I still don't understand the point about the deep pattern matching. In OOP you'll have an object that encapsulates all that knowledge, and in functional program

I still don't understand the point about the deep pattern matching. In OOP you'll have an object that encapsulates all that knowledge, and in functional programming you'll have a module that encapsulates all that knowledge, clients of both the object in OOP and clients of the data structure in FP will need to have the same knowledge to deal with it - once you need to serialise the information. I just don't find the argument compelling, in my reading it would be akin to saying, it's a code smell a class has all this implicit knowledge of the object it's modelling (assuming the deep pattern matching in the module dealing with transforming it). > There's almost always some microbenchmark a slow language can beat a fast language in, but that doesn't make it a fast language. You might want to dig into that "elixir lib that beats C++", because either the C++ was really bad or the elixir lib is actually written mostly in C(++). Usually it's microbenchmarking that doesn't flatter elixir/erlang - and stampede problems where you can get away with just brute forcing - eg. parsing directly to output a bunch of files where the output is a file(s) - but there, if you want then to build usable metadata through all of it things change fast - writing a correct program in any of the fast languages that has the same ergos for keeping usable information throughout and is at the same time easily changeable, can interleave information in parallel with pretty amazing monitoring, and doesn't require years of training, is quite a different thing. I know it doesn't use C++ because I wrote it and I know how much more it does as well, though I'm not here to convince you. > Yeah, but when you're talking about a 30-40 year programming language, that's not a necessarily a compliment. Nobody else has seen fit to exactly copy it, because we've found better things to cover the problem space than that. Well, sure, I just think it should not be written as "cover" the problem space, is more "making holes" in the problem space. > There is a lot more to being a message bus than just having a TCP socket. Given that your argument was: > A modern message bus like Kafka or the dozen other choices doesn't impose an implementation language on you, nor does it impose that implementation language being the only one I'm not sure there's any more esperanto than tcp/sockets, which comparing to any other language are a joy to write, use, monitor, and deal with. > You can, in theory, connect to an Erlang cluster without Erlang, but in practice the requirements of being "an Erlang cluster" are so specific This sincerely... How do you connect to other clusters in other languages (if they're even able to set up meshes)? You don't. How do you solve it? With clustering solutions. How is it that a runtime that can be put inside those same clustering solutions, by the same process, but has a zillion more functionality can be worse than those other solutions regarding that? > Once you've taken the time to speak to a non-Erlang message bus, use a non-Erlang database, wrap your Erlang code in K8S or some non-Erlang manager, use Erlang to hit HTTP APIs, speak to non-Erlang monitoring systems... why are we using Erlang again? Yeah, because they all speak something else than http/tcp and we know erlang is not really made for handling sockets and can't do http.post().