rvirding

The OTP are identical because both use the same OTP, the original Erlang OTP. Elixir just puts a wrapper around it to give a more elixir feel. And add default callbacks which I personally don't like.

One difference is that Erlang's concurrency and error handling in the language is more basic than Akka's and does not directly provide fault-tolerance through supervision but does provide the primitives to implement. All of OTP is implemented in Erlang with these basic primitives. These primitives are actually very simple, the difficulty was getting the right set of simple primitives on which to build the rest.

Also I think you will find that a lot of features which are very similar of Akka's location transparency were built-in to the distribution mechanisms which are part of Erlang. We were at least thinking of distribution from a very early stage.

That is a very good paper, well worth reading!

I was going to make a nasty comment and refer to Schiller, but I won't. The jokes on you. :-)

Who got it from elsewhere. ;-) The sequential part of Erlang is basically a simple functional language with nothing really unique, except maybe for binaries. It is the concurrency and error handling where the really good bits are.

Just want to point out that atoms and function names ARE the same in that function names are atoms, they must be in fact as that what the system demands. So are module names for that matter. That is why if you want a function with a "funny" name you quote it as you do an atom

'the answer'() -> 42.

It was originally in the original Erlang interpreter written in Prolog but you could use it for back-doors in the communication so we removed them. If you sent an unbound variable in a message then the receiving process could reply by binding the variable. We wanted all communication to be explicit.

I agree though that unification is cool. And I still like Prolog and other logic languages, and have implemented Prolog in Erlang, of course.

We also gave some thought to laziness but felt it just didn't fit as for the type problems in which we were interested. For those problems when things are done is critical, not just that they are eventually done. That would have meant a lot explicit evaluation which defeated the point of laziness.

They got that from Erlang :-)

Well, you can filter, map and fold over maps so there is not really much missing. And they are efficient both when they are small and large.

I thought they all must be java.

If you seriously look at the Erlang syntax you will find it is very simple, concise and consistent. We wanted to keep it simple. Yes, it different from most OO languages, most functional languages look different, but that is not surprising as the semantics of Erlang and other functional languages are very different from the semantics of your typical OO and imperative languages like Jave, Ruby and C. If it is doing different things why should it look the same? That would just be confusing.

Also, if you again look seriously at the syntax you will see there is actually very little Prolog in it, most of that disappeared along the way when it became functional. What is left are variables, atoms and lists. Records are a bit messy although they are very logical and consistent (again) but no one has come up with an alternative that works. They also fit the language semantics.

Also I personally don't see the problem with learning another syntax. I know and have used about 9-10 so far so what is really the problem?

And I rather like Prolog syntax, it simple, concise, consistent and truly homoiconic though with operators.

It is actually being used in products.

The name was the hard bit, elua was already taken, erlua sounds funny and erlanglua is so long. So it became luerl.

Yes, I am a language nut :-) and I like to implement languages. It is a very complete Lua implementation in that it supports all of Lua 5.2 except for coroutines and many of the standard libraries. There is of course a good erlang interface and it is easy to write more interface modules to things written in Erlang.

The default usage is more to call Lua from erlang to do things, much like from C to the standard implementation.

Of course metatables are supported, it wouldn't be much of a Lua without them. Luerl is standard Lua 5.2 except for coroutines.

I know I missed this but I do want to make some (general) comments:

- Erlang, the language and system, was designed for highly concurrent and fault tolerant systems. In many ways these were more important than raw throughput in that if it could not handle the massive concurrency and build truly fault-tolerant systems then it wasn't interesting. At all.

- Same with pre-emptive scheduling, the system had to be non-blocking. Again if it wasn't then it wasn't interesting. Yes, you can provide primitives to allow the programmers to do it but this does make things difficult and not-reliable.

- The language design was focussed on these types of systems and and implementing the types of architectures which OTP supports.

- From Erlang's point of view using OS threads as a base for Erlang processes is not an option. They are way too heavy and you can't have enough of them to be interesting. 10k processes are child's play, 100k processes is starting to get interesting and 1M process production systems exist, for example WhatsApp.

- For Erlang processes are the basic building blocks in a similar way to objects in an OO language. What would a Java programmer say if they were told that they couldn't have more than 1000 objects?

- Having the erlang VM handle using all the cores, or as many as you want, by default is just the natural way to do things. If I had to do any form of restructuring of my system because I was running on 4, 8, 16 or 32 cores I would consider that to be intolerable and so primitive I would wonder what the implementors were thinking of.

- While the Erlang syntax is different (which functional language doesn't have a different syntax?) it is actually very concise and consistent, this by design. The elixir syntax is "Ruby influenced" and more complex and feature filled. Which you prefer is up to you.

- I am very fond of lisp so there is at least one native implementation of lisp on the Erlang VM, LFE (Lisp Flavoured Erlang), http://lfe.io/ and https://github.com/rvirding/lfe.

- There is nothing which you can do in one which you can't do in the others, after all they run on the same VM and you can easily combine them and use them together.

That's about all for the moment,

Robert

Yes, but the VM clock guaranteed more, every time you access the clock using erlang:now() you would get a monotonically increasing value. Practical to be sure, but not scalable.

Why not just write it in hexadecimal?

Aaaahhhh, the syntax is different! Help, help, the world is coming to an end.

If you replace "Joxa" with "LFE" here you would get a good description of LFE.

Not quite, LFE is a self-contained Lisp system with all the things you would expect a lisp system to have. It has been designed to run on the Erlang/OTP system and to efficiently use all the features of that system and its VM. This means that LFE has a clean interface to Erlang/OTP so it can easily be used together with applications written in Erlang. Mixing components written in Erlang and in LFE to write a larger application is straight-forward and painless.

If I could rename it then a better name would be EFL (Erlang Flavoured Lisp), which is what it is. The "Flavoured" in the name comes from that I had earlier implemented a Lisp machines flavors system on another lisp, with an english spelling thrown in as a joke.

They don't handle errors very well.

Why am I getting this strong deja vu feeling? Hmm. Oh, now I know! These were exactly the type of problems we were attacking, and solving, 25 years ago when we were creating Erlang. How you build concurrent, fault-tolerant and non-blocking systems with low-latency. And about 10 years ago there came implementations of Erlang which handled multi-core transparently and provided things like load balancing automatically.

I would say you would have to have really extreme requirements to handle those type of things yourself.

The best thing that we weren't faking this. We did actually run though the whole sequence as was shown in the movie with having a call going while another part of the crashed and was fixed.

I found that being a Lisp-1 made it inconsistent so I went with Lisp-2. Why should I be able to multiple functions with the same name but different no of args at the top-level (which you can and is commonly used) but not in local functions? Lisp-2 gives you the same handling for local functions and top-level functions.

Yes, implementing languages is fun, implementing lisp doubly so.

Being an erlang programmer I am so used to programming for the correct case and not to check errors but let the process crash when you get an error or, rarely, use a try that I find this style of programming completely wrong. It is what we are trying to avoid. You will always miss cases.

You can use similar methods for interfacing C as well, if this is a better way for you to interface fortran.

The heading does actually say for which language this is: elixir.

Here is a good talk on getting erlang to talk with other systems, http://www.erlang-factory.com/berlin2014/robby-raschke. It is of course completely accessible from LFE.