Elixir v1.20: Now a gradually typed language • Hacker News Board

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

#411

Post by kamma4434 » Fri, Jun 05, 2026, 3:28 PM UTC

geokon wrote: post #401

kamma4434 wrote: post #372

Earlier quoted context omitted.

That’s my top issue with Clojure: I see what the function does, but is it expecting a list, a string, either, or a map? The function may apply correctly, but what was it supposed to do? Java may be boring, but it’s surprise-free. In Elixir this is less of an issue because of pattern matching and very clear errors showing the actual arguments passes, that are unbeatable for debugging - you look at the log and can “see…

In Clojure you typically program to interfaces/protocols and not to types The Clojure docs should be more straightforward about the interfaces that are available and targetted You can still have a problem of not knowing which is required of an argument, but its usuallt clear contextually

What I mean is that it is harder for me to reason about. In Java you also use collection interfaces, but List is a no brainer.

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

#412

Post by simoncion » Fri, Jun 05, 2026, 3:43 PM UTC

sabiwara wrote: post #294

simoncion wrote: post #267

Earlier quoted context omitted.

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

> Does Dialyzer understand Elixir? Last I knew, it could only process Erlang source code and BEAM files. Once compiled, it boils down to BEAM files that Dialyzer can understand, yes. And the [Dialyxir]( https://dialyxir.hexdocs.pm ) wrapper helps translating error messages in Elixir. But, there is a significant limitation compared to plain Erlang: Elixir protocols (which are quite used in core parts of the language)…

Ah. So I assume that Dialyxir does some sort of patch-up or correlation or enrichment or whatever you want to call it between the results dialyzer pulls out of BEAM files and the Elixir-specific type-and-other-metadata that Dialyxir has access to?

That sounds complicated, but so's Dialyzer. Hopefully the Dialyxir people are having a fine time working on it.

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

#413

Post by teleforce » Fri, Jun 05, 2026, 4:32 PM UTC

agentgt wrote: post #365

teleforce wrote: post #350

Earlier quoted context omitted.

>Type systems restrict which programs can be expressed and increasing expressiveness often requires increasing type-system complexity (which, speaking from experience, both humans and agents will struggle with). I used to hold similar opinion but D language, and this article by Patrick Li (HN JITX co-founder) who's the original author of little known but very powerful language Stanza changed my mind [1],[2]. He argue…

> Groovy also deserved a special mention, and the pudding is Grails. I vaguely remember that when Groovy became more typed (statically typed that is. I believe you could always put the types in but they were not checked.) there was a theory that it kind of hurt possible uptake of the language. The reason being is that people felt well if we are adding types and a project is requiring it why don't we just use: Java, S…

You can considered Stanza as modern version of Dylan, as admitted by its author Patrick Li.

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

#414

Post by __turbobrew__ » Fri, Jun 05, 2026, 4:49 PM UTC

h506001 wrote: post #400

__turbobrew__ wrote: post #357

Earlier quoted context omitted.

I may be wrong, but last time I checked there was not a statically typed OTP implementation which is kindof a bummer. I think Gleam is the ideal implementation on top of the BEAM but it does just seem pretty immature.

It’s had it for a long time now: https://gleam-otp.hexdocs.pm/index.html

> Not all Erlang/OTP functionality is included in this library. Some is not possible to represent in a type safe way, so it is not included. Other features are still in development, such as further process supervision strategies.

It seems like they are re-implementing a half baked OTP lookalike, but they aren’t actually using Erlang/OTP under the hood which gives me pause as the Erlang/OTP implementation has been battle tested over many decades now whereas the gleem implementation is a complete rewrite.

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

#415

Post by igouy » Fri, Jun 05, 2026, 5:26 PM UTC

shakna wrote: post #393

igouy wrote: post #377

Earlier quoted context omitted.

That's someone's 8 year old mirror of the benchmarks game website. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Huh. And after eight years, SBCL and Java are side by side, still.

> Huh.

The hardware changed.

The way measurements were made changed.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The Java version changed.

The SBCL version changed.

> side by side

You'd have to say what you mean by that.

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

#416

Post by mega_dean » Fri, Jun 05, 2026, 5:44 PM UTC

siwatanejo wrote: post #406

debugnik wrote: post #300

Earlier quoted context omitted.

The 'in' keyword is purely syntax, like semicolons/newlines or braces in your language of choice.

Yeah and it's fucking ugly and unreadable, it shouldn't be allowed.

That was my reaction at first, but I got used to it pretty quickly. Some of the other bizarre syntax bothered me for much longer, like using semicolons for list separators, eg [1;2;3] instead of [1,2,3].

I briefly tried to use Reason since it “fixed” a lot of my biggest issues with the syntax, but it wasn’t worth it overall so I went back to plain ocaml pretty quickly.

I didn’t look very closely at F# at the time, but I remember thinking it looked like “ocaml with more normal syntax”.

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

#417

Post by igouy » Fri, Jun 05, 2026, 5:57 PM UTC

kscarlet wrote: post #396

igouy wrote: post #377

Earlier quoted context omitted.

That's someone's 8 year old mirror of the benchmarks game website. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

These mean nothing. The C/C++ implementations use SIMD intrinsic while Lisp doesn't (it should have used sb-simd).

> The C/C++ implementations use SIMD intrinsic

Except when they don't.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#418

Post by awesome_dude » Fri, Jun 05, 2026, 7:56 PM UTC

dpatterbee wrote: post #410

awesome_dude wrote: post #391

Earlier quoted context omitted.

is_int is doing the work of a type checker? I mean I'm not an Elixer guy (not at all) so it's a bit opaque to me how that's not an enforcement of specific types (albeit the firstname, lastname can be anything?) Once we get into the function itself, if two incompatible types, say a string and a filehandle.. (just random attempt, you may, if you choose, point to why the two types must have some alignment), what happens…

In elixir, processes (these are Erlang "processes", not OS processes) are designed to fail when they encounter errors, and the supervising process will restart it according to various rules you can configure. This isn't dissimilar to how kubernetes restarts jobs when they fail, but at a more fine-grained level. It's actually intended that your function doesn't try too hard to validate it's input types, and just that…

I mean - you're arguing there about a small blast radius, and I genuinely appreciate that not taking down the whole system when a bug occurs is incredibly valueable.

But, the discussion is about dynamic typing, and the fact that the function is in a state where it cannot compute because of bad input.

This might as well be a Null Pointer Exception - the function has encountered bad input, and crashes.

The argument is, that a MUCH stronger position is for all callers to be forced to provide input that cannot get the function into such a state - and a major subset of the set of all inputs possible can be eliminated with static or strict typing (I know the nomenclature gets a bit hazy here, but I hope that my intended meaning is clear)

If the callers know in advance that they cannot provide input shaped in ways that the function will not handle, then they will not call the function in those ways.

And that forces the call chain to be sure about the data transferred from top to bottom.

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

#419

Post by shakna » Sat, Jun 06, 2026, 5:39 AM UTC

igouy wrote: post #415

shakna wrote: post #393

Earlier quoted context omitted.

Huh. And after eight years, SBCL and Java are side by side, still.

> Huh. The hardware changed. The way measurements were made changed. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... The Java version changed. The SBCL version changed. > side by side You'd have to say what you mean by that.

> You'd have to say what you mean by that.

They appear, literally, side by side, in the list. That is, they were competitive eight years ago. They are still competitive today.

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

#420

Post by aeonfox » Sat, Jun 06, 2026, 6:42 AM UTC

waffletower wrote: post #352

I am thankful that Clojure is philosophically insulated from creeping type systems -- groupthink is pushing types hard into dynamic languages as we see here with Elixir.

> philosophically insulated

As an outsider, I'm curious on how?