Live data from Hacker News

Erlang/OTP 24 highlights

blog.erlang.org

51–60 of 103 posts

Re: Erlang/OTP 24 highlights

#51

> there are still 260k lines of code added and 320k lines removed So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That's praiseworthy IMO. Imagine if "we did more with less" infected much of software development today.

Imagine if we had a metric of "how easy is the code to understand and work with" rather than "can we do it with less lines of code".

Re: Erlang/OTP 24 highlights

#52
post #46

> there are still 260k lines of code added and 320k lines removed So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That's praiseworthy IMO. Imagine if "we did more with less" infected much of software development today.

Recently I read somewhere that writing long prose is easy but writing something succinct takes way longer. I think that translates to writing code as well.

Brevity is the soul of wit.

Re: Erlang/OTP 24 highlights

#53

BeamASM vs HiPE? Since BeamASM doesn't support HiPE - has anyone seen benchmarks of BeamASM (JIT) vs HiPE. I've searched and searched and can't find such analysis. (Super excited the JIT work is seeing light after 10+ years)

HiPE support is getting wonky, I don't know if many people use it, and I'm not sure it supports the latest OTP versions.

The Erlang folks are looking for maintainer volunteers to continue working on HiPE support, they don't have the manpower right now to maintain it themselves.

Re: Erlang/OTP 24 highlights

#54
post #46

> there are still 260k lines of code added and 320k lines removed So a net reduction of 60K lines of code? And yet functionality was added to the system as well. That's praiseworthy IMO. Imagine if "we did more with less" infected much of software development today.

Recently I read somewhere that writing long prose is easy but writing something succinct takes way longer. I think that translates to writing code as well.

“ I only made this letter longer because I had not the leisure to make it shorter.” Blaise Pascal

Re: Erlang/OTP 24 highlights

#55

Earlier quoted context omitted.

Totally agree. I have just a few remaining complaints about the language at this point, and Kernel.tap/2 and Kernel.then/2 will solve two of them. When Jose mentioned a few years back that Elixir the language was more or less "done" or at least stable, and that they would focus on ergonomics and UX going forward, I remember getting a little worried. But I’ve found myself agreeing more and more - there’s not much I mi…

As someone who has been programming with Elixir for my day job for the past few years, I find this aspect of the language to be super pragmatic and productive. It's a nice feeling to not have to chase new language features and syntax and focus more on the problem at hand. In addition, I've never felt limited by the language given that the underlying constructs are so powerful (message passing, immutability, pattern m…

Curious, do you use typespecs and dialyzer? If so, how do you find it?

Elixir checks pretty much every box I'd want in a language, but after dealing with nil in Ruby for years and having fun with TypeScript... I'm feeling more drawn to working with type systems.

Re: Erlang/OTP 24 highlights

#56
post #40

Slightly off-topic from someone who hasn't touched Erlang in almost 20 years: if my app is distributed with Erlang/Elixir, I kind of feel like my choice of database should be something with excellent horizontal scaling too. Can someone offer some insight into the trends in 3rd-party tools like databases for Erlang applications?

Erlang already comes with a distributed DBMS called Mnesia https://erlang.org/doc/man/mnesia.html , which under the hood uses ETS/DETS depending on the configuration. In distributed Erlang projects you'll find that or abstractions over it. Mne sia makes the most sense in mu opinion when you only have 1-2 relations or just need some kind of distributed cache. In Elixir apps you'll frequently find the aforementioned Ec…

The one sort-of thorny piece with Mnesia is querying the DB. The syntax for select is not super straightforward and involves writing matchspecs (http://erlang.org/doc/man/ets.html#match-specifications) which are non-trivial.

Mnesia lets you do a lot of cool things (in memory DB by default! Super fast!) but it also has some pitfalls (Doesn't write to disk by default! Lose all your data when you restart the BEAM!).

Generally, I think it's a fine system if you're willing to put in the time to optimize it.

Re: Erlang/OTP 24 highlights

#57

BeamASM vs HiPE? Since BeamASM doesn't support HiPE - has anyone seen benchmarks of BeamASM (JIT) vs HiPE. I've searched and searched and can't find such analysis. (Super excited the JIT work is seeing light after 10+ years)

I believe HiPE is going away in the future.

Re: Erlang/OTP 24 highlights

#59

Earlier quoted context omitted.

As someone who has been programming with Elixir for my day job for the past few years, I find this aspect of the language to be super pragmatic and productive. It's a nice feeling to not have to chase new language features and syntax and focus more on the problem at hand. In addition, I've never felt limited by the language given that the underlying constructs are so powerful (message passing, immutability, pattern m…

Curious, do you use typespecs and dialyzer? If so, how do you find it? Elixir checks pretty much every box I'd want in a language, but after dealing with nil in Ruby for years and having fun with TypeScript... I'm feeling more drawn to working with type systems.

Answering from similar experience. I personally use them both, dialyzer as part of the Elixir Language Server and typespecs when I feel something needs more clarity and definition.

Depending on what itches your types scratch for you it might be enough, might not. I've never wanted more type system in my Elixir personally.

Re: Erlang/OTP 24 highlights

#60

OMG, YES! The JIT is here... and holy crap, if you haven't tried it yet... it's awesome (everything feels snappier). I'm particularly stoked for the receive optimizations and process aliases. BEAM just gets better and better. It's a good time to be an Erlanger/Elixirist...

It's noteworthy that the JIT doesn't (yet?) do runtime optimization or specialization, so gains should be moderate. The very low end of double digits. Not comparable to going from a Javascript interpreter to v8. But it's a great starting point.

From my recollection (interviewed OTP team on this stuff once) they don't really intend to go there either. They are a very small team comparatively and maintaining that kind of runtime optimization would likely be unwieldy. (https://devchat.tv/elixir-mix/emx-114-just-in-time-for-otp-2...)

It won't be anything like V8, entirely correct, but it brings some VM code to native performance, beating NIFs in some cases.

I think some RabbitMQ tests reported 30% increase in throughput which is pretty wild.

Post reply on HN