10 ms·
Erlang/OTP 18.0 has been released
- stevedomin 11y agoThis is great news for Elixir as well!
- thibaut_barrere 11y agoMy thoughts exactly. I've never been so excited about seeing a new Erlang release :-)
- spand 11y agoAnything noteworthy ? :-)
- tachion 11y agoHow 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 11y agoRandom 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.
- thibaut_barrere 11y agoThat's not what I meant! It's that I've witnessed Erlang releases for quite a long time (as everyone), but the coming of Elixir (and me starting using it) made me care about them.
- rubiquity 11y agoTwo really nice enhancements are efficient large maps and being able to use variables as keys in maps. Also switching to the Apache license will make adoption of Erlang/Elixir more possible for certain organizations. Elixir also gets to reap any performance improvements at runtime and compilation.
- fithisux 11y agoStill non mingw or mingw-w64 or (windows) clang friendly.
- jlouis 11y agoI 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.
- sarciszewski 11y agoObligatory: https://www.youtube.com/watch?v=rRbY3TMUcgQ https://www.youtube.com/watch?v=rRbY3TMUcgQ
- brucify_ 11y agoFor 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 11y agoCan 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 11y agoIt 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.
- brucify_ 11y agoThe previous versions of Erlang were using the Erlang Public License 1.1, a modified Mozilla Public License adapted with Swedish laws. https://en.wikipedia.org/wiki/Erlang_Public_License https://en.wikipedia.org/wiki/Erlang_Public_License
- jlouis 11y agoSomething 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.
- passwordis 11y agoIsn't HAMT Phil Bagwell ?
- istvan__ 11y agoNo 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.
- masklinn 11y agoYes. QuickCheck the original property-based test library, initially for Haskell then commercially ported by the original author to Erlang (as Quviq QuickCheck) http://www.cse.chalmers.se/~rjmh/QuickCheck/ http://www.cse.chalmers.se/~rjmh/QuickCheck/ http://www.quviq.com/products/erlang-quickcheck/ http://www.quviq.com/products/erlang-quickcheck/
- jlouis 11y agoThe 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.
- bandris 11y agoThe 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 11y agoIt totally makes sense that a highly concurrent system would need to start getting really nitty-gritty with time values...
- qohen 11y agoFred Hebert, author of Learn You Some Erlang has a new postscript to the book about the new way time will be handled in Erlang 18+ : http://learnyousomeerlang.com/time http://learnyousomeerlang.com/time (BTW, there's also a talk from Erlang Factory by Lukas Larsson on the subject: https://www.youtube.com/watch?v=gfsc2MyP8p8&list=PLWbHc_FXPo2h0sJW6X2RZDtT1ndw6KKpQ&index=18 https://www.youtube.com/watch?v=gfsc2MyP8p8&list=PLWbHc_FXPo... )
- throwaway12357 11y ago> 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 11y agoYou 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.
- shockzzz 11y agoCommits like this make me realize, "oh, they're just developers like me" https://github.com/erlang/otp/commit/37f143e9e16e89d753b0e5e4415968dbcd5f6b65 https://github.com/erlang/otp/commit/37f143e9e16e89d753b0e5e...
- endymi0n 11y agoSee, this would not have happened if they had coded this project in a purely functional language.
- lectrick 11y agoIt would not have happened if that logic was covered by tests :O
- jlouis 11y agoYes and no. Erlang/OTP has a pretty extensive test suite which takes several hours to run. There is a nightly test run on a multitide of architectures. So it is some times the case that a fault is caught at night and fixed the following day. The Erlang/OTP team runs a mantra where everything is covered by tests and they are doing a really good job at what they are doing. So I would not be surprised to see this having been caught by a test.
- deeviant 11y agoExactly, 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 11y agoFor example, Erlang was originally implemented in prolog.
- jflatow 11y agoI 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).
- nodivbyzero 11y agoGreat news, guys... keep it up!!!
- GGMethos 11y agoOUTLAW TECHNO PSYCHOBITCH