[softbuilder]

Every time I see these (LFE, Elixir, perhaps others) mentioned I feel sad that people don't seem to see the beauty in the Erlang language itself. Learning Erlang was a watershed moment for me and it had little to do with the actor model or OTP.

That should not be meant to take away from these other projects that do interesting things. It just seems like people needlessly avoid Erlang because it's unfamiliar and they miss something amazing in the process.

[sitkack]

Welp, I am pretty sure the creator of LFE "gets" Erlang, as it is Robert Virding [1]

Pattern matching and immutability are pretty sweet aren't they? So is homoiconicity and macros.

[1] https://github.com/rvirding

[softbuilder]

>Welp, I am pretty sure the creator of LFE "gets" Erlang

Did I suggest otherwise?

[fenollp]

IMO Erlang needs Elixir’s `|>` and `with` pipes. I voiced my opinion on the ML and kind of started working on it! I need https://bugs.erlang.org/plugins/servlet/mobile#issue/ERL-639 fixed first.

I find Erlang a harder tool to shoot yourself with than Elixir yet there are definitely some things it could improve on, and not only at the language level (always running xref on compilation would be nice).

[dnautics]

the pipes are worth it for the IO.inspect pattern alone.

For those who are not familiar, in Elixir you can write

    result = value
    |> f1()
    |> f2()

and that is equvalent to

    result = f2(f1(value))

IO.inspect is a function that will fork a copy of its passed parameter to stdout, pretty-printed, and pass its parameter as the sole result.

so if you wanted to check on on the values you can do this:

    result = value
    |> IO.inspect(label: "value")
    |> f1()
    |> IO.inspect(label: "result-of-f1")
    |> f2()
    |> IO.inspect(label: "result-of-f2")

This makes "println debugging" super, super, easy, because post facto cleanup doesn't require rebalancing your parentheses.

[i_feel_great]

> I find Erlang a harder tool to shoot yourself with than Elixir

Can you please elaborate? I was of the opinion it was the other way around.

[waisbrot]

One example that I hit frequently:

An "atom" is an Erlang/Elixir thing, kind of like an enum value. "true" and "false" are implemented as atoms, you might create atoms to represent connection states ("idle", "connecting", "connected", "disconnecting"), or to represent errors ("file_not_found", "no_permission", etc). It's a really useful thing and something I miss in every language that doesn't have it.

In Erlang, a variable is a token that begins with a capital letter ("UserId") and anything that begins with a lowercase letter is either a keyword ("if", "case", "end") or an atom. Since keywords are a finite set, this is pretty straightforward. Module names and function names are atoms, so there's no additional complexity there.

In Elixir, a variable is a token that begins with a lowercase letter, unless it's a keyword or one of the special atoms "true", "false", and "null". An Elixir atom either starts with a capital letter (typically module names) or has a ":" in front of it (":file_not_found") or has a ":" after it when used as a map key ("file_error: :file_not_found" -- both words there are atoms).

So the problem that I run into is that identifying whether a token is an atom and, if so, if it's the same atom as in another spot, requires more thought than I think it should.

My Elixir experience was that there were quite a few cases like this where I hit minor friction. In general, I felt that Elixir code is a little easier to write but a little harder to read and Erlang code is a little harder to write but a little easier to read. I feel like the latter situation should be much preferred.

[dnautics]

This is just coming from an Erlang background. For those of us who came from other languages, atoms are often implemented with the colon syntax (ruby, julia)

The reverse colon syntax was a bit wierd, but it (and including the parser assuming that it's in a list when it's the last term) make parameter lists buttery.

[Ndymium]

Just a note:

The atom for "null" is actually `nil`.

[jchassoul]

Syntactic sugar causes cancer of the semicolon!

[rs86]

I really like Erlang but Elixir has the protocol feature for polymorphism that is really useful.

Personally I like the Erlang syntax better but most colleagues find it weird.

[rvirding]

Well, I do of course see the beauty of the Erlang language; it is a simple, concise and consistent syntax. However, I also like Lisp being an old lisper. Lisp was actually the first high-level language I learnt. So LFE is an attempt to get the best out of Erlang and Lisp, at the same time.

[brightball]

I love the runtime and don’t have anything against Erlang, but the coding experience of Elixir really won me over.

It’s not a dislike of Erlang as much as it is a joy of Elixir situation.

[whitepoplar]

I love Elixir, and I've played around with Erlang, but only very briefly. What made learning Erlang a watershed moment for you apart from the actor model and OTP? What do you think are the most elegant parts of Erlang?

[softbuilder]

'Elegant' is probably not a word I would choose, although it may apply at times. Erlang was the first place I saw pattern matching and is also how I came to actually understand list comprehensions, although I'd seen them elsewhere. There were other little things. And I liked the syntax! I don't think it was any one thing though. It was more the way things worked together, and worked much differently than other languages I had worked with. At that point I had been a programmer for 10 years and felt kind of jaded. Everything seemed fundamentally the same. I was even surprised now not-weird Lisp was when I finally got around to it. It seemed like once you get to a certain place with programming you think you basically have it all worked out and everything becomes implementations details. And then something comes along and shakes that understanding. It's that shake that I was grateful for. It was a personal experience. Others have probably had that with Haskell, etc.. I hope everyone gets to have that now and then.

[whitepoplar]

Thanks!

[pjmlp]

Same here, but then again I was a big Prolog fan during university.

So Erlang syntax feels natural, I just don't have any use for it on my line of work.

[rvirding]

I am a big fan of Prolog and concurrent logic languages as well.

[debacle]

Erlang is a very ugly language with brutalist, esoteric syntax. If Erlang adopted a C-like syntax (like nearly every other successfuly language in the world) it would see much wider adoption.

[nonsince]

C is a very difficult-to-parse language for both humans and computers and its syntax family got popular as much from circumstance as anything else. JavaScript stole Java syntax to court Jaca developers, Java stole C++ syntax to court C++ programmers, C++ stole C syntax to court C programmers and now you have most of the biggest languages of the past 20 years using C syntax because C got big back in the day (and it didn’t get big because of its syntax).

Modern C-family/Algol-family syntax is nice but I certainly welcome trying out other syntax families (in the case of Erlang, Prolog-family).

[alexeiz]

Erlang syntax indeed seems a little strange. But it's only because today we are accustomed to languages with much more usable/friendly syntax. But when Erlang was born in the 80's the usability wasn't much of a concern yet for programming language designers. Compare popular languages born in the 80's such as C++, Perl, Tcl with the languages born in the 90's such as Python, Ruby, Lua, Haskell. There is a clear pattern. Later languages are much easier to read and write.

[jarcane]

Jamming C syntax into everything is how we get eyesores like ReasonML.

A syntax should match the semantics of the language. C style is not the only way to design a programming language and does not fit all domains and semantics.

[maze-le]

Brainfuck is esoteric, C++ Template Metaprogramming is pretty esoteric. But once you wrap your head around the pattern matching, the erlang syntax becomes pretty straight forward. I found it interesting because it explicitly didn't look like a C-derivative. The only thing that I think can be a bit cumbersome are specs and types.

[pjmlp]

Beauty is in the eyes of the beholder.