Live data from Hacker News

Erlang/OTP 24 highlights

blog.erlang.org

41–50 of 103 posts

Re: Erlang/OTP 24 highlights

#41
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?

Elixir has the excellent Ecto package which talks to many SQL dbs, Postgres being the default.

Re: Erlang/OTP 24 highlights

#42

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.

Re: Erlang/OTP 24 highlights

#43
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?

Postgres? ;) In all seriousness though, I wouldn't really expect database needs for Erlang & Friends to be that different from other languages. My current employer has a vertically scaled AWS RDS Postgres as companion for an Elixir app and it's worked great. (Ecto in particular is an excellent ORM.) If your app truly needs zero downtime or ultra-low latency then there are other options.

Re: Erlang/OTP 24 highlights

#44
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 Ecto "ORM", which has adapters to different DBMSs like MySQL, PostgreSQL, and even Mnesia.

Re: Erlang/OTP 24 highlights

#45

Working with Elixir on a daily basis is mostly a pleasure, but those "ArgumentError" errors have been super annoying. Looks like Elixir 1.12 will take full advantage of EEP 54: https://github.com/elixir-lang/elixir/releases/tag/v1.12.0-r...

Awesome, thanks for linking that! I was wondering how these improvements would flow through to Elixir. Looks like we get the JIT performance improvements for free. And unrelated to the Erlang/OTP changes, Elixir 1.12 looks awesome. Totally small, but such an unexpected little quality of life improvement, Kernel.then/2 for pipelines, looks great. I love the core team's focus on the UX of the language.

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 miss in the language itself, and projects like Nx, LiveView and LiveBook have shown that it’s an excellent foundation to build very powerful and modern stuff on top of.

Re: Erlang/OTP 24 highlights

#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.

Re: Erlang/OTP 24 highlights

#47

I love the new error messages. Rust seems to have started that trend, Python also added better errors recently.

Okay, lots of people arguing about this, so I'm gonna reply to you, the top-most person in this sub-thread :) I think the reason that it's easy to argue is that you can be talking about similar but slightly different things.

When Rust was created doesn't really matter, exactly. For a very long time, errors looked something like this:

  hello.rs:2:4: 2:16 error: unresolved name: print_with_unicorns
  hello.rs:2     print_with_unicorns("hello?");
                 ^~~~~~~~~~~~~~~~~~~
At some point, "improving the error messages" became a project goal, and Jonathan Turner decided to take this on. This is described in https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-com... . The post explicitly cites Elm as inspiration because Rust was directly inspired by Elm in this regard.

Yes, other languages may have started this trend earlier. Yes, maybe they influenced Elm, which influenced Rust. Yes, Rust may be "older" than Elm. But if you ask the people who began this effort, they will name Elm as the inspiration.

(And yeah, then you can try to argue about who has influenced the broader public, which is effectively impossible to prove, IMHO.)

Today that error looks like

  error[E0425]: cannot find function `print_with_unicorns` in this scope
   --> src/main.rs:2:5
    |
  2 |     print_with_unicorns("hello?");
    |     ^^^^^^^^^^^^^^^^^^^ not found in this scope
incidentally, and there's also JSON output, and if you're not on a terminal, you get the line numbers like before... lots of things are improved. This particular error doesn't show off some of the nicer things. Esteban Küber has taken up where Jonathan left off, and has been doing amazing work.

Re: Erlang/OTP 24 highlights

#48
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?

Probably CockroachDB (https://www.cockroachlabs.com/)? It's wire-compatible with postgres so any library with a postgres driver will work.

Re: Erlang/OTP 24 highlights

#49
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)

Re: Erlang/OTP 24 highlights

#50

Earlier quoted context omitted.

Awesome, thanks for linking that! I was wondering how these improvements would flow through to Elixir. Looks like we get the JIT performance improvements for free. And unrelated to the Erlang/OTP changes, Elixir 1.12 looks awesome. Totally small, but such an unexpected little quality of life improvement, Kernel.then/2 for pipelines, looks great. I love the core team's focus on the UX of the language.

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 matching, etc). Glad that Jose made the decision that he did.
Post reply on HN