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

Elixir v1.20: Now a gradually typed language

elixir-lang.org

Post reply on HN
Print view View original

261–270 of 426 posts

Re: Elixir v1.20: Now a gradually typed language

#261

Post by IshKebab »

awesome_dude wrote: post #112
IshKebab wrote: post #104

Earlier quoted context omitted.

It's the circle of life. Dynamically typed language has fans. Other people correctly say that it would be a lot more useful with static types. Fans take this personally and say it doesn't need static types because (they aren't useful anyway/it goes against the spirit of the language/it's only a scripting language anyway/you can just use a debugger/static types hurt productivity/etc. etc.) Then eventually they add sta…

For my $0.02 - it depends where you want to put the onus Statically typed languages put the onus on the caller to transform the data into the shape(s) required. Dynamically typed languages put the onus on the called to handle anything. That is, in a dynamically typed environment your function has to defensively code for every possible type it could be handed.

Nobody writes dynamically typed functions that can be called with any possible type.

It's not about that at all. Static types give you errors reliably at compile time instead of randomly at runtime, better documentation of what the code expects (people writing dynamically typed languages eventually resort to type comments), working IDE support, reliable refactoring and better code, all of which results in faster development.

The cost is a more complex language, occasionally difficult-to-write types, and very occasionally impossible-to-write types. But those are very very minor in comparison to the pros.

Re: Elixir v1.20: Now a gradually typed language

#262

Post by steve_adams_86 »

asa400 wrote: post #259
steve_adams_86 wrote: post #245

Earlier quoted context omitted.

Do changesets incur a runtime cost?

Ecto Changesets[0] are runtime constructs, yes. They're similar to libaries like Pydantic, if you're familiar with Python. [0] - https://ecto.hexdocs.pm/Ecto.Changeset.html

Yes, this is exactly what I was wondering, thanks. Another version of this that I love is Effect Schema in TypeScript land.

The runtime costs aren’t trivial, especially on large datasets, but I’ve come to love this pattern a lot.

Re: Elixir v1.20: Now a gradually typed language

#263

Post by frollogaston »

dns_snek wrote: post #260
frollogaston wrote: post #152

Earlier quoted context omitted.

Well now Claude will add the types for me, so I don't need to use escape hatches

As long as you're fine with the types being semantic gibberish because all agents I've used take the lowest effort approach to make the error go away. You probably have the same logical type duplicated in 3+ different places (at least partially), including inline casts using type literals like "maybeCat as { meow(): void }"

So far I've seen it actually do the types well when I tell it to add types. But even if it didn't, I wouldn't care, it's just to check a box.

Re: Elixir v1.20: Now a gradually typed language

#265

Post by pjmlp »

jeremyjh wrote: post #96
pjmlp wrote: post #86

Earlier quoted context omitted.

The irony is that dynamic languages that predated them had optional typing. BASIC, Smalltalk vs Strongtalk, Common Lisp, Dylan It is the eternal September.

Elixir predates set-theoretic types. Simon Marlow took a solid crack at typed Erlang 30+ years ago and couldn’t make it work and preserve what Erlang is. 9 years later Success Typings was published and Dialyzer happened. Not the best, but far better than what any other dynamic language had at that time, and Elixir had that available from the beginning. So it is possible new theory was actually needed to preserve ever…

Fair enough, however given past experiences, there is probably value designing dynamic languages with optional typing from day one.

In any case, most of these questions are starting to become less relevant as we switch to having robots doing the programming instead.

Now the question is how to typecheck natural languages.

Re: Elixir v1.20: Now a gradually typed language

#266

Post by josevalim »

xlii wrote: post #249
losvedir wrote: post #88

Oooh, here we go! As a professional Elixir developer for... 10-ish years now, I've been super excited about types coming. I'm very excited that the beginnings have started to land here. That said, I would love to know how the state of what's in v1.20 compares to un-spec'ed dialyzer. I was under the impression that dyalizer's "success typing" approach (not flagging a function if there are some combination of parameter…

Dialyzer fails to successfully report errors when there are circular dependencies. Circular dependencies are nigh unavoidable in Elixir (IIRC bootstrapped Phoenix has 3 or 4) and outside of interfering with Dialyzer it impacts on compilation performance and stability (compilation races causing non deterministic compilation)

You are mixing runtime and compile-time dependencies. Runtime dependencies (circular or not) have no impact on compilation performance and stability. Phoenix does include one circular dependency (the layout is rendered by your endpoint and it references your endpoint) but it is a runtime one.

Re: Elixir v1.20: Now a gradually typed language

#267

Post by simoncion »

xlii wrote: post #249
losvedir wrote: post #88

Oooh, here we go! As a professional Elixir developer for... 10-ish years now, I've been super excited about types coming. I'm very excited that the beginnings have started to land here. That said, I would love to know how the state of what's in v1.20 compares to un-spec'ed dialyzer. I was under the impression that dyalizer's "success typing" approach (not flagging a function if there are some combination of parameter…

Dialyzer fails to successfully report errors when there are circular dependencies. Circular dependencies are nigh unavoidable in Elixir (IIRC bootstrapped Phoenix has 3 or 4) and outside of interfering with Dialyzer it impacts on compilation performance and stability (compilation races causing non deterministic compilation)

> ... circular dependencies ... compilation races ...

Does Dialyzer understand Elixir? Last I knew, it could only process Erlang source code and BEAM files. Looking around, it seems like folks running Dialyzer against Elixir code are using some "dialyxer" thing.

You talk about circular dependencies causing minor compilation troubles, so it doesn't sound like you're talking about types defined in terms of each other. I might be unaware of something important, given that I've never had the opportunity to do Erlang professionally [0]... but aren't the only "dependencies" of BEAM files the exported functions they call in other modules? If I'm not wrong about that, then what happens when you run Dialyzer against BEAM files compiled from Elixir that has circular dependencies? Do its reports become more reliable, or does the reliability of those reports become irrelevant because the transformations the Elixir build system makes to your code make the structure of the BEAM code difficult to trace back to the Elixir source code?

[0] ...and have written nearly zero Elixir in any context...

Re: Elixir v1.20: Now a gradually typed language

#268

Post by solumunus »

elitehacker1337 wrote: post #202
teleforce wrote: post #163

Honest question, in the era of vibe and AI assisted coding is there any advantages of using untyped programming languages, apart from the fact that non-typed languages has more traning data for the LLM? This probably controversial, but personally I consider untyped languages as technical debts that need to be fixed sooner or later, and the OP article is partly addressing this very issue. Rewriting critical software i…

I’ve been using Ruby and Elixir for over a decade. Pre-AI I used them for aesthetic reasons. The code was beautiful, and I disliked dealing with types. People without experience in dynamic languages tend to overestimate the number of bugs their type system is saving them from. It’s pretty rare that I run into a bug in production that a type system would have caught. They also overstate how much types help their AI ag…

> It’s pretty rare that I run into a bug in production that a type system would have caught.

Well yes, surely because you’re not designing your system around the type system. You need to architect your project to lean heavily on types, pattern matching, etc to actually gain the benefits. If you move a JS project to TS and just rename the files, yeah there’s going to be no difference, you must reengineer the entire codebase to leverage the type system.

Personally, after moving to TS I’ve been completely sold on types and am currently planning to migrate my app to F# so I can gain even more benefit.

Re: Elixir v1.20: Now a gradually typed language

#269

Post by josevalim »

asa400 wrote: post #187
josevalim wrote: post #99

Earlier quoted context omitted.

That can be a concern indeed but it is worth noting that strong arrows compose/propagate. So if you have a function without guards that calls a function that guards on said types, the caller is also strong! We will likely have mechanisms to measure "strength" when we introduce type annotations.

Is it fair to think of this as the ability for type information to be propagated in both directions, e.g. both up and down the callstack? So callees down the callstack may receive any type information the caller might have, while callers up the stack may also receive any information callees further down the stack might have? Please correct me if my understanding of what you wrote is way off base!

That happens with a single module but not across modules because being able to hot code load modules is an essential ability in Erlang/Elixir.

Re: Elixir v1.20: Now a gradually typed language

#270

Post by cubefox »

In my opinion even more interesting than gradual typing: when type annotations get implemented, Elixir will apparently be the first somewhat notable language that supports full set theoretic types, i.e., not just unions and intersections but also complements ("negations").

This is interesting because TypeScript and Scala only support set theoretic union and intersection types, but {union, intersection} is not functionally complete, while {union, intersection, complement} is [1]. So Elixir will be able to express arbitrary set theoretic types while TypeScript can't. E.g. "A or (B and not C)" or "Either A or B".

1: https://en.wikipedia.org/wiki/Functional_completeness#Set_th...

Post reply on HN