Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Erlang/OTP 24 highlights

blog.erlang.org

Post reply on HN
Print view View original

61–70 of 103 posts

Re: Erlang/OTP 24 highlights

#61

Post by lawik »

latch wrote: post #39
rubyn00bie wrote: post #37

Earlier quoted context omitted.

`mix test` _is_ fast for me... I've only seen slow tests when folks are misusing timeouts (generally speaking); what problem are you seeing?

The delay is all in compiling exs files. It uses Kernel.ParallelCompiler to compile every .exs file, so it's very CPU/core dependent. On my weaker laptop, `mix test` takes nearly 10 seconds to just start. I've looked into this in more details in the past. We've had success just writing our own test runner and avoiding exs files. But re-implementing things like running tests based on line number, or integrating with e…

Really? I'm surprised that is your test bottleneck. I've mostly seen it be actually slow tests and things that can't be asynced.

Re: Erlang/OTP 24 highlights

#62

Post by lawik »

mrslave wrote: 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?

I've had interesting exchanges with a guy who does work on CouchDB. That is built with Erlang and should scale quite well in what sounds like a resilient way. Haven't dug in.

Horizontal scaling of the DB seems like a problem in many architectures. For SQL I'd be looking at CockroachDB as it is Postgres-compatible and is built with scaling out in mind. Haven't tried it though. Most of my work hasn't needed that for the DB recently.

Re: Erlang/OTP 24 highlights

#63

Post by toast0 »

tiffanyh wrote: post #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)

I'm not sure if there's a point in the history where you can run with (this) JIT or with HiPE on the same commit. Which makes an apples to apples comparison difficult. If you compare HiPE on OTP 23 with JIT on OTP 24, you're also getting the large amount of other changes as well.

Both HiPE and this JIT have drastically different improvements depending on the specific code that's running, which makes it challenging to have a real world benchmark as well.

Re: Erlang/OTP 24 highlights

#64

Post by benzible »

lawik wrote: post #60
the_duke wrote: post #42

Earlier quoted context omitted.

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…

Seems like WhatsApp / Facebook would benefit by contributing some resources towards this...

https://twitter.com/garazdawi/status/1385263924803735556

Re: Erlang/OTP 24 highlights

#65

Post by niho »

Improved error messages is great. But one area specifically that is in desperate need of some love is the type errors from Dialyzer. They are rarely helpful to identify what is actually wrong in the code. Typically the error message will point to something several layers up or down in the call stack and prints out a huge blob of unreadable and unhelpful type signatures. Most of the time the best you can do is to simply compile and run the system to figure out what is wrong with the types. The obscurity of the type errors remind me of C++ template errors.

Re: Erlang/OTP 24 highlights

#66

Post by dnautics »

mindfulmore wrote: post #55
akoutmos wrote: post #50

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.

I find working with nil in Elixir to be quite reasonable. One way in which elixir is different is that you have different operators for when it must be boolean, and nil is not tolerated for those operators (and vs &&). This coupled with the convention of using ? at the end of functions which emit boolean makes things easier.

The one thing I wish is that people stopped writing boolean functions with is_ in front (that is supposed to be only for guards, but not everyone follows that convention).

Re: Erlang/OTP 24 highlights

#67

Post by watermelon0 »

deeviant wrote: post #51
travisgriggs wrote: post #25

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

Those two are not exclusive.

Re: Erlang/OTP 24 highlights

#68

Post by lawik »

benzible wrote: post #64
lawik wrote: post #60

Earlier quoted context omitted.

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…

Seems like WhatsApp / Facebook would benefit by contributing some resources towards this... https://twitter.com/garazdawi/status/1385263924803735556

Arguably, yes :)

Re: Erlang/OTP 24 highlights

#69

Post by cuddlecake »

mindfulmore wrote: post #55
akoutmos wrote: post #50

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.

If you want type systems, you can probably work with Gleam, in the future, I imagine there could be great interop where you can just drop in a .gleam file in your elixir code base with zero hassle attached, and have parts of your code base that are completely type safe, and let Elixir handle all the risks of IO and other effects.

But, this might just be my wishful thinking.

Re: Erlang/OTP 24 highlights

#70

Post by ericmj »

latch wrote: post #39
rubyn00bie wrote: post #37

Earlier quoted context omitted.

`mix test` _is_ fast for me... I've only seen slow tests when folks are misusing timeouts (generally speaking); what problem are you seeing?

The delay is all in compiling exs files. It uses Kernel.ParallelCompiler to compile every .exs file, so it's very CPU/core dependent. On my weaker laptop, `mix test` takes nearly 10 seconds to just start. I've looked into this in more details in the past. We've had success just writing our own test runner and avoiding exs files. But re-implementing things like running tests based on line number, or integrating with e…

What made your test runner faster? We would be very interested in porting those optimizations to ex_unit.
Post reply on HN