
A History of Erlang (2007) - vinnyglennon
https://dl.acm.org/doi/abs/10.1145/1238844.1238850
======
callamdelaney
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.

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

~~~
dnautics
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](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.

------
mycall
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...](https://www.codementor.io/blog/worst-
languages-2019-6mvbfg3w9x)

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

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

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

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

