4 ms·
I will be the guy bringing Erlang (or more precisely BEAM -the Erlang VM- and the various languages that run on top of it) into this thread... But it's amazing
by Xixi 11y ago
I will be the guy bringing Erlang (or more precisely BEAM -the Erlang VM- and the various languages that run on top of it) into this thread... But it's amazing how much Erlang got right so long ago. Erlang applications are effectively fine-grained, Service Oriented, with a very low overhead.
There is, of course, one drawback: you loose the low overhead advantage as soon as you step outside of the Erlang world. That's a major drawback given that a non-negligible part of the Service Oriented Architectures appeal is the possibility to use the best possible tool for a given job, no matter what language/VM/hardware that tool is built with...
- rdtsc 11y agoGood point. There is also a funny tangent on it. Garrett Smith (the person responsible for such movies as "MongoDB is Webscale" and "Erlang II: The Movie" http://www.gar1t.com/blog/tags/videos.html http://www.gar1t.com/blog/tags/videos.html) made a comment that Erlang has already been doing nanoservices before microservices were cool. In a certain way he is right. Each gen_server lightweight process is a small independent service that starts up with only a few KB of memory, has an isolated heap and can be called from another Erlang node from half-way across the world like a you'd call a local process.
- cies 11y agoLet me take your point even further: it is some principles of functional programming that make these languages a great fit for "refactoring" and "breaking apart the monolith". Myself I'm more into Haskell. I see similar benefits in both Haskell and Erlang. A nice thing of Erlang is that you have to structure you application as a bunch of services from the start.