[sph]

I know this is blasphemy to the average HN reader, but as a professional Elixir developer for 10 years, never have I felt the need for stronger compile-time type guarantees. None of my production services have had downtime or crashes because of type errors. Sure, at times, for very data-intensive sections of the application I would have loved something a bit more complex than dialyzer, but the guarantees offered by OTP and its actor model are much more important than compile-time type checking.

Of course people used to write server software in compiled languages feel the need for them because any runtime bug means downtime, but in BEAM land you'd have to work very, very hard to see your application crash in the classic sense, causing downtime and gnashing of teeth. And Elixir is strong typed enough never to cause the type of bugs you see in Javascript land, for example (i.e. a string is a string, not a number in some conditions)

That said, I'm perfectly happy for José and team to work on this niche feature, because for me, the language is pretty much done and all the improvements are on the OTP and library side rather than Elixir itself.

[__jonas]

I wouldn't say it's blasphemy, but I don't really understand the argument about how this relates to 'the application crashing and causing downtime'.

I don't have your level of experience with the language, but I have a personal project written in Elixir, and I do not feel very confident about parts of it that don't have complete test coverage, due to the lack of static typing.

I'm talking about things like: Is this pattern match exhaustive or is there a possible permutation I forgot / specified wrongly, which may then cause a match error at runtime, breaking a particular feature? (of course not bringing down the whole app due to OTP!); or if I change some keys in a map / struct in refactoring, did I forget to change them somewhere else in the application, introducing another error that is only caught at runtime?

Both of these have happened to me, I can even give you examples from code that is not my own – for my project I use a snapshot testing library by an experienced Elixir developer, and while using it I encountered two runtime crashes due to data being in the wrong shape and failing a (function clause) pattern match:

https://github.com/zachallaun/mneme/issues/85

https://github.com/zachallaun/mneme/issues/105

Proper static typing would make it very hard to write bugs like this. In Gleam for example, the compiler checks the exhaustiveness of your pattern matches against the type of the data you're matching against, and forces you to handle all possible values.

[williamdclt]

> people used to write server software in compiled languages feel the need for them because any runtime bug means downtime

I keep hearing that but I don't think it's been true in many years? Whether it's Go, Java, C#, Rust... a runtime bug will only fail the request, not the whole server.

FWIW, the main reason I like types isn't for the compile-time guarantees (although they're certainly nice). It's for documenting what are the data types I'm working with rather than having to guess them from the code, it's for knowing that something is a square hole therefore I should put a square piece in.

[kamma4434]

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” the issue.

[geokon]

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

[kamma4434]

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

[geokon]

yeah, your overall point stands. Sometimes you can get a bit mixed up on "wait, does this take a File object or a string with the filename?". I guess my point was that because you program to interfaces this happens a bit less often than one would expect. If it can take a vector it can usually also take a list

[ken-kost]

very true; & 4 years for this niche feature, I feel like it was built for hacker news people.

But that's good! Indeed that was the most needed!

& magnificently executed - that's the craziest part - takes away nothing. The compiler is faster!! It's awe inspiring to say the least, what Jose did and still does.

[conradfr]

For me it's more the productivity and DX that suffer from lack of function arguments types.