Really like the new Erlang 27 docs https://www.erlang.org/doc/readme.html
[deleted]
Erlang/OTP 27 Highlights
31–40 of 53 posts
Re: Erlang/OTP 27 Highlights
#32Hyped about json becoming a first class citizen. As an Elixir engineer and daily Jason user it will be great to rely on stdlib functionality. Jason is great, regardless!
Reading the notes it appears it was implemented by Michał Muskała who also implemented Jason (and seems it is faster too)
Re: Erlang/OTP 27 Highlights
#33Earlier quoted context omitted.
Tasks are not processes, and that would be a wrong thing to do, and so would be "isolated heaps" given performance requirements faced by .NET - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. CSP, while is nice on paper, has the same issues as e.g. partitioning in Kafka, just at a much lower level where it…
> and that would be a wrong thing to do, and so would be "isolated heaps" - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. It depends on the context. In some contexts absolutely not. If we share memory, and these tasks start modifying global data or taking locks and then crash, can those tasks be safely r…
What value does isolated heap offer for memory-safe languages?
Task exceptions can simply be handled via try-catch at the desired level. Millions of concurrently handled tasks is not that high of a number for .NET's threadpool. It's one thing among many that is "nothingburger" in .NET ecosystem which somehow ends up being sold as major advantage in other languages (you can see it with other features too - Nest.js as a "major improvement" for back-end, while it just looks like something we had 10 years ago, "structured concurrency" which is simple task interleaving, etc.).
It's a different, lower-level model, but it comes with the fact that you are not locked into particular (even if good) way of doing concurrency in Erlang.
Re: Erlang/OTP 27 Highlights
#34The `maybe_expr' meta pattern matching fallback mechanic is nice, and can surely help avoid a lot of boilerplate code while simultaneously encapsulating the logic in a structure which is easy to read and reason about. It's also not a thing in any other programming language I've learned- C, Java/Scala/C#/C++, Go, Javascript, Tcl, Bash(lol), PHP, Forth, ML, and so on. I had to look up it's usage though, because I'm new…
You do realize that Rust, C#/F#, Kotlin/Scala, now Java to an extent, pretty much all FP and many other languages have extensive pattern matching support?
Re: Erlang/OTP 27 Highlights
#35The `maybe_expr' meta pattern matching fallback mechanic is nice, and can surely help avoid a lot of boilerplate code while simultaneously encapsulating the logic in a structure which is easy to read and reason about. It's also not a thing in any other programming language I've learned- C, Java/Scala/C#/C++, Go, Javascript, Tcl, Bash(lol), PHP, Forth, ML, and so on. I had to look up it's usage though, because I'm new…
You do realize that Rust, C#/F#, Kotlin/Scala, now Java to an extent, pretty much all FP and many other languages have extensive pattern matching support?
In fairness, it's doing a bit more than "just" pattern matching. It's very similar to the `with` expression in elixir: https://hexdocs.pm/elixir/1.16.3/Kernel.SpecialForms.html#wi...
You can use it to execute a series of functions returning `either`-ish tuples and build up a railway oriented program.
Re: Erlang/OTP 27 Highlights
#36Earlier quoted context omitted.
> and that would be a wrong thing to do, and so would be "isolated heaps" - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. It depends on the context. In some contexts absolutely not. If we share memory, and these tasks start modifying global data or taking locks and then crash, can those tasks be safely r…
What value does isolated heap offer for memory-safe languages? Task exceptions can simply be handled via try-catch at the desired level. Millions of concurrently handled tasks is not that high of a number for .NET's threadpool. It's one thing among many that is "nothingburger" in .NET ecosystem which somehow ends up being sold as major advantage in other languages (you can see it with other features too - Nest.js as…
GC determinism is one of the things you get. Another one is non cooperative asynchronous termination.
Re: Erlang/OTP 27 Highlights
#37Really like the new Erlang 27 docs https://www.erlang.org/doc/readme.html
Finally. I never liked erlang doc style.
Re: Erlang/OTP 27 Highlights
#38Earlier quoted context omitted.
this. Erlang's concurrency support is one of those things you can't unsee. Going back to sequential-by-design languages (which is pretty much every other industrial quality language bar go[1]) just feels cumbersome: C/C++/C#/Python/...: "You want concurrency? Sure. We have OS processes, and threads, and this cool new async doohickey. Pick whatever you fancy! Oh, but by the way: you can't use very many processes cos t…
C++: zero-cost leaky abstraction with unlimited cognitive and development cost Functional programming languages: Unlimited good abstractions of unknown cost I don't feel like there's a great third option. Go is pretty good.
I hate to be that guy, but if you want "C++ but also functional programming" then... Well, then Rust is in fact the language which you're looking for.
Re: Erlang/OTP 27 Highlights
#39Earlier quoted context omitted.
What value does isolated heap offer for memory-safe languages? Task exceptions can simply be handled via try-catch at the desired level. Millions of concurrently handled tasks is not that high of a number for .NET's threadpool. It's one thing among many that is "nothingburger" in .NET ecosystem which somehow ends up being sold as major advantage in other languages (you can see it with other features too - Nest.js as…
GC determinism is one of the things you get. Another one is non cooperative asynchronous termination.
Pretty much all efficient GC implementations are inherently non-deterministic, even if predictable.
How can this improve predictability of GC impact?
Re: Erlang/OTP 27 Highlights
#40Earlier quoted context omitted.
> and that would be a wrong thing to do, and so would be "isolated heaps" - you do want to share memory through concurrent data structures (which e.g. channels are despite what go apologists say), and easily await them when you want to. It depends on the context. In some contexts absolutely not. If we share memory, and these tasks start modifying global data or taking locks and then crash, can those tasks be safely r…
What value does isolated heap offer for memory-safe languages? Task exceptions can simply be handled via try-catch at the desired level. Millions of concurrently handled tasks is not that high of a number for .NET's threadpool. It's one thing among many that is "nothingburger" in .NET ecosystem which somehow ends up being sold as major advantage in other languages (you can see it with other features too - Nest.js as…
Briefly, the tradeoff that Erlang and its independent process heaps model make is that garbage collection (and execution in general) occurs per-process. In practical terms, this means you have lots of little garbage collections and much fewer "large" (think "full OS process heap") collections.
This provides value in a few ways:
- conceptually: it is very simple. i.e., the garbage collection of one process is not logically tied to the garbage collection of another.
- practically: it lends itself well to low-latency operations, where the garbage collection of one process is able to happen concurrently to the the normal operation of another process.
Please note that I am not claiming this model is superior to any other. That is of course situational. I am just trying to be informative.
This is a good post with more information, if you're interested: https://hamidreza-s.github.io/erlang%20garbage%20collection%...