Who might be interested in specification

Without taking into account Elixir core team and myself there are several third-party projects who might benefit in having language specification and

• Elixir linters can detect unreliable and exploiting behaviors (cc @rrrene)
• LSP can have better completion around what and where can be called (cc @axelson)
• Tools leveraging reflection and elixir metaprogramming approaches (like sourceror (cc @dorgan) and patch (cc @mdnowack)) could have a better understanding of how Elixir modules must work and how AST must behave, how variable contexts behave and so on.
• erts developers could have a better understanding of how beam generated by Elixir programs is supposed to be executed
• Elixir compiler developers (like myself)

Personally I think that this is not worth the time, you should understand that elixir without erlang is pretty much an empty shell, because some of the more advanced features like pattern matching are part of erlang, not elixir.

I understand that, but how does this go against the idea of language specification?

Shouldn’t it be the other way round? Beam code being the standard (which has defined specs for erts to follow) and elixir just like other beam languages is a consumer of that spec?

This most probably will never happen, the only exception is lumen and who knows how many years it is from completion.

The other thing is that there are talks about elixir 2.0, so there might be a lot of breaking changes.

In general I think that having specifications is a good thing, however I don’t see how the effort invested in making a specification for elixir will be paid off.

Where did you get that impression? Yes there’s things queued for an eventual 2.0, but afaik there are no plans at all to act on those at this point.

Elixir 2.0 is coming out soon

I just don’t see an already overworked core team working on this ever. And the community, while very practical and of high quality, is not big enough or with enough free bandwidth to tackle this. We seem to mostly address functional stuff that helps us do our jobs. Not too much foundational work (exceptions exist of course, but they kind of prove the rule).

I do agree with the rationale btw, I am just not seeing this idea happen.

One thing I’d explore if I had all the time and energy in the world: an alternative Beam VM implementation without hot code reloading. Maybe skipping that will allow for both more performance optimizations and a way to spec the whole thing better. Maybe.

…Or maybe we can collaboratively agree on e.g. AST format for code-generating libraries as a start. The value of that is up in the air though.

It works in both ways. ERTS developers are interested in optimizing runtime for frequently used patterns, and Elixir developers are interested in generating efficient code. The specification would help to define what kind of features Elixir relies the most and what features are not that necessary.

There is also Tria, Eir project, and a lot of companies are interested in development of statically typed elixir compilers (@josevalim gave several talks about it)

It is neither scheduled, nor expected to happen yet.

It is actually a good point, thanks. I think that there are several approaches to this problem. As I’ve said, it is not required to have 100% complete spec of the language. And I think that it should not be the job of core team to gather specification requirements, specification format, specification implementation and the specification of language itself

I would suggest something like this:

• Specification proposals are gathered in terms of RFC which can be accepted, declined or can have an update requested. Core team should not be responsible for writing these RFCs.
• One time a year (perhaps synchronously with Elixir release) all RFC must be accepted, declined or must have an update requested. The decision to accept or decline RFC can be the only job core team must do.
• Accepted RFCs and the current specification will form the new version of language specification

Yeah like this talk, and the conclusion of that talk is that having static types that are solved at compile-time don’t solve much and why elixir will never be typed like languages such as java.

This seems to be a big overstatement, but it is no news that people want their classic OOP language, either because they are too lazy to learn a new paradigm or because that is the only way they know how to architect and write software, a good example is this discussion.