A History of Erlang (2007) | Hacker News Reader

A History of Erlang (2007)

dl.acm.org

107 pointsvinnyglennon48 comments

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.

i completely agree.

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.

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?

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.

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.

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.

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...

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.

“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.

It is. Management will invariably say "We want the best!", and they may even pay comparable to FAANG levels, but when it comes to language/runtime, it's "We need to be consistent" and "We need something we can hire for".

Meaning even if management understands that a language/framework can be a competitive advantage, they will still be optimizing for lowest common denominator.

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.

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

I guess it depends upon what you mean by "unfamiliar". Erlang's syntax is unnecessarily divergent from a lot of mainstream languages. So much so that it makes it more difficult for mainstream developers to get into.

Elixir was modeled after Ruby for a reason. That reason was Ruby's very approachable and intuitive syntax.

It makes it easier for people to dismiss it; it actually is easier to learn.

Erlang it took me two weeks to become proficient enough to write useful things, without any real FP background. That includes leveraging OTP.

Even with that in place (plus a lot of Java, Javascript, some others, plus many more years of experience), it took me longer to be comfortable with Elixir, and there are still bits that surprise me or bite me (pinning a variable to match it rather than rebind it, macros, etc).

What's hard about Erlang's syntax? People keep telling me it's hard, but I was literally failing out of college at the time and still managed to learn it without much trouble (perhaps a month of occasional practice). I give that context because I can't imagine that I was struggling that much with school if I'm significantly above average for our field.

"People keep telling me it's hard"

Shouldn't that be enough to let you know that people at least don't find it to be intuitive?

No, because no one has ever explained how it's hard. They just keep repeating that refrain, and to date I haven't heard it from someone who spent more than a day with the language or gave it any serious consideration.

If people can enumerate the problems with the language (like I've seen or done for other languages), then I'll entertain the complaint.

So far the closest thing to a real complaint has been about variables-not-being-variables (in the C, anything can change, sense). But this is 2020, mutable-by-default is a known bad idea so this is hardly novel or a challenge.

The other reason I've heard is the lack of loops. If a professional programmer can't handle recursion, they need to go back to basics. I'm not trying to be mean with that one, but recursion is pretty easy.

I agree with you. Erlang is not as hard as people make it out to be. However...

Look at this piece of code: https://github.com/erlang/rebar3/blob/master/src/r3.erl#L32-...

In this example the keyword "end" ends with "", ";", and "." all within 6 lines of each other.

In this example the keyword "ok" ends with "" and ";".

In this example `Self` "exclamation marks" `Ref`.

All of this is easily understood with some experience but you have to admit that `erlang.send(Self, Ref)` is much more easily understood than some symbol that has to be googled. And consider this, a junior dev is going to be overwhelmed with all the syntactic sugar. They're just learning how to define and call functions.

All of these issues matter if your goal is to on-board as many hobbyists and juniors as possible. (Which shouldn't be the goal of every language).

I'm very happy with Erlang. I don't want it to change.

I have written a few thousand lines of erlang over the years.

> No, because no one has ever explained how it's hard.

> recursion is pretty easy.

uh, sure.

Let's talk about syntactical problems.

%% instead of // for comments because legacy+

=:= is === and /= is != , it's legacy+

Macros, atoms and functions are differentiated by context not syntax (?macros do have something). The capital letter variable name is basically an ever changing indicator. PHP $ or perl @ or some consistent indicator would be an improvement+

String handling is terrible, to this day and remember shell:strings(false) because legacy. Screw it, let's hide it in the gotchas of the manual and wait.

Some BIFs are named poorly. eg apply instead of "dynamic_call".

This is the correct way to look at branching decision syntax:

    if X < 0  -> negative
     ; X > 0  -> positive
     ; X == 0 -> zero
    end

The language doesn't help us with this for no apparent reason, with semicolons almost universally ending up on the end of expressions (sometimes):

    if X < 0  -> negative;
       X > 0  -> positive;
       X == 0 -> zero
    end

The problems are obviously user hostile and elixir and I magically overlapped. Anything with a trailing + was addressed in elixir which I did not know for sure before writing this list

The entire Erlang community response is basically the same (mailing list onward). Any attack on the syntax is either regarded as immaturity or whataboutism so people have just stopped talking about it like when someone gets an unfortunate face tattoo. The problems remain.

I find erlang to be harder to read. Part of that is possibly because it encourages passing modules in non-intuitive way. If you want an example, try spending a day figuring out why erlang's TFTP module won't support PXE booting. You'll give up after about 2 hours because the code shuffles in dependencies between multiple modules.

Basically its problems, may be more cultural than syntatical, in that, it grew up in the C era, where you did things the C way. And now, it's 2020. Software development has changed. We have parsers that can make reasonable decisions about when and where statements end (and I don't mean javascript). Documentation is easier to make pretty, bad architecture models (like FactoryFactoryFactories) are understood and we know why they're bad. Code editors are smarter, and little things like "now you have a directory tree on the side of your editor" make a difference to how you're going to architect and organize your code for ergonomics. And Language theory things like "why you might want to not have a string preprocessor" are better understood.

In short, time has moved on, and in some ways, erlang hasn't. Luckily, the virtual machine is still fantastic (and getting better).

So I noticed a bunch of responses seemed to be missing something you said -

"at least don't find it to be intuitive"

I will 100% agree it's not intuitive.

That said, I think only languages that behave like other languages you already know seem intuitive; the first time you were exposed to (your first language) it wasn't intuitive either. You had to _learn_ it. Learn the concepts, learn the syntax.

And I think that's what hurts when coming to Erlang. Most people doing so aren't used to language flavors other than the Algol-C heritage. Certainly, they're not used to the Prolog heritage Erlang is coming from, nor, probably, functional languages, and certainly not actor based ones. It's not intuitive at all; that said, I also don't think it's 'hard'. The language and grammar is quite small and understandable, even if parts of it are things I and many others find faults in. It's just by the time most people encounter it, they aren't used to having to _learn_ a language, but instead are used to being able to just kinda intuit a lot by just looking at it.

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.

100%! I actually prefer it now over elixir. Once you get to use it and spend a few weeks working with it, it becomes so expressive and it feels so clean to read and understand.

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.

Sure but I'm talking about on-boarding and generating developer interest. Appeal to junior developers and hobbyists is critical for large scale adoption. And like it or not a hobbyist's barriers to entry are different than a senior software engineer's.

> Appeal to junior developers and hobbyists is critical for large scale adoption.

Hmm, I have personally trained Erlang to half a dozen juniors and interns. Any person who knows basics of programming can pick it up and write/fix mundane business code in less than a month. And I am a horrible teacher.

Generally true, but there's also such a large convergence on Algol style syntax these days that your mind builds up familiarity with them. That makes groking them quicker.

Well for me looking at Erlang code is akin to looking at 'vase or two faces' photo, due to lower case being atoms and uppercase being variable names. And I dislike having to change ',' to '.' or vice versa when editing lines. Though three ',' and '.' endings do have an elegance to them.

Elixir is nice in that it is similar enough to Julia that I can copy and paste pieces of code and make minor edits to translate. Even javascript is relatively similar if map/reduces are used. Python is a bit harder due to white space blocks and list comprehension.

The ,.; line endings are a PITA when you refactor. I've heard them referred to as 'ant turd tokens'. It's a minor nitpick though, I still like Erlang a lot.

lol, that's a unique description. A good linter could fix them, but they drive me crazy. I tend to shift lines around more than any other editing.

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.

> 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.

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

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)

True when you have all the dependencies already compiled. If you are working with it in Docker though, it needs to compile the whole shebang the first time you start it up. It usually took 3+ minutes to get the day started. And any time an additional library was added to config, had to be restarted again.

As opposed to something like go, which compiles in seconds typically. Naturally, different folks will have different experiences depending on how it's used. For myself, the long compile time was a turn off.

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.

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.

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.

Yep, GP mentions in another comment that they misinterpreted the error.[0]

Anyway, Python replaces the prompt ">>> " with "... " if the input is mid-statement, and I suppose it would be nice if Eshell did the same thing.

[0]: https://news.ycombinator.com/item?id=22799222

This whole thread is going in my "Humility" file, not only did I misinterpret the error this one time, I've been messing around at the Erlang REPL putting a space after each command for absolutely no reason <headdesk>.

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).

Oh, that makes sense! Thanks to both you and moreoutput.

My argument is wrong then-- this isn't shockingly bad anything, just a little quirkiness.

I think part of it is that the shell is not the most forgiving of syntax errors, and Erlang doesn't always give the clearest syntax error description.

It's always been correct by line number for me, but I usually have to read that and the line above/below to understand what my actual errors are.

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.

what is this, 2009? If your language cares about it, Your code editor should automatically convert CRs and tabs as you type.

Every language in existence is able to deal with default windows files. Zig -intentionally- breaks on carriage returns and tabs. It went out of its way to not work.

I think that's a wise choice. The zig ecosystem doesn't need people that get hung up on that.

Hung up on what? Working? Please explain why this problem that would take 30 minutes to correct makes sense to keep around?

Reply on news.ycombinator.com