Stuff Goes Bad: Erlang in Anger | Hacker News Reader

Stuff Goes Bad: Erlang in Anger

engineering.heroku.com

292 pointsmononcqc51 comments

For those who don't know, this is by the author of:

Which has the same clear, detailed and very approachable writing style.

Erlang really needed a book like this that goes into some of what happens with real, non-toy applications. Hopefully he'll continue to add to it!

For what it's worth, LYSE is one of the few paper books I've purchased in recent years - it's really good, and very clearly a labor of love.

Hopefully he'll continue to add to it!

The PDF has a version # in the file name -- text.v1.0.1.pdf -- so your hope may well not be in vain :-)

This should have been updated to text.v1.0.2.pdf roughly 8 hours ago. I fixed issues with the running header, page numbering, and a few content issues pointed out to me.

Great work!

BTW Fred is also the author of Learn You Some Erlang For Great Good:

http://learnyousomeerlang.com/

As he put it, a lot of these tips and tricks end up preserved in local company folk tradition and eventually get lost. This way the whole community gets to benefit. Many thanks, Fred!

Some of these things I've seen on Erlang's mailing list. Some saw in Erlang Factory talks, some are mentioned on #erlang channel. But having them in one place is quite nice.

Some more detailed things I like:

* There are a good number of Erlang resources targeting beginners. This one targets advanced users as well.

* Focused on maintenance and debugging. A successful product will always have that aspect. It is often overlooked.

* Nice semantic layout of chapters -- explanation of how things work, then hands-on sections/example sessions, then exercises and open ended questions for further thinking and discussing.

Wow, great book. Worth reading alone for chapters 7-9 which deal with debugging running process.

I hope they get fleshed out a bit more.

I wish more technical books would dive into the inner workings of the language like this. https://realworldocaml.org/ was the only other book I've read in the past few years that has done this.

I might be the exception in the book buying crowd but I don't want a book to teach me the syntax, I want to know how to debug my process, what tools are available and which ones the experts use.

For those that want to get started, I've been reading the Erlang Thesis^1. It's a really good read. I recommend it even if you don't plan on learning Erlang because it will teach you why it's difficult to build reliable systems when processes can share mutable state.

1: http://www.erlang.org/download/armstrong_thesis_2003.pdf

For anyone who's interested in Erlang (or functional programming in general) but thinks it looks a bit daunting, check out Elixir.

It's a new language which has just turned 1.0, has Ruby/Python like syntax and runs on the Erlang OTP VM (kind of like how clojure runs on the JVM). This gives you all of the amazing concurrent power which has helped the Heroku guys here.

Check it out!: http://elixir-lang.org/

Also review previous discussions of Elixir for pointers to additional resources:

https://news.ycombinator.com/item?id=8007383 (july)

https://news.ycombinator.com/item?id=7622280 (april)

For anyone who's interested in Elixir (or functional programming in general) but thinks it looks a bit daunting, check out Erlang.

It's a stable production language which has just turned 17.3, has extensive resources, and runs on its own VM (kind of like how Java runs on the JVM). This gives you all of the amazing concurrent power which has helped the Heroku guys here.

Check it out!: http://erlang.org/

I love a good troll :)

I'd say: evaluate both and pick what suits you.

Indeed.

Yeah trying both is definitely the best way to go about it.

But be aware that all of Erlang's libraries and support ecosystem are available to you when you use Elixir.

But all of Elixir's support and ecosystem are available to you from Erlang, only if you install elixir.

Yes, but Elixir gives you some awesome things (on top of everything available in Erlang obviously) - macros, Ecto (LINQ for Postgres) and pipe operator are my top 3.

NB: I don't use it at work or anything, just read up on it during free time.

Haha! That's very true.

The reason I'm promoting elixir instead is because I feel that it's easier to pick up in terms of how different it is from imperative and OO languages.

While you are right in how Erlang has a much longer reputation, it's odd though how it hasn't gained much popularity like other languages that have been around for that long.

Elixir seems only syntactically different, to me (with a few nifty feature additions). Erlang is a syntax for BEAM more than anything.

What makes Elixir easier to learn for OO programmers?

Three things that make the experience of developing in Elixir completely different from Erlang: Tooling, libraries, and actual language features (that aren't just skip deep).

Spend 5 minutes developing an app in Elixir and you'll realize why it's not just "only syntactically different" from Erlang.

I gave credit insofar as language features, hygienic macros and pipe ops are both wins in my book.

Which libraries and tools do you think set Elixir apart? Do you prefer it to erlang (I've seen you in #elixir-lang ;)?

Here's an old (18 months ago) exhibition of Elixir's improvements upon Erlang oddities and difficulties:

http://devintorr.es/blog/2013/01/22/the-excitement-of-elixir...

As an elixir programmer who loves erlang, programming elixir is programming erlang (compiles down to the same thing). It makes some things a lot easier than they are in erlang- a lot- and syntax is just one of them.

But the really are, in a fundamental way, the same "language".

Elixir is just a lot easier for newbies, and rubyists.

I think it's prettier and more fun, which is why I choose it, but I switch to erlang when needed, and regularly use erlang libraries in my elixir projects.

When two languages have different scoping rules, they don't have the same semantics. When two languages differ in their opinion about macros, they don't have the same semantics.

When two languages have different semantics, they are different languages.

And finally, when two languages have fundamentally different syntaxes, the idioms promoted by their creators differ, and thus problems are solved in different ways.

They are not fundamentally the same language, no.

Erlang and Elixir aren't the same language, but they do share a pretty unique architecture in OTP. When people talk about "the advantages of Erlang" they're frequently really talking about OTP (that, or BEAM's reduction-counting ISA.) So people think it's Erlang that gives you those advantages.

Of course, it's not; any language that targets BEAM could pick up those advantages "for free", in the same way Clojure gets a bunch of Java libraries "for free." But people compare programming languages, not abstract machines or library ecosystems. If you treat Erlang and Elixir as black boxes, hiding BEAM and the OTP (the way someone who doesn't know either language would), then they seem to be much more similar to one-another than any other language is to either of them.

Sharing a common subset does not make them "fundamentally the same language".

>they seem to be much more similar to one-another than any other language is to either of them.

"language"

Quotes don't magically let you say wrong things.

Scoping rules? I what way do they differ? Honest question.

Variables in Elixir can be rebound, and there are no unsafe variables at all in Elixir.

I wouldn't call it "scoping" difference, although I can see why one would think about it as such. It would be a real scoping issue if you could assign variables in outer scopes from inside the nested scopes. Can you?

You can. And even if you couldn't, what I mentioned is still different scoping rules, whether you put scare quotes or not.

> what I mentioned is still different scoping rules

You're probably right, I don't want to argue about terminology.

What do you mean by "scare quotes"? Honest question: English is my second language and I'm not very good with it.

> You can.

You're wrong. Here, take a look:

    iex(4)> f = fn() -> a = 0; (fn()->a=9 end).(); a end
    #Function<20.80484245/0 in :erl_eval.expr/5>
    iex(5)> f.()
    0

f.() should evaluate to 9 if what you said was true. Either there's a special syntax for doing this in Elixir (like nonlocal in Python 3) or it's absent, and then the scoping rules are the same in Elixir and Erlang, with a bit of syntactic sugar for SSA transformation, which you need to do by hand in Erlang.

Again, I'm not Elixir programmer, so this is a honest question: is there some special syntax which would make the example above produce 9? I doubt it very much because it wouldn't fit very well with BEAM, but everything is possible and I'd be glad to learn about another nice feature of Elixir.

You introduced a closure there. Bindings set in if, case, receive, etc will spill in their surrounding environment. Obviously they won't spill outside closures without mutable terms, which BEAM lacks.

The bits about SSA transformation needed to be done by hand in Erlang are a bit fun, because that's considered a feature in the Erlang realm.

The scoping rules aren't the same for the very reason you dismiss as an implementation detail.

Scare quotes: http://en.wikipedia.org/wiki/Scare_quotes

> The scoping rules aren't the same for the very reason you dismiss as an implementation detail.

Ok, this means that I need to learn some more about how scoping rules are defined and described, because apparently my current understanding is incompatible with the common one. That happens all the time if you're self-taught like me, so I simply accept this.

Thanks for discussion and the "scare quotes" term :)

Wow -- I consider this "The Missing Manual" for Erlang production developers. A lot of this you learn over time -- as you work on production systems, but this will cut down the pain significantly.

Nice to see another boon to the community come from Fred.

Wow, Fred has been providing a massive service to the community. It's great to see someone continually producing high quality, open source, technical prose (for Erlang).

Joe Armstrong approves:

https://twitter.com/joeerl/status/512575633122021377

This is awesome, I can't wait for this to go into print, so I can pay you for your work! But in the meantime, many thanks for writing this.

It is pretty much never going to be printed. The book has to remain available for free and never for profit according to the deal I've taken internally with Heroku to work on it.

The only way it gets printed is if Heroku decides it feels like allocating time and resources getting this printed by working with a publisher, which is way outside our usual line of work there.

I don't see the incentive for the corporation to do this, financially or otherwise.

Ok, I'll more copies of learnyousomeerlang instead :)

Wouldn't it be pretty easy to make it available on Lulu.com or something?

I read the online version of LYSE and it really helped me understand the language and how to use it. Additionally you've helped answer questions along the way and have always been a big contributor to the community.

I've just bought a hard copy of LYSE to say thanks. I own almost no physical books these days, but you are worth it. Thank you!

Any chance it could be made available in HTML format? Converting to epub is much easier that way...

I tried tools like pandoc and they promptly choked on the latex. Every code sample that had an _ was problematic, and that issue likely didn't come alone.

is it possible to put the source files on gitub (i ask because the book is CC licensed. I understand if you are not keen on that idea.), so that i can take a gander at converting it using pandoc?

I'll possibly do it. I have to think.

The issues I can see with putting the source itself open is receiving pull reqs, which quickly turn into an issue of copyrights and form-waiving and all kind of stuff I'm not comfortable running around with.

I have a friend who's currently playing with making the conversion work with far more determination than I have, though.

A great testimonial

Can i buy mobi version somewhere?

Nope. Not for sale. Always for free.

I will be looking into whether it's possible to do decent conversions from LaTeX -> [epub, mobi] later this week, and then figure out how to make that available, if it goes well.

pandoc: http://johnmacfarlane.net/pandoc/

See example: https://github.com/karlseguin/the-little-redis-book [The little Redis book, written entirely using pandoc]

Pandoc exploded on the first code sample with an underscore it met. Too bad.

Like! :)

Impressing.

Reply on news.ycombinator.com