I'm going to miss those `badarg` errors :D
Found the person who likes writing an in-house ETS wrapper on every new job!
Erlang/OTP 24 highlights
21–30 of 103 posts
Re: Erlang/OTP 24 highlights
#22I'm going to miss those `badarg` errors :D
I know you're being sarcastic but I will definitely not miss those when working with Elixir......
Re: Erlang/OTP 24 highlights
#23Working 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...
Re: Erlang/OTP 24 highlights
#24Sometimes I'll sit there, look at the error trying to decipher it, and I forget who I am and what I was doing.
Great work on the improvements!
Re: Erlang/OTP 24 highlights
#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.
Re: Erlang/OTP 24 highlights
#26I love the new error messages. Rust seems to have started that trend, Python also added better errors recently.
> Rust seems to have started that trend,
No it didn't. Lets not try to rewrite history here, clang started the trend of meaningful error messages, gcc quickly caught up.
Re: Erlang/OTP 24 highlights
#27I love the new error messages. Rust seems to have started that trend, Python also added better errors recently.
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.
Re: Erlang/OTP 24 highlights
#28Nice update on the error message!
Speaking of error message. I love that Erlang gives the exact parameter values in the call stack. (I guess this is generally possible because immutable data structures are enforced in the whole language?) It saves a lot of time than just speculating with call stack only.
Re: Erlang/OTP 24 highlights
#29OMG, 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...
Re: Erlang/OTP 24 highlights
#30Earlier 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.
Does -fdiagnostics-plain-output not do what you want?