Erlang R15B Released
erlang.org
erlang.org
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.
I had just spent hour wresting with a bug in a fn with many case clauses where the line number would have been fantastic...
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.
It's nice to have that gone just to avoid confusion with the whole "why there are two regular expression modules?".
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.
(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, ...
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.
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.
Mik