Live data from Hacker News

Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

elixir-lang.org

41–50 of 170 posts

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#41
post #3

I'm excited about the type system so far, but I'm especially excited to hear about what else the type system is going to enable in the future. I remember José describing this as a "gradual gradual type system," where the gradual type system is going to be gradually added in stages, with this being the first stage. Any cool new type-system-related stuff coming up in the next few stages? I'm especially hoping for newly…

Doesn't gradual type system mean something else here? As in developers being able to iteratively add types while leaving untyped parts for later? At least this is how Ruby's Sorbet describes it

You’re right about what a gradual type system means! A gradual type system allows flexibility in how you approach typing a codebase. It also means that your system incorporates a dynamic type, making your types 'gradual'.

Interestingly, gradual set-theoretic types are flexible enough to let you gradually implement type inference for that system. Hence, the gradual gradual type system. :-)

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#42

Really impressed with how thoughtful _and_ fast they are delivering on their type system.

I'm really curious to know if many people with large Elixir problems are finding any issues with the new type system. This is pure curiosity, I don't have a dog in the fight!

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#43
I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience.

I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even without LiveView and realtime/channels, just using Elixir as a backend for a simple API has been really fun.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#44

Earlier quoted context omitted.

Yea I never bought this assertion from the TS team, saying “given the trade-offs at the time” is the same as saying “we’re already backed into a corner by previous decisions” - the decision(s) may have been intentional at each step but the design itself probably was not. Given the choice of sound or unsound, considering that the purpose of a type system is to give certain guarantees, a type system design must always…

Is the TypeScript team correct in explaining that soundness would exclude functions accepting subtypes as laid out there? If so, it seems like any type system that was meant to be able to type common JavaScript idioms would have to be unsound.

Sub-types can be represented with algebraic types so I’m not sure that’s necessarily true, for example an abstract class with subclasses can be represented as a sum type

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#45
post #43

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience. I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even wit…

You can use Phoenix without LiveView by running mix phx.new with the —no-live flag (or manually pull it out of an existing project).

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#46

Really impressed with how thoughtful _and_ fast they are delivering on their type system.

I'm really curious to know if many people with large Elixir problems are finding any issues with the new type system. This is pure curiosity, I don't have a dog in the fight!

José Valim already caught two bugs (one in Phoenix, one in Livebook) because of the type system: https://x.com/josevalim/status/1791409843888111667

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#47
post #43

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience. I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even wit…

You can use Phoenix without LiveView by running mix phx.new with the —no-live flag (or manually pull it out of an existing project).

But too the OPs point. This is not a technology that should be included by default. No matter how cool.

Saying this as a die hard Elixir fan who's been using it since 2015.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#48
post #43

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience. I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even wit…

You can use Phoenix without LiveView by running mix phx.new with the —no-live flag (or manually pull it out of an existing project).

Yes, I totally get that (and have been doing that). My complaint/suggestion is more around the marketing and messaging. There is so much more to Elixir than LiveView!

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#49
post #43

I've been using Elixir as a backend for a side project (with a Remix frontend) and it's been really pleasant and productive to work with on the backend. I appreciate how productive LiveView can be, but for my specific case I needed to handle poor network connections and LiveView was (as expected) a poor experience. I wish Elixir was able to decouple itself from LiveView in a sense in the minds of developers. Even wit…

There are a couple comments to you so far and both of them miss the point.

> decouple itself from LiveView in a sense in the __minds of developers__

This isn't a technical knowledge issue or if a given technology should be the default on install. Assuming I understand your original post correctly this is a mindset issue: too many people dismiss Elixir and the rest of the ecosystem because the first thing they think about is LiveView while ignoring the rest of the ecosystem and that's a shame, because it's much more than that... and I would agree with that point. Even Phoenix is more than LiveView.

It's possible to have solidly productive, cost effective Elixir applications not involving LiveView or even Phoenix for that matter. The choice of Elixir in the backend should be more common than it is, though I understand some of the conventional wisdom and fears that motivate other choices.

Re: Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

#50
I've been building my startup 100% fullstack in elixir, and it's been the most wonderful technology I've ever worked with. I'm evangelising all my serious tech friends about how great it is.

Now it would be awesome if rabbitMQ and its client would run on OTP 27, would love to upgrade :(

Post reply on HN