
Erlang/OTP 18.0 has been released - johlo
http://www.erlang.org/news/88
======
jlouis
Something you may find interesting is that the new faster maps are loosely
based on Rich Hickey's HAMT implementation that is used in Clojure. Jose and
co. in Elixir adapted/is-adapting their internals to use maps as well, as they
were faster than any implementation they had.

In addition, I wrote a full QuickCheck model for the new maps. That is, we
randomly generate unit test cases for the maps and verify them. We have
generated several millions of those test cases, including variants which
heavily collides on the hash. This weeded out at least 10 grave bugs from the
implementation, which in turn means this release is probably very stable with
respect to maps.

~~~
istvan__
No surprise there, Rich's code is pretty solid. I really like this sort of co-
operation between languages.

Out of curiosity: QuickCheck is a property based test library? I know of
test.check in Clojure and they mention QuickCheck as the inspiration, so I
guess they re similar in this regard.

~~~
jlouis
The base is the same, but Quviq QuickCheck for Erlang provides some libraries
which are far more developed than most QuickCheck implementations out there.
On the other hand, it is not a free tool if you want the full version.

Since you are searching randomly, you need good heuristics that skews the
distribution toward where "errors often occurs". This means errors are
uncovered in fewer test cases. Also, you need good heuristics for
minimizing/shrinking a known failing error. Some of the error cases shrank
from 80 commands down to 5, and furthermore simplified the input so it was
easier to see what stood out.

------
brucify_
For the first time Erlang 18 shipped under Apache License 2.0, it will likely
have a meaning for Erlang's future development. The Industrial Erlang User
Group has spent quite some effort on that.

~~~
MCRed
Can you explain why, or link to a summary of the history? Wasn't it a license
specific to erlang in the past? If so that's great as Apache is standard. But
if it went from another common license I'm curious to know why.

~~~
nosequel
It didn't come from another common license. It came from the EPL (Erlang
Public License
[http://www.erlang.org/EPLICENSE](http://www.erlang.org/EPLICENSE)). Erlang
users have been asking for the change for years and OTP 18 finally delivered
on the promise.

------
shockzzz
Commits like this make me realize, "oh, they're just developers like me"

[https://github.com/erlang/otp/commit/37f143e9e16e89d753b0e5e...](https://github.com/erlang/otp/commit/37f143e9e16e89d753b0e5e4415968dbcd5f6b65)

~~~
endymi0n
See, this would not have happened if they had coded this project in a purely
functional language.

~~~
deeviant
Exactly, because if it was a purely functional language, they would have
started the project, worked on it for a week, blog about it and said purely
functional language for a year, then throw it away.

~~~
fanf2
For example, Erlang was originally implemented in prolog.

------
bandris
The improved time handling is the biggest new feature for most users probably
(apart form maps improvements and the new license).

[http://www.erlang.org/doc/apps/erts/time_correction.html](http://www.erlang.org/doc/apps/erts/time_correction.html)

~~~
lectrick
It totally makes sense that a highly concurrent system would need to start
getting really nitty-gritty with time values...

------
stevedomin
This is great news for Elixir as well!

~~~
thibaut_barrere
My thoughts exactly. I've never been so excited about seeing a new Erlang
release :-)

~~~
spand
Anything noteworthy ? :-)

~~~
tachion
How come you havent noticed?! The number! 18! Come on, Ruby is on 2, Python
struggles to get to 3 and Java tries to catch poorely with 8...

~~~
coldtea
Random numbers (18 vs Python's 3 or Java's 8) don't mean anything without
comparing the release cycles and version numbering schemes as well.

I could make small incremental updates to a toy language and release them
every week to get to FooBarLang 200.0.0, that doesn't mean it's progressing
faster than a language at release 2 or 10.

~~~
Conlectus
That's the joke.

~~~
coldtea
Maybe add the /s then?

It's amazing how many people actually confuse version numbers this way,
including on HN (check any discussion about semver).

------
jflatow
I love Erlang releases and am very happy about the improvements to maps. I
have to admit the OTP motto of "move slow and never break anything" always
leaves me wanting more (though).

------
sarciszewski
Obligatory:
[https://www.youtube.com/watch?v=rRbY3TMUcgQ](https://www.youtube.com/watch?v=rRbY3TMUcgQ)

~~~
qohen
Might be worth watching this first, though:

[https://www.youtube.com/watch?v=xrIjfIjssLE](https://www.youtube.com/watch?v=xrIjfIjssLE)

------
fithisux
Still non mingw or mingw-w64 or (windows) clang friendly.

~~~
jlouis
I think a patch for this would be welcomed. Usually there are some subtle
complications from such ports which tend to also affect other systems. So
fixing it in one place often helps other porting efforts as well.

------
throwaway12357
> ssl: Remove default support for SSL-3.0 and added padding check for TLS-1.0
> due to the Poodle vulnerability.

> ssl: Remove default support for RC4 cipher suites, as they are consider too
> weak.

I'm not following Erlang news but was just wondering, aren't these fixes
coming out way too late?

~~~
jlouis
You could tell the `ssl` application to avoid SSL-3.0, TLS-1.0 and RC4. Here
is an explanation by RabbitMQ:

[https://www.rabbitmq.com/ssl.html](https://www.rabbitmq.com/ssl.html)

It is different from an end-user application in the sense that you can
configure this in a safe way, and that has indeed been the typical workaround.

Now we just make it impossible for people to misconfigure this in any way.

The fix was also backported to 17.5 w.r.t the padding for TLS-1.0.

Another point worth mentioning is that Erlang/OTP uses OpenSSL, but only for
the cryptographic ciphers. `ssl` is a complete standalone implementation of
TLS in Erlang and this automatically avoids a lot of trouble. The common case
is that an attack on OpenSSL leaves the `ssl` application unaffected by the
error.

------
nodivbyzero
Great news, guys... keep it up!!!

