Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Erlang R15B Released (erlang.org)
108 points by chops on Dec 14, 2011 | hide | past | favorite | 21 comments


This is great news: Line number and filename information are now included in exception backtraces


I have just subjected my coworkers to some happy shouting and a jaunty little dance over this news.

This has literally cost me man-days of lost productivity over the years I've been working with Erlang, and it just never made sense to me. Sure, compilers are hard, etc etc, but this is a basic thing. I've seen toy languages implemented as a proof-of-concept that will never see the light of day that managed to output line numbers with their errors. It's part of most "Baby's First Compiler" tutorials.


Yes! Although the absence of line numbers forced you to think through (in some cases) related code as well as the code that generated the error :)


For those of you stuck with R14B or earlier, Thomas Lindgren's smart_exceptions library will add line number information to exception backtraces: https://github.com/thomasl/smart_exceptions


When this was announced at EUC in Stockholm there was this palpable feeling of relief.

I had just spent hour wresting with a bug in a fn with many case clauses where the line number would have been fantastic...


Yes! I seriously thought it wasn't possible for some unknown FP related issue.


You will have incomplete stacktraces; tail calls will be removed from the stack trace. However, you'll be able to know where in the current call (and file) the error lies, which was a big problem in Erlang as soon as you had somewhat lengthy functions.


Why didn't they add this before? Lack of time to develop it, or no requests from developers wanting it? I find the latter hard to believe, and the former to be a more likely cause.


Because it isn't that useful in Erlang, so the want to have it has not been that big. Most (proper) Erlang programs happen to be a lot of small functions and you know what function caused the error and the error type to boot in addition.

This information is often enough to quickly figure out what is wrong. The trouble arises when you have a large function you did not break up yet because then finding the culprit is much harder.

While I like the change, there is a risk associated with it. Namely that people will be less inclined to break up their code.


Slightly paraphrased quote that I read somewhere: writing a compiler is easy. Writing a compiler with good error messages is the hard part.


Notable: The old (deprecated) 'regexp' module has been removed. So if any of your code relies on 'regexp', make sure you replace it with the newer 're' module and update your regular expressions accordingly.

It's nice to have that gone just to avoid confusion with the whole "why there are two regular expression modules?".


Off topic, but is there a recommended post detailing various online Erlang learning resources? I'm reading an O'Reilly book and playing around in the shell but I feel like I need more 3rd party resources to really grok what I'm reading.


http://learnyousomeerlang.com/

Inspired by Learn You a Haskell.

Haven't read all the way through it, but what I've seen looks good.

There's also http://www.tryerlang.org/ , which seems to be down right now.


Pragmatic Bookshelf's Programming Erlang book (written by Joe Armstrong, the inventor of Erlang) is a good starting point. If covers the basics of the languages as well as introducing ETS, OTP, and Mnesia.


And then there's also #erlang on freenode and the erlang-questions mailing list, the participants of which are quite friendly and helpful.


Also the book "Erlang and OTP in Action". Great next-step book after the PragPub one (or even just skip the PragPub one).


The System Documentation section of erlang docs has well written getting started guides: http://erlang.org/doc/ -- they were the only reference we had before these silly books started showing up a few years ago.

(implied: i was erlanging before it was cool. you probably hadn't heard of it back then.)

Just remember to learn Erlang in layers. Vague order of learning: base language/runtime, APIs, more runtime, more APIs, concurrency, behaviors, nodes, more APIs, multi-nodes, ports, drivers, nifs, ...


Anyone have any performance stats about the memory allocation improvements in erts? Couldn't find anything with naive Google queries..


Alleged drop in performance for some(+) R15A testers.

http://groups.google.com/group/erlang-programming/browse_thr...

Devs claim that it improved performance in their particular benchmarks. I guess the best is to try it for yourself.

(+) presumably those that tested and got a performance gain never bothered to write a ticket or a word of praise. so keep that fact in mind.


In addition, they did retry the tests later and found no performance drop.

But do carry out tests if you are hitting the performance ceiling. A particular use of a particular construct may be hampered when people rewrite a piece of code. So while the overall performance might improve, your case may not.


I'm looking forward to running the Windows 64-bit version on my new 4-processor 8GB Dell E6420 :)

Mik




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: