[losvedir]

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 parameters such that it works, rather than flagging it if some combination of parameters can make it fail) was like what Elixir is doing here, and I haven't found dialyzer terribly useful.

[felix_starman]

I think the 300th episode of Thinking Elixir w/ José as the guest included a discussion on that point exactly, and if I remember correctly it was a "it depends", but I took away "probably not worth adding more labor into putting it in if you haven't already".

I haven't had it catch something before the compiler in a while. I still use typespecs for their documentation benefit, though I've been using `defguard` w/ `is_struct/2` and complex guards a lot more in recent years.

[xlii]

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)

[josevalim]

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.

[xlii]

No I'm not. This is often brought up.

I spent 3 months analyzing failures caused by - what looked like - dirty builds but was caused by unstable compilation order. Which is quite obvious.

The solution is dynamic dependency resolution but this causes problem with macros.

The problem is easy to validate. Compile application multiple time and compare hashes. I'm not sure if it's sufficiently visible in bootstrapped Phoenix but I saw it in as small as <1000 LoC toy apps.

[josevalim]

Please file a bug report if you can indeed isolate/reproduce it (and please ping me on GitHub once you do)!

[xlii]

I've made one for Phoenix (as per - it creates a cycle), though unstable compilation is a wider issue.

https://github.com/phoenixframework/phoenix/issues/6697

In case you want to see files affected I made extended writeup on my blog - for reference. https://xlii.space/eng/elixir-cycles/

[simoncion]

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

[sabiwara]

> 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) are not an Erlang construct, so Dialyzer will be clueless about them, just accepting any term. Enum.map(nil, & &foo/1) or to_string(%{}) will be invisible to it.

[simoncion]

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.

[felix_starman]

Dialyzer (and Dialyxir) were written prior to compiler tracing, and also are based on Erlang's "Typespec" syntax which is a bit lacking.

I still use the Typespec syntax for its documentation benefits, and for catching "dumb" bugs, but as the Elixir compiler has improved I have found Dialyzer to be less relevant as the compiler usually catches things before Dialyzer would as it's not built into the compiler and isn't able to be.

[xlii]

There's dialyxir which is wrapper to Dialyzer and I found it work fine on pure (non Phoenix) code.

As for how the problem manifests: even obvious contract violations stops being shown (making it feel like "Dialyzer is useless") but the second tell is very long check times (tens of seconds up to minutes).

[simoncion]

Cool, cool.

  [W]hat 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?

[dugmartin]

I'm curious what it is going to find in my 10 year old Elixir codebase (still in active production use).

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