Live data from Hacker News

Erlang/OTP 24 highlights

blog.erlang.org

31–40 of 103 posts

Re: Erlang/OTP 24 highlights

#31

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

I was hoping our `mix test` would be faster, but it doesn't appear to be. It would be nice if this got some attention fro the Elixir team.

Re: Erlang/OTP 24 highlights

#32

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.

Re: Erlang/OTP 24 highlights

#33
post #30

Earlier quoted context omitted.

GCC also copied clang's excessive diagnostics and I'm seriously thinking of making a fork just to strip them out. I doubt the developers would accept a patch that implements --stfu.

Does -fdiagnostics-plain-output not do what you want?

    $ cc -fdiagnostics-plain-output c.c
    cc: error: unrecognized command-line option ‘-fdiagnostics-plain-output’

Re: Erlang/OTP 24 highlights

#34
post #17

Earlier quoted context omitted.

expressive diagnostics was one of clang's early selling points: https://clang.llvm.org/diagnostics.html Clang was released 2007 and was usable 2009/2010-ish. Rust dev started 2010. I'm not saying the trend of having good diagnostics was started by clang, but it's a more believable than the claim that it was started by Rust. -- Rust-the-language is nice, but the Rust community feeling the need to mention Rust on every…

GCC also copied clang's excessive diagnostics and I'm seriously thinking of making a fork just to strip them out. I doubt the developers would accept a patch that implements --stfu.

Every change breaks someone's workflow. But you are the closest I've seen to the person complaining here - https://xkcd.com/1172/

Re: Erlang/OTP 24 highlights

#36
post #4

Earlier quoted context omitted.

Rust was inspired by Elm, if I’m not much mistaken.

Rust was started in 2010, and Elm in 2012. https://en.wikipedia.org/wiki/Rust_(programming_language) https://en.wikipedia.org/wiki/Elm_(programming_language) That said, the concepts in question are all much older. If you're ever bored, check out the "Influenced by" sections of the Wikipedia pages on programming languages. It's amazing how old so many of the "new" ideas really are.

According to this:

https://en.wikipedia.org/wiki/Graydon_Hoare

Rust was started in 2006.

Re: Erlang/OTP 24 highlights

#37
post #31

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

I was hoping our `mix test` would be faster, but it doesn't appear to be. It would be nice if this got some attention fro the Elixir team.

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

Re: Erlang/OTP 24 highlights

#38
post #34

Earlier quoted context omitted.

GCC also copied clang's excessive diagnostics and I'm seriously thinking of making a fork just to strip them out. I doubt the developers would accept a patch that implements --stfu.

Every change breaks someone's workflow. But you are the closest I've seen to the person complaining here - https://xkcd.com/1172/

Yeah. It's funny how back in the day people used to make fun of excessively long compiler errors involving templates.

Now everyone seems to praise the compiler barfing three screenfuls of text and code and explaining the include hierarchy of my project and expanding all the macros and making bogus suggestions because I mistyped a variable name.

It's gotten to the point where locating the actual error message is literally more work than fixing the code. It doesn't help that this interferes with navigation in emacs and trying to jump to next error instead takes you to the next #include line gcc wants you to learn about.

Re: Erlang/OTP 24 highlights

#39
post #31

Earlier quoted context omitted.

I was hoping our `mix test` would be faster, but it doesn't appear to be. It would be nice if this got some attention fro the Elixir team.

`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 external tools (like excoveralls) has been a dealbreaker.

Re: Erlang/OTP 24 highlights

#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?
Post reply on HN