A History of Erlang (2007)

https://dl.acm.org/doi/abs/10.1145/1238844.1238850

by vinnyglennon • 6 years ago

107 48 6 years ago

dl.acm.org

mycall• 6 years ago

I don't understand why people don't like Erlang so much [1]. It has many excellent features and the runtime stability is unmatched.

[1] https://www.codementor.io/blog/worst-languages-2019-6mvbfg3w...

imglorp• 6 years ago

All true, plus other advantages, but I think there are some business requirements that prevent adoption. The syntax and runtime model are unfamiliar and there aren't enough users to get dependable critical hire biomass on a new project. Lots of management would rather have a lot of average, commoditized labor than a little rare, elite few.

It's especially tragic because we keep repeating the same mistakes and discoveries over and over that OTP+Erlang solved ages ago. Eg most environments are still dinking around with clumsy hacks to help with GC and concurrency issues.

cpach• 6 years ago

“Lots of management would rather have a lot of average, commoditized labor than a little rare, elite few.”

Very well put and probably very true.

rukittenme3• 6 years ago

I like erlang. But erlang's syntax doesn't do it any favors. Might as well use elixir. Still the beam.

I also don't think the beam's benefits are necessary for the vast majority of software which makes it perma-niche. "Why use erlang when I can use python, a database, and a distributed task queue?"

I also really like Elm so I was sad to see it in the poll position, but I also don't base my language choices off of someone's blog.

macintux• 6 years ago

Unfamiliar syntax is not the same as bad syntax. Erlang’s syntax is much simpler than Elixir’s, and generally more concise.

PopeDotNinja• 6 years ago

The more I've played with Erlang, the more I've liked its syntax. What I don't like is dealing w/ strings in Erlang.

h91wka2• 6 years ago

I have long since learned that dismissing languages based on their syntax is very punitive, as novel and powerful languages very often come with unfamiliar syntax. Syntax is the least difficult thing to learn. Things like type system, approach to concurrency and memory management are orders of magnitude more important.

WilliamEdward• 6 years ago

It's gaining a good track record because big industry giants are using it, but it's hard to force functional languages on people. The majority of people will learn OOP for a number of reasons unrelated to how good it is, while functional is becoming more like a niche artisanal craft.

dnautics5• 6 years ago

while functional is becoming more like a niche artisanal craft.

Well, I mean most boot campers are being taught functional React, so, I think it's hard to justify calling it "niche and artisanal" anymore.

johnmarcus2• 6 years ago

In me experience using Phoenix, it takes an eternity to compile. I imagine that turns a lot of folks off to begin with.

1_player2• 6 years ago

Eternity? My 50kloc Elixir project compiles about the same time as my 10kloc next.js/React project.

I've never noticed any compilation issue on my machine, though it's a beefy one (and still JS takes ages)

1_player2• 6 years ago

What a stupid list that is. Rust, Typescript, Elixir, Haskell, C not worth learning in 2019?

If you know zero languages, yeah, go learn Javascript, Python or (ugh) Java. If you know one or more language, the ones listed above are definitely worth your time.

You might find it a little hard to make a career out of knowing only Elm, but you might not grow very much professionally without widening your horizons a bit either.

seagreen3• 6 years ago

I've had trouble getting into it because the ergonomics are so incredibly, wonderfully, art-project level rough.

For example:

    $ erl
    Erlang/OTP 20 [erts-9.2] [source] [64-bit] [smp:8:8] 
    [ds:8:8:10] [async-threads:10] [kernel-poll:false]
    
    Eshell V9.2  (abort with ^G)
    1> 2 + 2
    1> 2 + 2.
    * 2: syntax error before: 2
    1> 2 + 2.
    4

Note the trailing whitespace(!) after the last `2 + 2. `, necessary for the result to be printed.

I was coming from Haskell which has its own very serious tooling and ergonomics problems. Trying Erlang made me realize things could be even worse. My internal model in my head of language designers/promoters is COMPLETELY wrong, I have absolutely no idea how people could spend time promoting languages with such strange tooling to a general audience with any expectation that it will work.[1]

[1] Not to say that these languages/tools aren't awesome. Trailing whitespace matters semantically absolutely not at all. But if you're trying to promote a language with meaningful trailing REPL whitespace to a general 2020 audience there is some terrible mismatch between your expectations and your actual chance of success.

moreoutput• 6 years ago

What am I missing here? I see no meaningful white space when running the same logic. I would expect this from any language when expressions aren't properly terminated.

Eshell V10.4 (abort with ^G)

1> 2+2

1> 2+2.

* 2: syntax error before: 2

1> 2 + 2.

Jtsummers4• 6 years ago

There's no meaningful whitespace in your example. You have a syntax error in the first example.

To get the effect you wanted in the you needed a `.`:

  1> 2 + 2
  1> .
  4

That is, if you really wanted it split over multiple lines.

The syntax error is indicated as being on line 2 (though not obviously on line 2) with the prefix to the error:

  * <line number>: <syntax error information>

What you've essentially typed in your first example is (replacing the newline with a single space):

  1> 2 + 2 2 + 2.

You'd expect an error from that since there is no operator between the second and third 2. Even placing a comma would've been enough:

  1> 2 + 2
  1> ,2 + 2. ;; this is weird to do, but valid
  4

The shell expects a period terminating an expression before it parses it. This permits entering multi-line expressions without doing anything special (you don't need a special "I'm going to continue on to the next line please don't parse this one" backslash, for instance).

BubRoss3• 6 years ago

If you think that's bad, wait until you realize that even though people will fill threads talking about zig being a successor to C, it -purposefully- errors out on carriage returns and tabs! It is specifically built in that if you save a text file out of any windows editor without changing special settings, zig will error out. If you put in tabs, it will error out. Now trailing white space doesn't seem so bad.

callamdelaney• 6 years ago

I actually find Erlangs syntax a breath of fresh air. Coming from Python, this may sound odd, but there's something soothing about it.

I much prefer Erlangs syntax to Go, for example. I also much prefer Erlangs syntax to Elixir; I never liked ruby either, so there's perhaps no surprise there.

waynesonfire• 6 years ago

i completely agree.

dudul2• 6 years ago

Agree. I like that it's very logical and consistent. The way periods and semi-colons sometimes seem a little like anarchy, but there is actually a strong reasoning behind it, very well explained in Joe's book.

Elixir brings a lot to the ecosystem, but I personally find the syntax not as pleasant because of all the syntactic sugar that hides a lot of the "real" syntax.

thijsvandien• 6 years ago

It's unfortunate how Elixir splits the ecosystem in a way, simultaneously drawing attention to and away from Erlang. While it should be possible to use (compiled) Elixir code from Erlang—as once demonstrated by Joe Armstrong himself—it's far from pleasant compared to the inverse. At this point, I would be hesitant to use BEAM if I didn't like Elixir (still have to really try, though I can totally see the appeal of Erlang), because it's becoming harder and harder to ignore. To those of you that prefer Erlang, what's your opinion on this?

pjmlp• 6 years ago

Me too, as former Prolog fanboy, I really don't get Elixir hype, other that it provided an escape route for those not wanting to deal with Rails, or its lack of performance due to MRI Ruby not having a solid JIT story and the alternative implementations not being as good running Rails.

dnautics5• 6 years ago

I think this illustrates the power of elixir; You can't do this so easily (and certainly not as featurefully) in erlang: https://hexdocs.pm/zigler/Zigler.html

Other things I've done in Elixir that are way easier: implemented a multiverse registry that tracks supervised transient gen_statems in segregated test contexts (so a test only sees gen_statems that have been started in their caller context). Elixir has an opinionated way of tracking caller and ancestors in the supervision and temporal history that are crazy powerful. Thanks to erlang term format, it's also easy to send that information out of the vm (for example into chromedriver and back into the vm via http headers). It's become an accepted standard in the community, and the web drivers, database adapters, and dependency injection/mocking libraries consistently use them.

Implemented a virtualization library that seamlessly launches virtual machines with a unified abstraction between locally launched vms and remotely launched vms (there's things that elixir has that make this easier and compile-time checked). It's also got 100% code coverage thanks to Elixir's powerful dependency injection and abstraction capabilities.

Implemented compile-time checking of configuration settings that makes 100% sure I don't deploy broken configs to prod; they get stopped at the release stage. But also they get actively code highlighted at the TOML level in vscode, so I don't even have to wait to generate a release. It's dead easy to emit custom file/line information in Elixir's CompileError exception.

dudul2• 6 years ago

Elixir does provide a few nice things over Erlang I'll admit. The way it deals with behaviors is a little nicer to type, macros are definitely easier (but now the issue is that everybody wants to use macros for everything). A lot of effort is put in the documentation and tooling.

A History of Erlang (2007)

Related Stories