From the release announcement on the mailing list:
Some of the highlights are:
* Optimized handling of processes in the VM
* New internal process table allowing for parallel reads and writes
- optimized run queue management
- optimized process state changes
* "Non-blocking" code loading
* New internal port table, and rewrite of scheduling of port tasks.
* Dynamic allocation of port structures, allowing the default for maximum ports to be raised to 65536 (from 1024) Support for UTF-8 encoded Unicode characters in source files.
* Inets application: The http client now support HTTPS through a proxy
* Asn1 application: Major cleanup of back ends and optimizations of mainly decode for PER and UPER.
* The experimental features parameterized modules and packages are removed. An alternative compatible solution
for parameterized modules is provided here https://github.com/erlang/pmod_transform.
* All built in functions BIF's (even if they are implemented in C as part of the VM) are now visible in the
source code of the module they belong to, including their type specs.
* The Wx application now compiles and is usable with the unstable development branch of wxWidgets-2.9. This means that wx can now be built on 64 bit MacOsX as well.
For those new to Erlang conventions, the "A" in the release number is an indicator that this is a beta release. The stable releases are the "B" branches. So in this case, R16B will be the stable version.
The pmod arguments have been a pretty ongoing war[1] on the mailing list, especially since it was announced R16 would be removing official support for them.
With ChicagoBoss being one of the highest profile projects to use pmods extensively, Evan Miller has been arguing for them pretty extensively.
At least support wasn't completely dropped, since they are providing the parse_transform to re-enable the functionality:
Erlang is not a tinkerers language. If you want to tinker you want Scheme, Clojure or Haskell, which to a far greater extent plays around with new ways of doing things in programming languages.
Erlang is about providing a stable platform and controlled additions. The decision to remove parameterized modules must be balanced against the fact that you are maintaining an experimental extension and that it complicates the compiler. So the decision was made to remove them completely from the language in order to pave the way for a better solution.
One of Joe Armstrongs ideas is that if you add a new feature to the language, you must remove one as well. So the choice is all about balancing the effort required to keep parts of the implementation working.
It isn't that Evan Miller as not been heard and taken seriously. Believe me, the decision is not a quick one made just for the sake of making such a choice.
In Erlang, pmods are problematic because the language has no type system and they seriously mess with readability of program code. They also make it harder to grep in code, and there are very simple ways to work around the lack of them. And they are not the feature we need to make the language better. There are a large amount of other features which would be far better to have.
I'm well aware of the technical merits of the decision and generally agree with it (I upvoted you because of the clear explanation, btw). What rubs me the wrong way are comments like (emphasis mine):
"And they are not the feature WE need to make the language better"
and
"Looking over Elixir, I tend to agree with Tristan -- it seems to have
all the syntactic sugar that creative, non-hardcore, easily frightened
developers might like"[0]
You seem to have forgotten to quote the next paragraph which says, "In seriousness, it looks like a nice language -- I wonder if it, or the Ruby, Python, JavaScript "front-end" toolsets, might be a better fit for extending Erlang applications to programmers who are looking for a kinder, gentler syntax?"
Garret spends a fair amount of energy trying to make Erlang more accessible.
You're approaching this wrong; they do take the little and big people seriously. It's also a 20(?) year old language with a lot of features! You can't possibly add/remove everything everyone wants - I think the team behind Erlang is doing an exceptional job of maintaining stability while getting new features and cleaned up releases out.
Also - my own startup uses Erlang extensively (we use Riak, yes, but our actual application is built on top of Erlang too); I would say 80% of our codebase consists of Erlang. It's rock solid and the concurrency and distribution features (and ease of use) are unmatched. Also - OTP, nothing compares to OTP yet (Akka is trying to get there, but they have a long journey ahead of them).
I've been trying to learn a little erlang for a while. One of the things that holds me back is the external libraries. If it's a part of erlang/OTP, then great, usually I'm happy with it.
But it's hard to find, install, and update external libraries compared with many other languages (like haskell/cabal, ruby/gems, etc.). How do you deal with that on a practical level?
There isn't a central clearing house at the moment. But the conventions is to use a tool called "rebar" and you simply add a dependency in your rebar.conf like
and then it will use cowboy's rebar.conf to download what it requires, in this case ranch. So, you can just link to the top level library you care about it most cases and let rebar deal with it.
After asking around on IRC, I found out about CEAN, which looks like it's trying to be a central clearing house. But it's a little strange looking compared to ones that I'm used to... it doesn't look very community-oriented. I couldn't even find a license file for CEAN itself.
But it looks like rebar offers a lot already, so I'll look into that more.
Oh wow. I didn't know you were doing Erlang these days. (You know me as StoneCypher.)
Welcome to the flock. You're a very good programmer, assuming you're the person that I knew from efnet #c++, and the community will be improved for having you around.
Evan has a point regarding the verbosity of many expressions and there have been very complete enhancement proposals that are much better in what they cover and their properties. See for example Richard O'Keefe's 'Frames' proposal: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf
This doesn't mean his points and concerns are not valid, and it also doesn't mean that parametrized modules should stay. I think the compromise made (still support them, but not in the main OTP distribution) is a decent one, because it takes little effort to keep old code compatible, stuff still works, but the issues mentioned in my post linked above are no longer a concern of whoever is using or implementing libraries with features that were built on a weird implementations like tuple calls.
It also allowed a much simpler error handler with new very interesting mechanisms when similar features were cleaned up.
I think the community is open to change of the language, given that the idea you propose is a good one.
The thing that led tarcieri to write the "Erlang is a Ghetto" post was that he proposed the addition of Ruby-style blocks to the Erlang language. And then Richard O'Keefe wrote back a post—not a very diplomatic one—which explains why Ruby-style blocks is a horrendously bad idea to add to any language.
The main reason that Erlang sometimes comes along as smug is because there are some people in the community who are extremely capable in their fields of expertise. You need a good argument to convince a semanticist that your informally specified language extension is worth anything, unless you can supply meta-theorems which explains why. Or at least provide proper semantics. In other words, you need a really good design.
If you have working code for your design, it is even better. If you have an EEP (Erlang Enhancement Proposal) you may even have your idea implemented. There is, for instance, an EEP called "Named funs" which extends and generalizes tarcieris proposal. It did not go in in time for R16, but it is still being worked on.
Parameterized modules were an experiment. Like Tuple funs (now removed), packages (now removed), and mnemosyne (now removed). They still live on outside the Erlang distribution but retains enough inside to support them via parse transformations.
"
You are confronted with the problem of wasting a lot of time writing
basement level code to access and update deep values. You think "Great!
I can write DSL or combinators to solve this!". Now you got two
problems, and you haven't come any closer to solving the first one. The
DSL still maps to functions which needs to access and update these
values, and that code is still painful to write. Your next step is to
think "Great! Let's generate all that code then!". Now you got three
problems, and you better hope to have not made any error when writing
that code generator or you'll waste a lot more time. Speaking of time,
by the time you get to that point the PHP developer has already long
finished his bug-free implementation of the same code and is moving on
to other tasks."
I think the problem is that Erlang does some things extremely well, which leads to people getting a bit smug about it, in a way that sometimes reminds me of "photography purists" sniffing at digital photography as being so very clearly sub-par, a few years ago.
My reality is that for a lot of the web stuff I do, the faster development time that Rails gives me is worth way more than a bit of speed / better use of resources. I don't need a redundant site with 0 downtime, I need to figure out if there's a market for what I'm working on, and/or pivot and add features as I begin to understand things better.
+1 for Chicago Boss, though, it's a solid effort that tries to push Erlang in some interesting directions. I do think I'll be using it for a project soonish, as the specs involve a lot of piping data around, and websockets, stuff that Rails is not as good at.
I'm pretty comfortable with Erlang, actually, having used it on and off for the past 9 years. Elixir looks cool, but a bit too experimental for what I'm working on. Chicago Boss makes me a bit nervous from that point of view too, for that matter... so we'll see what route we end up taking. Evan Miller, for the record, is really great about responding to bug reports and code ideas, so that is a big plus about the project.
The community is anything but a ghetto. Everyone I've interacted with is both highly intelligent, helpful, and very opinionated about the future of the language.
One of Erlang's strengths is its stability; they get their stability from being really picky about some things.
This particular question highlights a shortcoming of long-form changelogs though. It would be nice if there was a way to have community-voted highlighting of a changelog pointing out the significance of each line-item of a changelog.
Some of the highlights are:
* Optimized handling of processes in the VM
* New internal process table allowing for parallel reads and writes
- optimized run queue management
- optimized process state changes
* "Non-blocking" code loading
* New internal port table, and rewrite of scheduling of port tasks.
* Dynamic allocation of port structures, allowing the default for maximum ports to be raised to 65536 (from 1024) Support for UTF-8 encoded Unicode characters in source files.
* Inets application: The http client now support HTTPS through a proxy
* Asn1 application: Major cleanup of back ends and optimizations of mainly decode for PER and UPER.
* The experimental features parameterized modules and packages are removed. An alternative compatible solution for parameterized modules is provided here https://github.com/erlang/pmod_transform.
* All built in functions BIF's (even if they are implemented in C as part of the VM) are now visible in the source code of the module they belong to, including their type specs.
* The Wx application now compiles and is usable with the unstable development branch of wxWidgets-2.9. This means that wx can now be built on 64 bit MacOsX as well.
You can find the README file with more detailed info at http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDAT...