Thank you and congratulations to the team! I’m honestly surprised it’s already out, I somehow thought the rc period was going to be much longer.
It’s been amazing to see how development on this progressed as well as how much care and thought is put into it. Looking forward to the next steps! 
I’m pretty sure they mean something like Haskell’s Maybe, Rust’s Option, Scala’s Option or Gleam’s Option.
It would be nice, but unless you can be sure that no nil values are allowed for any type (static at least), then I’m not sure that it would be that useful.
I guess I’d rather use something like GitHub - CrowdHailer/OK: Elegant error/exception handling in Elixir, with result monads. · GitHub.
That was my initial reading but then I started wondering. Thanks.
I don’t think those are coming anytime soon to Elixir, if ever. Maybe if the gradual typing can prove [non-]exhaustive pattern-matching then the road will be opened for that.
That’s up for the community to validate and report their findings.
We have our option/result types in Elixir with tuples and pattern matching: {:ok, value} or :error or {:ok, value} or {:error, reason}. Exhaustive pattern matching is the only missing piece of the puzzle.
In which version do you think that could happen, José? 
Not sure what the prerequisites are.
No ETA yet. We are working on it though! The announcement outlines the next challenges ahead.
FYI / production data point, in case it’s useful or anyone hits something similar.
We run a SaaS app (Enaia) and upgraded Erlang/OTP from 28 to 29 and Elixir from 1.19.5 to 1.20 in the same release. Shortly after, one LiveView mount started OOM-killing the machine: the BEAM grew to ~5.9 GB RSS and got killed by the kernel. As far as we know, this only ever manifested for a single user’s data (our automated monitoring account), so it looks data-dependent rather than universal.
After reverting to OTP 28 / Elixir 1.19.5, the exact same code path loads in ~0.2s and allocates ~4 MB (measured as a BEAM total-memory delta). So the same data and the same code went from ~4 MB on 1.19/OTP28 to ~5.9 GB on 1.20/OTP29, roughly a 1,400x difference.
We haven’t isolated which operation explodes yet (it’s an Ecto query with preloads feeding some map building), and we don’t have a minimal reproduction; reverting was the priority to keep prod healthy. Since we jumped both OTP 29 and Elixir 1.20 together, we also can’t yet attribute it to one or the other.
Sharing as an FYI for now rather than a bug report. We’ll try to reduce it to a minimal repro at off-peak hours and follow up if we get something concrete.
(cc @josevalim )
Congrats! And thanks for the write-up, I finally actually understand how dynamic() works 
Really interesting and very cool.
Hi all, I’m Neil’s colleague. Looks like it’s data issue which was spotted thanks to fixed monitoring and unfortunately we released Elixir 1.20 shortly after fixed monitoring. For now it looks not related to 1.20. I replicated same issue on 1.19.5. In case I’m wrong we will inform you about it again. Thanks