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.

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.

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

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.

I agree it's possible. The pertinent question is: how easy and ergonomic it is to do? Friction kills good innovation very often.

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.

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.

Answering from similar experience. I personally use them both, dialyzer as part of the Elixir Language Server and typespecs when I feel something needs more clarity and definition.

Depending on what itches your types scratch for you it might be enough, might not. I've never wanted more type system in my Elixir personally.

I generally verify types only at the boundaries of my application (or very critical modules) using norm[1].

Either you have a strict type system that does not have an "any" type (yes, I'm looking at you Typescript), or you have a flexible type system like Python/Erlang/Elixir and you do runtime type checking whenever it's needed.

I'm writing more Typescript code than I would in Javascript for almost no type safety benefits (but for documentation, it's awesome).

[1] - https://github.com/keathley/norm

Dialyzer and typespecs are better than nothing but not with much because they can introduce a lot of friction along the way, for not much benefit.

As another poster said, it can catch the very occasional potential bug but to me at least it's rarely worth the hassle.

I miss static typing after I got back to Elixir from Rust but the BEAM will likely never be statically typed.

To that end, I found utilizing metaprogramming to generate normal and property tests to be much more productive use of my time, with a measurable impact to boot.

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.

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