Elixir v1.20.0-rc.0 (and rc.1) released: type inference of all constructs

Amazing work!

I found something very surprising … I have 2 Elixir versions installed using mise:

$ mise ls
Tool           Version             Source                      Requested          
# …
elixir         1.19.5-otp-28      
elixir         1.20.0-rc.0-otp-28  ~/.config/mise/config.toml  1.20.0-rc.0-otp-28
erlang         28.3                ~/.config/mise/config.toml  latest
# …

On the first one 1.19.5-otp-28 the credo tool does not emits any issues, but in 1.20.0-rc.0-otp-28 it produces a false positive for only one check Credo.Check.Readability.ModuleDoc for all modules in my project.

Edit: I have found the issue. It appears that credo expected AST meta for block expression to be an empty list, but in 1.20.0-rc.0 it contains additional line and column information.

Edit 2: I have created a quick fix PR: Fix 1.20.x compatibility issue with block expression AST by Eiji7 · Pull Request #1241 · rrrene/credo · GitHub

As a temporary workaround you can use my fork by simply changing the credo dependency to:

{:credo, branch: "fix-1.20.x-block-ast-compatibility", github: "Eiji7/credo", runtime: false},

All other tools (ExUnit tests, ex_coveralls report and dialyzer report) does not seem to change (as expected)

The only one thing I would like to see fixed in dialyxer output are OTP 28 related warnings when building PLT, but as mentioned above it’s the same behaviour as in older Elixir releases and besides that the checks so far works without any problem.

xmerl_ucs.erl:58:1: Warning: missing specification for function is_iso10646/1
xmerl_ucs.erl:70:1: Warning: missing specification for function is_unicode/1
xmerl_ucs.erl:75:1: Warning: missing specification for function is_bmpchar/1
xmerl_ucs.erl:84:1: Warning: missing specification for function is_latin1/1
xmerl_ucs.erl:88:1: Warning: missing specification for function is_ascii/1
xmerl_ucs.erl:92:1: Warning: missing specification for function is_iso646_basic/1
xmerl_ucs.erl:108:1: Warning: missing specification for function is_visible_latin1/1
xmerl_ucs.erl:117:1: Warning: missing specification for function is_visible_ascii/1
xmerl_ucs.erl:122:1: Warning: missing specification for function to_ucs4be/1
xmerl_ucs.erl:125:1: Warning: missing specification for function from_ucs4be/1
xmerl_ucs.erl:128:1: Warning: missing specification for function from_ucs4be/2
xmerl_ucs.erl:131:1: Warning: missing specification for function to_ucs4le/1
xmerl_ucs.erl:134:1: Warning: missing specification for function from_ucs4le/1
xmerl_ucs.erl:137:1: Warning: missing specification for function from_ucs4le/2
xmerl_ucs.erl:141:1: Warning: missing specification for function to_ucs2be/1
xmerl_ucs.erl:144:1: Warning: missing specification for function from_ucs2be/1
xmerl_ucs.erl:147:1: Warning: missing specification for function from_ucs2be/2
xmerl_ucs.erl:150:1: Warning: missing specification for function to_ucs2le/1
xmerl_ucs.erl:153:1: Warning: missing specification for function from_ucs2le/1
xmerl_ucs.erl:156:1: Warning: missing specification for function from_ucs2le/2
xmerl_ucs.erl:161:1: Warning: missing specification for function to_utf16be/1
xmerl_ucs.erl:164:1: Warning: missing specification for function from_utf16be/1
xmerl_ucs.erl:167:1: Warning: missing specification for function from_utf16be/2
xmerl_ucs.erl:170:1: Warning: missing specification for function to_utf16le/1
xmerl_ucs.erl:173:1: Warning: missing specification for function from_utf16le/1
xmerl_ucs.erl:176:1: Warning: missing specification for function from_utf16le/2
xmerl_ucs.erl:181:1: Warning: missing specification for function to_utf8/1
xmerl_ucs.erl:184:1: Warning: missing specification for function from_utf8/1
xmerl_ucs.erl:193:1: Warning: missing specification for function from_latin9/1
xmerl_ucs.erl:483:1: Warning: missing specification for function to_unicode/2
xmerl_ucs.erl:523:1: Warning: missing specification for function is_incharset/2

Thanks for another awesome release and congratulations on 15 amazing years!!

Classic. Elixir 1.19 did this for other expressions / constructs and some libs had to adapt (such as this issue of Routex).

Lib maintainers using AST be aware: wildcard match ‘_meta’ the metadata instead of an empty list ‘’

Granted we would have done so before, but I expect most simply adapted AST and never had a thought about that empty metadata list.

Had time to read the release notes and boy I like what I see. Congrats to all involved. The work is invaluable!

ps. I should have written more type violations just to see it in action :’)

My codebase is actually faster compiling with 1.20-rc (otp28) but only just couple dozen ms and well within margins of error. Nice job!

Only curiosity I have is that the compiler catches type mismatches in our tests, tests that were testing errors on wrong input types ha! Suppose in 1.20 we will be able to delete those!

Awesome!

In the future, will it still be worth it to use Dialyzer? I guess to find unused code, but what about the other checks?

Unless Elixir type system would generate a @spec or ex_doc would support Elixir’s Typespec natively dialyzer would have a great value at least in documentation purposes. From unknown types to mismatched ones. There are still lots of cases that dialyzer uses. Also it’s very useful when you assume that your complex logic always returns specific data and dialyzer warns sometimes it’s not a case. That’s very useful in code refactor when you forgot to update some small part of a bigger module.

I wonder if Elixir core team have any further plans about improvements to type system like mentioned ex_doc support or auto-generation of function @spec. In past we had discussions about new type definitions starting with $ character, but I’m not sure how those topics ended up like if those are on the official roadmap or so.

Any generation of @spec is highly unlikely. Typespecs lack negations like „anything, but an atom“ and therefore are unfit to represent the types inferred by the elixir typesystem.

Type signatures are on the roadmap though - see 3. in the ~15 months section. They‘ll surely become part of docs once they exist as well.

Great work! Looking forward to trying this out. So far, I loved all the changes.

Yeah, I remember that the type system allowed more stuff. Support for negations would not look good, but is rather possible - it’s just about list every type except the excluded one.

Good to know they are on roadmap, but 15 months is a lot of time especially in our rapidly changing world. Within that time almost everything can change. On GitHub there is a discussion that if situation would go that way Tailwind sooner or later may become an abandonware as they loose the traffic (by 80% or so) to their documentation (which is the only place for their paid plans) due to increased LLM usage. Looks like they already lost 75% jobs there.