12 ms·
Erlang/OTP 25.0 Release
- out_of_protocol 4y ago* The JIT now works for 64-bit ARM processors, including M1 * The JIT now does type-based optimizations based on type information in the BEAM files.
- igouy 4y agoPreviously (Erlang/OTP 24 highlight) "The BeamAsm JIT-compiler has been added to Erlang/OTP and will give a significant performance boost for many applications. The JIT-compiler is enabled by default on most x86 64-bit platforms that have a C++ compiler that can compile C++17."
- mikl 4y agoEasily the best feature in this release if you do your dev work on an Apple Silicon Mac (or Raspberry Pi, I guess?). Also great if you have the option of deploying on AWS Graviton or similar.
- nifoc 4y agoHighlights: https://www.erlang.org/blog/my-otp-25-highlights/ https://www.erlang.org/blog/my-otp-25-highlights/
- tonyg 4y agoThe new `maybe ... end` looks nice.
- sph 4y agoAt first sight it looks like Elixir's `with` expression.
- rkangel 4y agoIt is very much that. The Erlang team have not been too proud to steal good ideas from Elixir. Elixir has been a good source of fresh thinking for the BEAM ecosystem which has helped both the Erlang and Elixir side.
- mononcqc 4y agoThe Erlang 'maybe' expression expands on what 'with' allows in Elixir, mostly because the 'with' construct allows a list of conditional patterns and then a general 'do' block, whereas the Erlang 'maybe' allows mixed types of expressions that can either be conditional patterns or any normal expression weaved in together at the top level. It is therefore a bit more general than Elixir's 'with', and it would be interesting to see if the improvement could feed back into Elixir as well! The initial inspiration for the 'maybe' expression was the monadic approach (Ok(T) | Error(T)) return types seen in Haskell and Rust, and the first EEP was closer to these by trying to mandate the usage of 'ok | {ok, T}' matches with implicit unwrapping. For pragmatic reasons, we then changed the design to be closer to a general pattern matching, which forced the usage of 'else' clauses for safety reasons (which the EEP describes), and led us closer to Elixir's design, which I felt was inherently more risky in the first drafts (and therefore I now feel the Erlang design is riskier as well, albeit while being more idiomatic). So while I did get inspiration from Elixir, and particularly its usage of the 'else' clause for safety reasons, it would possibly be reductionist to say that "the good ideas were stolen from Elixir." The good ideas were stolen from Elixir, but also from Rust, Haskell, OCaml, and various custom libraries, which have done a lot of interesting work in value-based error handling that shouldn't be papered over. I still think these type-based approaches represent a significantly positive inspiration that we could ideally move closer to, if it were possible to magically transform existing code to match the stricter, cleaner, more composable patterns that they offer. In the end I'm hoping the 'maybe' expression still provides significantly nicer experiences in setting up business logic conditions in everyday code for Erlang user, and it is of course impossible to deny that I got some of the form and design caveats from the work done in the Elixir language already :) Also as a last caveat: I am not a member of the Erlang/OTP team. The design however was completed and refined with their participation (and they drove the final implementation whereas I did the proof of concept with Peer Stritzinger and wrote the initial EEP), but the stance expressed in my post here is mine and not the one of folks at Ericsson.
- deleted 4y ago[deleted]
- rcarmo 4y ago...with JIT support for ARM processors, which is quite interesting.
- jacquesm 4y agoHave there been benchmarks of the JIT vs say JS or the JVM?
- innocentoldguy 4y agoHere's a good comparison between Elixir, Go, and Node: https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi... Some of the things I like better about Elixir and Erlang vs. Go and Java are: - In Elixir/Erlang, all processes are stored in private memory and can only be accessed via defined message interfaces. In both Go and Java, processes are stored in public memory. - Elixir/Erlang processes are a lot smaller, memory-wise, than Go/Java processes. - We moved all of our development at my current company from Java to Elixir because Elixir, being functional, makes writing multi-threaded applications a lot faster/easier. Elixir is also cheaper to deploy. At least that has been our experience. - I like the syntax of both Elixir and Erlang better than Go, Java, or JS. - I don't have as much experience with Node/Express, but in my limited testing with Node/Express vs. Elixir/Phoenix, the latter is several times faster and much more scalable. It also makes better use of hardware (which I believe is discussed in the link above). I hope at least some of this helps answer your question.
- rkangel 4y agoI think the focus has been more on comparing the JIT'd code vs the unJIT'd previous VM approach and looking at the speedups.
- out_of_protocol 4y agoErlang JIT is still very simple, unlike highly optimized super complex V8 jit. It's faster than non-jit erlang, sometimes twice as fast, but nowhere near nodejs-fast. Erlang team don't have resources to make and maintain such complex beast. (everything said here is about raw performance)
- andy_ppp 4y agoThe JVM is nearly as fast as hand optimised C, this is not intended to be that fast, rather a simple bedrock to build further optimisations into. Immutable everything also will limit performance as will the focus on latency at the cost of everything else. Not sure of actual performance compared to JVM though, I wonder if it’s as far away as I expect…
- clone1018 4y agoHighlights blog post here: https://www.erlang.org/blog/my-otp-25-highlights/ https://www.erlang.org/blog/my-otp-25-highlights/
- benwilson-512 4y agoARM support for the JIT is a great addition for any of us on an M1! I believe on Intel the JIT was improving compile times by 30-50%.
- Jeff_Brown 4y agoI taught myself Erlang last year and loved it until I tried to write an application. The OTP documentation, while voluminous, was confusing and seemed to have important omissions, and I found little if any community.
- innocentoldguy 4y agoOTP is different, but there are a lot of good resources for understanding it. I liked: Elixir in Action. The Little OTP Book. Designing Elixir Systems with OTP. Pragmatic Studio's Elixir OTP course.
- davydog187 4y agoThere is a huge community, not just in Erlang, but in the larger BEAM ecosystem. Have you tried the Erlanger or Elixir slack? We also have https://erlangforums.com/ https://erlangforums.com/ and https://elixirforum.com/ https://elixirforum.com/. For smaller BEAM languages like Gleam, we have Discord available https://discord.com/invite/Fm8Pwmy https://discord.com/invite/Fm8Pwmy There's a lot of great stuff in the BEAM ecosystem, I would caution on writing it off too fast
- Jeff_Brown 4y agoI know there's a lot of power there. Whatsapp was written in OTP and had something like half the world using it with a development team of maybe 12. I'm glad to hear the community is bigger than what I found. I don't actually remember that search process. What I remember clearest was running into the brick wall of the OTP documentation.
- davydog187 4y agoI'm not sure on your exact timeline, but the documentation has also seen several upgrades. For example, see the "telemetry" library, written in Erlang and published to the Hex repository. Its documentation is built using the Elixir-based ex_doc https://hexdocs.pm/telemetry/readme.html https://hexdocs.pm/telemetry/readme.html
- 4y ago
- haolez 4y agoI've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.
- yumaikas 4y agoIf you're wanting to use Elixir, it's not going to be nearly as mainstream as, say, Node, but fly.io has support for Elixir apps (to speak of cloud), and I think there's some cool stuff going on in Elixir myself. Of other note is that Erlang seems to enable folks that use it to punch above their weight class when it comes to running services internally and such. Serverless is far from the only valid way to run things these days.
- brightball 4y agoIMO people represent what they know. People also overestimate what “the new” is, constantly. Otherwise, PHP would be dead by now rather than flourishing. Serverless is essentially PHP in CGI mode, with a lot of marketing behind it. There are certainly places where it’s beneficial. Servers and databases are not going away anytime soon. They are simply too effective for what they do. The “everything is legacy crowd” hasn’t been correct about almost anything in my lifetime. Mainframes are still going strong. SQL databases are better than ever and the NoSQL crowd has largely died out. 90% of the cloud ecosystems of today are just doing what Java app servers were doing in the late 90s. Erlang and the BEAM offer a set of trade offs that happen to be ideal for a lot of server based use cases to make hard things really simple. Probably not going to take over the world but if it fits what you do you probably won’t want to go back.
- deckard1 4y ago> NoSQL crowd has largely died out. yeah, that was rather curious. Similar to how XML died out. Not with a bang but with a whimper. Not that NoSQL or XML are completely gone today, just like PHP. But suddenly one day you recognize these topics are no longer appearing on HN or elsewhere. Then you realize you're getting old and... oh my god... we're actually stuck working in a fashion industry and nothing matters, life is meaningless, and all this is dumb dumb dumb. When HN and other techies find a new hammer they end up beating that hammer against every problem they see. Right now it's SQLite. I love SQLite. But man. Can we quit talking about it for one fucking day already? This is probably how it felt to be an Erlang fan when Facebook bought WhatsApp. I remember the decades of Joe Armstrong talking about Erlang on Usenet and no one caring. It's just cargo cult with no thought behind it. WhatsApp was successful using X, so if we use X we must be successful. People have this perception that Python is new and modern despite being, relatively speaking, the same age as Perl. Erlang was cool long before WhatsApp. It's really quite old tech.
- haolez 4y agoI've seen more than once recently an engineer saying that software solutions outside of the Serverless ecosystem (FaaS, DB, etc) is "the new legacy". And that cloud providers have solved all the pains that Erlang was supposed to address. What's your feeling on this? Elixir sounds very compelling to me, but I worry that I might be going in a direction that's not where the industry is going.
- davydog187 4y agoServerless? You mean vendor lock-in, distribution issues and reproducibility issues, etc?
- haolez 4y agoYeah. There are obvious downsides, but what if your competitor.manages to outperform you with such tools? That's my concern
- conradfr 4y agoOutperform in which aspect?
- haolez 4y agoDeliver more features, faster.
- davydog187 4y agoYour competitor beat you while you were rewriting your product to be serverless
- rawoke083600 4y agoHaha :D Too True !
- 4y ago
- tiffanyh 4y agoWith the JIT foundation now set in Erlang/OTP 24 & 25, I can only hope that we'll begin to see massive perf improvement in Erlang/OTP 26. (Thanks you to Lukas and all others who work on this)
- di4na 4y agoI mean we already got a stable 25% or more improvement, to the point that Jason is faster than NIF based json library... we already saw massive perf improvement with the JIT
- mattbaker 4y agoGood news for anyone deploying to Graviton too
- terom 4y agohttps://youtu.be/rRbY3TMUcgQ https://youtu.be/rRbY3TMUcgQ 2013 and still totally relevant Outlaw Techno Psychobitch FTW
- lenkite 4y ago> The JIT now works for 64-bit ARM processors. Does this mean mobile apps in Erlang is not far off ?
- lvass 4y agoI don't see any serious attempt at UIs with erlang. I think erlang processes would provide a great foundation for UI components, but has it even been tried?
- jolux 4y agoErlang comes with a binding to wxWidgets that is used to implement the graphical debugger and observer it comes with, but they are fairly utilitarian in their styling and I don’t know of any other Erlang/Elixir GUI apps. Which is to say: it probably could be done, but doesn’t seem to be popular even among Erlang programmers.
- the_duke 4y agoNot really, because UI components inherently need tight integration for event propagation, layouting, drawing... Sure, you could render individual components in their own processes and have one process accumulate a render tree , but I don't see much sense in that. The lack of GC also is a problem, so you might have to do each redraw in a fresh process or something like that to avoid accumulating too much memory. Processes would be good for all sideline functionality like API/db requests and expensive computations.
- outlog 4y agoI'm in elixir land - but have a look at https://github.com/elixir-desktop https://github.com/elixir-desktop - they even have an ios app in the app store.. basically wxwidgets comes with a webview, and that one is loaded up - and everything is packaged as an app - so you can use phoenix (liveview), or even react or anything to your liking.. believe certain improvements were made to OTP 25, so multiple things will land soon - even livebook https://github.com/livebook-dev/livebook https://github.com/livebook-dev/livebook are aiming at shipping a native app..
- 4y ago
- sergiomattei 4y agoIs Elixir running on OTP 25?
- innocentoldguy 4y agoYes. I'm currently using OTP 25.0 and Elixir 1.13.4 and it is working fine.
- Kototama 4y agoNot yet, you can use OTP23 or OTP24 at the moment with latest Elixir 1.13. Check https://hexdocs.pm/elixir/1.13/compatibility-and-deprecations.html#compatibility-between-elixir-and-erlang-otp https://hexdocs.pm/elixir/1.13/compatibility-and-deprecation...
- conradfr 4y agoAlthough changelog says: > v1.13.4 (2022-04-07) > This release has been verified to work with Erlang/OTP 25 RC2.
- Kototama 4y agoAh nice, I missed that!
- ricketycricket 4y ago1.13.4 is verified on OTP 25 RC2, so I'd assume it supports the release OTP 25. See: https://github.com/elixir-lang/elixir/releases/tag/v1.13.4 https://github.com/elixir-lang/elixir/releases/tag/v1.13.4
- distortedsignal 4y agoHaving worked with erlang for some time now, https://www.erlang.org/eeps/eep-0049 https://www.erlang.org/eeps/eep-0049 is _very exciting_ to me. One of the issues that I have with the codebase that I'm in is deep nesting, which could be solved with this feature. Very compelling. (HN mods: feel free to delete this comment or my comment at https://news.ycombinator.com/item?id=31426002 https://news.ycombinator.com/item?id=31426002, since they're the same content)
- barkerja 4y agoThis is great. I hope this finds its way to Elixir land.
- linkdd 4y agoThis already exist with the `with` expression, no?
- kemiller 4y agoYeah, `with` is pretty much this.
- dugmartin 4y agoIt is already there with the "with" macro. The EEP doc calls it out: https://www.erlang.org/eeps/eep-0049#elixir https://www.erlang.org/eeps/eep-0049#elixir "This is the most general control flow in this document, being fully flexible with regards to which values it can handle. This was done in part because there is not a strong norm regarding error or valid values in either the Erlang nor Elixir APIs, at least compared to other languages here. This high level of flexibility has been criticized in some instances as being a bit confusing: it is possible for users to make error-only flows, success-only flows, mixed flows, and consequently the ˋelseˋ clause can become convoluted."
- deleted 4y ago[deleted]
- di4na 4y agoThanks to the EEF for funding my work on the float to string algorithm! And also, if you wonder if you could do it for your current platform of choice, please do not engage. Inside float to string conversion lies madness...
- nanis 4y agoDoes no one proof-read any more? > New PRNG added to the rand module, for fast pseudo-random numers.
- lytedev 4y agoIn one sense, I totally understand your point. In another, I still got the message so who cares?
- robocat 4y agoAre strings in Erlang rather inefficient? Or does the memory usage or string performance not matter in practice? I have always ignored anything related to Erlang because I dislike the idea of a language that lacks an efficient string representation . . . even though I have spent over a decade using JavaScript! (so maybe I don’t actually care?)
- rdtsc 4y agoThere are binaries and strings. Binaries is what are used as efficient "strings" most often these days. Binaries allow matching, even building bitstrings (binary strings not ending on an 8 bit boundary). Even more interesting, strings and binaries can be combined in iolists, which is an arbitrarily nested or combined list of binaries or other lists. Those can be used for efficient IO and IO drivers know how to emit or consume those. For additional details I recommend https://adoptingerlang.org/docs/development/hard_to_get_right/ https://adoptingerlang.org/docs/development/hard_to_get_righ... which also mentions how unicode is handled. It turned out quite a bit easier because of how Erlang represents strings.