rvirding · HackerTrans

в прошлом годуdiscuss

The reason for calling it Luerl was that it was/is an implementation of Lua on Erlang. It is Dave who has been working with a more serious Elixir interface. The original one, which still exists, had a very simple Elixir interface module which just flipped the argument ordering to calls to be more Elixiry in feel.

rvirding

3 года назадdiscuss

I would be very interested about the architectural possibilities of the BEAM you mentioned. Also the speed of the BEAM is not as bad as is often mentioned, definitely not when you start looking at problems/tests with lots of inherent concurrency. Also the sequential speed has markedly improved with the new ASMJIT.

Also problems with GC basically don't exist when running Erlang/LFE code, at least you have to put a lot of effort into getting problems with GC. A lot! And, of course, the BEAM does automatic load balancing over multiple cores which is another problem gone away. We never have to think about the class of problems like "I have my system set up to run on 2 cores, how should I modify it to run on 4?".

rvirding

3 года назадdiscuss

I think the thing to remember that it all started as an interpreter written in Prolog in which we could develop our ideas on what the real problem was and the right semantics of a system for solving them. As we went along our "language" evolved as well and became less and less Prolog and more functional as we removed much Prolog semantics, added functional "stuff" and developed the final syntax.

We had along the way also looked at concurrent logic languages. So by the time we had a language and design rules how to use it most of Prolog had disappeared, though some of its syntax still remained. This language was, of course, Erlang.

While Prolog was a nice base on which to develop our ideas it was never the language we would have used in real life.

comments