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

71–80 of 103 posts

Re: Erlang/OTP 24 highlights

#71

Post by jolux »

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'm not a huge fan of Dialyzer myself. I would put it strongly in the "much better than nothing" category rather than the "usable and useful type system" category. I always write specs for my functions and types, and while they sometimes catch bugs, they're not quite as expressive as I would like them to be.

I suppose you could write Elixir in a style that was more type safe by writing in a less polymorphic or recursive style, but the language does not lend itself well to it. Structs and maps are mostly fine, discriminated unions less so.

Re: Erlang/OTP 24 highlights

#72

Post by elcritch »

lawik wrote: post #62
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 th…

I love the notion of co-located processing and data, but most of the data stores dont quite embrace it. Well actually Riak does quite well if you're fine with a dynamo like kv store. The riak library is actually pretty nifty for distributed computations. But with Basho out of business it's harder to justify. Plus KV stores really aren't as usable as good ole sql. In that realm there's ActorDB, but I've not been able to figure out how to run it inside my own beam cluster rather than standalone.

Re: Erlang/OTP 24 highlights

#73

Post by jerf »

sgrytoyr wrote: post #45
losvedir wrote: post #32

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…

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

That's awesome to hear. I think there's a lot of language communities in the 10+ year range (and look, that's right where Elixir is) could stand to have that recognition. I'm getting kind of saddened by the number of languages I see that are good languages that proceed to festoon themselves with so many new features that they become quite difficult to use.

Re: Erlang/OTP 24 highlights

#74

Post by di4na »

niho wrote: post #65

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 simp…

Part of the problem here is that dialyzer is a quite ... spaghetti codebase, that noone really want to fund that work and that noone really knows how this stuff work that is interested in doing that work.

There is a lot of research work to do and noone to pay for it. That said, if you know of a company interested to fund this work, i am interested and would love to hear more about it.

Re: Erlang/OTP 24 highlights

#76

Post by josevalim »

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…

FWIW, I recently pushed a commit to master that made loading of Elixir's test suite 33% faster (from 15s to 10s): https://github.com/elixir-lang/elixir/commit/2eb03e4a314c0e6...

Unfortunately, it is a bit too large (and too late) for v1.12, but if loading times have been problematic for you, it would be awesome if you could try master out and let us know in the issues tracker (or in the commit) if you see any improvements.

Re: Erlang/OTP 24 highlights

#77

Post by vendiddy »

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'm in the same boat. Love Elixir, but I always found the typespecs to be a huge pain (and slow!) vs. type systems like typescript.

I'd love to see experiments to replace typespecs with a more ergonomic type system.

Re: Erlang/OTP 24 highlights

#78

Post by mindfulmore »

cuddlecake wrote: post #69
mindfulmore wrote: post #55

Earlier quoted context omitted.

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.

I've kept an eye on Gleam. Essentially all of the programming I do is based around the web so I'm kind hoping a web framework shows up at some point.

Re: Erlang/OTP 24 highlights

#79

Post by QuinnWilton »

cuddlecake wrote: post #69
mindfulmore wrote: post #55

Earlier quoted context omitted.

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.

For what it's worth, I spoke last year about using Gleam to develop a type-safe core for a LiveView application: https://www.youtube.com/watch?v=UCIcJBM_YDw

I think that what you're looking for is already possible today, and that things only get easier over time.

Re: Erlang/OTP 24 highlights

#80

Post by ramchip »

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)

There's a comment here: https://blog.erlang.org/the-road-to-the-jit/#maturing-the-ne...

I feel like I saw graphs in one of the presentations, but I don't recall which, or if it was about the final iteration of the JIT.

I suspect HiPE would beat the JIT on tight loops, but the JIT wins in general because of the lack of switching cost between native and interpreted code.

Post reply on HN