I'm always surprised and delighted to see so many "first implementations" of languages in prolog. It was described to me in college as "just a novelty" but in fact it's used extensively in the JVM internals [1] and apparently is the starting-point impl for other languages.<p>But prolog still seems so..awkward. I wonder why langs like Haskell or OCaml aren't more de-facto for these purposes; they seem to have similar expressive power for parser/grammar things and with less inside-out paradigms (imho).<p>[1] <a href="https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf" rel="nofollow">https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf</a>
Prolog and Erlang in the same thread - is it Christmas already? Two of my favourite languages, both hugely undervalued.<p>I remember the moment I first "got" Prolog. Having only programmed in C/C++ to that point, it took some mental contortion. But the "oh!" moment was amazing. Backward chaining & logical variables are just so incredibly elegant. I still use transitive closure as an example of just how powerful the language is:<p>path(A, B) :-
link(A,B).<p>path(A, B) :-
link(A,I), path(I,B).<p>That's it. Stunningly simple.<p>As for Erlang - as others have noted - it was conceived right from the start as a language for concurrency. It's had 20 years to mature and robustly solve problems that inherently single-threaded languages have barely even recognised yet (C/C++/Java/C#/python/javascript/rust/...). Supervisors / error handling and threading are two notable examples. It makes me sad to look at the spread of "async". An inelegant sticking plaster that adds yet another concurrency construct and turns it into a tactical decision - on <i>every method</i> - and at the call site too.<p>Erlang shows that a single, well-conceived and executed construct is both possible and preferable. Lovely.
If you'd like a high-level discussion of why the BEAM was designed as it was, check out my recent post: <a href="https://dockyard.com/blog/2018/07/18/all-for-reliability-reflections-on-the-erlang-thesis" rel="nofollow">https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...</a><p>The TL;DR is: reliability was the main goal, and using isolated processes which can react to each others' failures, even when running on separate machines, was the way they found to get reliability. This turned out to be nice for scalability also.
When I say this out loud, it sounds like a stupid question, but I'm still curious...<p>Outside of the fact that different programming languages run on BEAM and the JVM, what's the difference between the two?<p>I believe BEAM ships with supervisors, which is why Elixir can utilize them... what else is different?
BEAM is phenomenal but one area that's still preventing people from adopting it is pure raw performance.<p>People have to write NIFs far to often to obtain the raw perf they need and in doing so, negates all the tremendous benefits of the BEAM.<p>I hope more people push BEAMJIT development forward.<p><a href="http://www.erlang-factory.com/sfbay2017/lukas-larson.html" rel="nofollow">http://www.erlang-factory.com/sfbay2017/lukas-larson.html</a><p>Maybe Facebook would fund this effort given their huge BEAM investment from WhatsApp use.