In functional languages pattern matching (and multimethod, where is available) exists as consequence of other features
I must say I really like this point, but I also don’t fully agree. Languages like ReasonML and Haskell are indeed focused on a single paradigm and as a result of that offer a feature set that matches beautifully together. On the other hand the more mainstream languages like TypeScript have a much wider and general-purpose features set. TypeScript comes with all the tools for imperative programming, has a solid implementation of classes with a lot of language features and is also very powerful when it comes to functional programming. (even tail-recursion is actually becoming a thing in javascript)
A practical example of this is the presents of both interfaces and types in TypeScript, where the first is pure OOP style and the second much more functional. In one way this is a bit of a ugly mess, in an other way this is how you make a language that works for everybody. Sum types and monads are totally valid ways of solving problems in TypeScript, I use them more then daily. Only in the object/prototype way of javascript you use fluent style api’s instead of custom operators. C# is also a great example of a mainstream language that is creeping more and more to a functional way of thinking with the introduction of lambda’s, anonymous types, tuples, pattern matching (yes) and more features from its functional cousin F#.
For the coworkers point: our CTO writes blogs like ‘Category theory for TypeScript programmers’ and ‘Type-safe monads and React’, over here we are on functional side of problem solving. We write our React components here as IO monads and use a standard library with compositions and common implementations to get the max out of them.
