rvirding

We all learned prolog at the lab, well at least those of us who used prolog.

That about Joe is not strange actually as he has never been a C-programmer. Before coming to the lab he was a fortran programmer.

LFE (Lisp Flavoured Erlang) is very much alive with a whole bunch of new stuff now released on the master branch. For example you can now easily write LFE shell scripts and run them, much in them way as with sh. There is also a good webpage, the http://lfe.io/ you mention, and a growing set of libraries which have been done by me.

There is also a mailing list at https://groups.google.com/forum/?hl=en#!forum/lisp-flavoured... and an IRC chat at #erlang-lisp.

P.S. I also have a prolog running on erlang as well.

That RabbitMQ gives you many of the features you want from Erlang is not that strange really as RabbitMQ is implemented in Erlang. :-)

Some people have already been mentioning this but I wish to clarify some things.

When Erlang was designed/invented the goal was never to make a new language, the goal was to design a way of building systems with a set of specific characteristics, massive concurrency, fault tolerance, scalability, etc. One part of this was the language, Erlang. But at the same time we were developing the language we were also looking at how you would use the language and its features to build such systems. The language and the system architecture went hand-in-hand with support in erlang for the type of patterns you would need in the system architecture.

These ideas and patterns existed before OTP. So there were Ericsson products built on top of Erlang which used these ideas and patterns before OTP. OTP "just" took these ideas and design patterns and formalised them in a generic, cohesive way. Plus of course a lot of useful libraries.

So we were never really out to design a functional language based on the actor model, we were trying to solve the problem.

(We had actually never heard of the actor model but were told later that Erlang implements it)

Did you try to implement your own behaviours? Or processes that aren't behaviours as such but still function correctly in supervision trees and in applications?

Yes, it is flawed logic, but you were using so I don't see why you should object to it. And his goal was to show that.

Erlang parse transforms give you access to the full AST of a whole module and it must return the full AST of a module. It is like a macro which operates on a module not on a form. They are very powerful but easy to get messed up in.

I forgot to mention that if you want to have lisp macros in the erlang ecosystem you have LFE (Lisp Flavoured Erlang) https://github.com/rvirding/lfe or Joxa.

I would say that one restriction with the type of macros that elixir has, irrespective of whether we call it homoiconic or not, is that they can only manipulate existing forms in the AST, they can't define new syntactic forms. In elixir this means that you basically work with function calls. There is syntactic support for making the function calls look less like function calls but the macros you define are basically function calls.

In Lisp you are free to create completely new syntactic forms. Whether this is a feature of the homoiconicity of Lisp or of Lisp itself is another question as the Lisp syntax is very simple and everything basically has the same structure anyway. Some people say Lisp has no syntax.

Trying to build the AST that directly in elixir is quite difficult as the AST is not trivial even if it relatively simple and regular. Quote and unquote in macros do a lot of the work for you. At one level you could do something similar for Erlang but no one has actually gone all the way with it. Erlang uses parse transforms for that. They are more powerful but much more complex to use.

Elixir isn't homoiconic, it never was, and they no longer make that claim.

Yes, that's me. Where is the "comment below"? Couldn't find it.

I just want to point out that I don't dislike Lua at all, it is a small neat language with some very nice features. It just isn't something on which I would base a parallel system as it has too much sharing and other things which don't go parallel easily. Using it as plugin to erlang for doing "business" logic works quite well, either by communicating with a Lua system or doing like Luerl and implementing it Erlang. This means that Luerl meshes completely with Erlang.

Actually if you really start asking a lot of people do actually want this but it is often something they don't explicitly mention. It tends to be one of those "of course it must ..." things.

The erlang syntax is actually much simpler than Elixir's which both contains more syntax and alternate ways of writing things.

From personal experience implementing the string handling is trivial compared to implementing the system side of Erlang. Get real.

Yes, and you will end up reimplementing a lot of what is already in Erlang and most likely not as well either. Virding's 1st rule.

I am not going to enter into a syntax argument I have already given my views on that here http://rvirding.blogspot.se/2014/01/erlang-syntax-again-and-... . My main point is that the syntax is simple and that it fits the semantics much better than anything based on an Algol like syntax would, even one which uses ';' in the "normal" way.

And one reason it works is because it has built-in those features for building fault-tolerant systems which, for example, Go lacks. Borrowing from NASA "Failure is not an option".

Erlang does automatically parallelize over multiple cores. By default it will start one Erlang VM thread per core which work together to run the Erlang system. The Erlang VM also does automatic load balancing over the threads and even tries to shut down threads/cores if it detects they are not needed. It is possible to control how many Erlang VM threads you want at start-up and to lock them to cores as well, though the latter is not recommended. But as I said there is no need to do this.

Yes, a daddy of 3 children including one daughter. It is still a stupid list.

Sorry, can't help it. What a stupid list!

Then what are we really measuring? Is it how many connections we get can get on as small a machine as possible? If so then I am sure I can get 600K connections with Erlang in a smaller system. At least running a benchmark.

There is one very significant difference and that is that the Clojure benchmark was just a benchmark while for WhatsApp it was their actual system doing something real. They have mentioned to me that they have managed to push their system to 3M connections but not in production.

So? Not really impressed. WhatsApp are getting over 2M concurrent HTTP connections with Erlang in a production system. And this was 1 year ago. http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...

I think one significant difference is in the actual implementation, or rather its intended use. The BEAM implementation is built to be used in products, it is very stable and bug-free and the OTP team are very cautious when making changes. Incompatible changes are introduced with early notices and warnings, usually 3 major releases before the change is made.

My impression is that Haskell implementations are more used as research tools and there is less control of what goes in and how it is to be supported.

In that sense it would be safer to build a product on top of Erlang.

That is just my impression and I could be wrong.

Yes, in retrospect using = was probably not a very good choice. I will admit some things in Erlang didn't receive much thought before being added while to some things we gave a lot thought; for example the language/systems basic properties and the semantics of concurrency, message passing and error handling.

Every time I read something about the weird Erlang syntax I get so tired and try and tell myself not to get into the discussion, it's not worth the effort, some people will never just never learn, etc. But sometimes I can't help myself. So some of my thoughts on this:

- Syntax is the easiest part of learning a language. It's all written down and its just a RTFM. And yes, I have written a lot of C and lisp and prolog and erlang and ... and I never have problems with the syntax.

- If people worry so much about the syntax what happens when they get to the semantics?

- Seriously, why would you want to Erlang to have similar syntax to a language with different semantics? In my view that would be asking for trouble. I think one reason why I haven't had trouble with mixing languages is that both the syntax and the semantics are different. C looks like and behaves like C while Erlang looks like and behaves like Erlang.

- The erlang syntax is actually very simple, much simpler than the languages you would like it to look like.

I will now stop before I say something nasty.

I liked the blog.

Sort of. The syntax evolved at the same time we were moving from Prolog onto our own implementation, which forced us to write our own parser and not rely on the original Prolog one. The biggest syntax change came around 1991, since then it has been mainly smaller additions and adjustments.

As in Prolog ',' and ';' are separators: ',' behaves like an and, first do then and then do this (as in Prolog); while ';' is an or, do this clause or do this clause (again as in Prolog). '.' ends something, in this case a function definition. Erlang's functions clauses are not the same as Prolog's clauses which explains the difference.

It is very simple really, think of sentences in English and it all becomes trivially simple.How many sentences end in a ';'?. And you almost never need to explicitly specify blocks.

Here http://ferd.ca/on-erlang-s-syntax.html are some alternate ways of looking at it.

I think it would be dangerous if Erlang's syntax were to resemble that of another language like Java or C. Especially for beginners. That is because if things look the same you expect them to behave the same, and Erlang's semantics is very different from those languages whose syntax people think it should be like.

There is no getting around the difference in semantics. For this I think that having a different syntax is actually better. Also there are things in Erlang which are hard to fit syntactically into the syntax of OO languages, for example pattern-matching.

Yes. For the underlying system to be able to detect and run in parallel you need the concurrency. Without concurrency your application will be run sequentially.

Beware of "Kenneth the Swede"! Just stay on the straight and narrow and you will reach the Celestial City.