Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

elixir-lang.org

Post reply on HN
Print view View original

61–70 of 170 posts

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

#61

Post by williamdclt »

josevalim wrote: post #23
williamdclt wrote: post #18

Earlier quoted context omitted.

sounds like what typescript does, I'm not clear if the Elixir approach is different from "structural typing" (as TS calls it) or if they're rediscovering the same thing. Either way, I'm happy it's the way they're going

While both Elixir and TypeScript are structural, they are different type systems. A set-theoretic type system is not one that has unions, intersections, negations, but rather one where the foundation of the type system is represented on top of unions, intersections, and negations. Even relations such as subtyping, compatibility, etc. are expressed as set-theoretic. We also have a very different approach to dynamic/gr…

I did read your article, and it’s actually how I came out with the idea that Elixir had come up with the same idea as TS haha!

I’m sure I’m missing something as I have no doubt you’re by far more knowledgeable than I am, but TS also represents types as sets (semantically, dunno about internal implementation), structural typing seems to inherently map to set theory

For example, about bounded polymorphism the article says “Of course, we can provide syntax sugar for those constraints”: seems like this sugar could be ‘a extends number’ to me, like typescript does. I don’t see how TS does _not_ map to set operations

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

#62

Post by azurelake »

GiorgioG wrote: post #4

Super-excited for this release. I wish someone would put some resources into the Elixir IntelliJ plugin. I've tried, but I just can't enjoy using VSCode (vs IntelliJ based IDEs, Visual Studio, etc.)

Same. I would pay 50 / month for an Elixir plugin that had a comparable amount of polish to RubyMine.

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

#63

Post by davidw »

dankai wrote: post #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 :(

If I may ask, what are you working on where Elixir hits the sweet spot compared to other technologies?

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

#64

Post by davidw »

ch4s3 wrote: post #38
aczerepinski wrote: post #35

For 10 years I’ve been reading about cool Elixir stuff here. Love the language. I gave up on finding a job in Elixir many years ago though after seeing salaries consistently lower than more mainstream languages. It may be the language I’d want to use most, but salary and cool product are more important to me than tech stack so it may never happen. Still fun to follow from afar.

> seeing salaries consistently lower than more mainstream languages That seems surprising to me as an Elixir developer. Are you looking in the US, or elsewhere?

I keep an eye out in the US and there just aren't many of them out there.

And you have to be careful because some of those are

* "Bob wanted to try out Elixir, so now we use it for this one microservice, but we're mostly a PHP/Rails/Java/Python/whatever shop and we'd like to rewrite it one day, because Bob left a few years ago" - places where someone wanted to play with something shiny and new.

* Early stage firms where someone is a true believer that BEAM is some kind of magic scaling bullet or secret sauce.

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

#65

Post by dankai »

davidw wrote: post #63
dankai wrote: post #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 :(

If I may ask, what are you working on where Elixir hits the sweet spot compared to other technologies?

A news aggregator (and premium news chatbot) that indexes and analyses around ~150.000 new articles a day (http://im.fo)

I'm absolutely certain the real time processing would be unfeasible in any other technology in terms of complexity and the minimal compute resources it's running on.

Modules like broadway, ash, oban, phoenix liveview ... make it not just a pleasure to work with but insanely performant.

With over 20 years of programming experience, I can say with certainty that there is no language that makes me as productive as elixir. It's at least 10x my python productivity (despite being at an expert level in python as well).

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

#66

Post by throwawaymaths »

weatherlight wrote: post #21
tiffanyh wrote: post #19

How does this compare to Gleam (strong) typing? https://gleam.run

Different type system with different goals. Gleam uses a modified version of the Hindley-Milner Type system. (Which is a rock solid tested type system.) A Set theoretical type system is more expressive(which suits the dynamic nature or Elixir better.) You can do Union and Intersection Types, and Negation Types, among other things, that you can't do with a HM type system. but it comes at the cost of how fast the progr…

It's also not clear that an h-m type system is what people want. For example, checking json inputs in gleam will always either be awkward or behind a "marshaller for me but not for thee" sort of inside-ball stuff, and the interface with other members of the beam ecosystem will be poor. It is possible to build a set theoretic type system without these problems, but I don't see these cases being handled by elixir's type system, either.

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

#68

Post by throwawaymaths »

bo0tzz wrote: post #32
tiffanyh wrote: post #25

Earlier quoted context omitted.

Does Gleam check types at compile-time? And Elixir check types at run-time? (If at run-time, would that mean it would slow down your entire app as a result?)

My understanding is that the BEAM vm already has some (optional) runtime typechecks in the form of guards, which this new typesystem will also add for you automatically. And that these guards are actually used to speed things up, for example by JITing more optimized code.

So inserting those type checks automatically will cause regressions because those checks are not free at runtime, and there are cases where the JIT will look at the code and not bother optimizing.

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

#69

Post by throwawaymaths »

williamdclt wrote: post #18
bobwaycott wrote: post #14

Earlier quoted context omitted.

From the original paper[0]: > We present a gradual type system for Elixir, based on the framework of semantic subtyping ... [which] provides a type system centered on the use of set-theoretic types (unions, intersections, negations) that satisfy the commutativity and distributivity properties of the corresponding set-theoretic operations. The system is a polymorphic type system with local type inference, that is, fun…

sounds like what typescript does, I'm not clear if the Elixir approach is different from "structural typing" (as TS calls it) or if they're rediscovering the same thing. Either way, I'm happy it's the way they're going

Elixir is going to be fundamentally different from TS though. The base set of datatypes is quite well defined, and function activities are rather composable unlike JS where "basically anything can happen".

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

#70

Post by CaptainOfCoit »

> This Elixir version introduces the Duration data type and APIs to shift dates, times, and date times by a given duration, considering different calendars and time zones.

> We chose the name “shift” for this operation (instead of “add”) since working with durations does not obey properties such as associativity. For instance, adding one month and then one month does not give the same result as adding two months:

I'm not exactly sure why adding one month and then one month would give a different result compared to just adding two months. Don't you in reality want the same thing? Why is "shift" more useful than "add"?

Post reply on HN