As preparation for my upcoming ElixirConf US talk, I would like to hear what are your concerns about Elixir adopting a type system in the future, hence this thread.
The goal of this thread is not to provide answers but simply have a general understanding of potential concerns and conflicts. Even if your concern turns out to not apply, it is important for us to know as it can be helpful material to include our guides and documentation.
I will establish some ground rules for this thread as an experiment:
Keep your concerns short, one to three sentences maximum. For example: “I worry the type system will make the compiler slower”.
Be precise if you can, avoid being too vague. For example, “I worry it will make Elixir bad” is too vague and therefore not helpful.
You may list at most your top three concerns.
Do not reply or comment on other concerns in this thread. If you agree with a concern someone else posted, feel free to “Like it” by clicking the heart button.
Let’s see how this goes, thanks.
Edit1: for those who say “what about those who prefer dynamic”, I suggest to dig a bit deeper. Why would you prefer to be dynamic? Assuming that types provide values, what worries you about static types that you would rather avoid them?
Edit2: for those wondering why types and how they would impact Elixir, I have talked about this during my ElixirConf EU keynote 2022.
Hello! Excited to hear about the type system. My main concern would be the adoption and gradual migration to this new type system. A big downside would be that you either migrate fully to types or can’t use them.
Fragmentation and Rust-style drama (the “unsafe” Rust drama, not the political Rust drama… oh, Rust). IE, “How dare you write your library without types!” incidents. I worry it will bring in an influx of people to the community with a different mindset who will make a lot of noise and apply massive pressure to make major changes to the language. I’m not overly concerned about the second as I trust the core team there, but thought I’d voice it (sorry for the extra sentence).
How well type system would be integrated in future?
Would we be able to write a macros with a new dollar ($) syntax just like we are doing now for @spec?
Would we be able to read information about it from beam files?
For reference: Dynamically generate typespecs from module attribute list
Would we be able to write multiple $ spec like we did for @spec?
This is supported by ex_doc and not supported by dialyzer?
For reference: What is the idiomatic way to use @spec?
What would happen with @spec and what with ex_doc?
Would ex_doc prefer $ over @spec or maybe it would just present both of them?
Would @spec be deprecated in long term or it would be only recommended to use one over another?
Verbosity in pattern matching is scary. (People are already asking me to break my non typed / non verbose pipelines!)
Hope we don’t have to include typedefs for libraries, like it happens with TypeScript projects.
If type system comes, it should be integral to the language, otherwise if it’s optional like @spec or proptypes in React, then my code base will be a mess. (I will become lazy about adding types, just like I leave out tests!)
The biggest annoyance with strong typed languages from my past experiences has always been around inheritance vs composition and the way interfaces abstract the types for encapsulation and polymorphism.
Often times it has more to do with the choice of things people lump into the interfaces calling them abstractions because they don’t have a better place to put said thing.
None of this is a concern of accessibility of said feature but rather use and abuse of the feature.
I think it would be wise to educate as much as possible around good uses cases and anti patterns.
Thank you to all the devs who keep pushing this awesome language.
I’m sure what ever you choose its going to be great,
just let necessity drive innovation and the path will show itself.
The type system won’t be strong enough, i.e. that it will be only a smaller improvement over dialyzer. Ideally, it would do justice to HM Type system (Hindley–Milner type system - Wikipedia) as a minimum.
The error output of the analyzer will be hard to read for newcomers. A good example is Rust compiler which gives precise and readable errors. A bad example is dialyzer errors as they are.
There won’t be a standard for how to and where to place type definitions in projects, thus causing types to be scattered all over the projects in random ways.
My concern is that type definitions written using $, after being auto formatted, will add in many cases too many “idle” or “low value” lines (this is the same issue I have with typespecs today). I would like to see a complementary interface to define types inside @doc. Maybe even more verbose, but nicer.
I’m thinking something along these lines:
@doc """
Calculates the area of a pie slice.
Args:
- radius, float(), "Measured in km."
- angle, float(), "Measured in radians."
Returns:
- {:ok, area = float()}, "area measured in km^2"
- {:error, :negative_radius}
"""
def calc_pie_slice_area(radius, angle) do
When I have conversations with my dev friends who haven’t yet tried using Elixir, a common reason they give for not trying it is that Elixir doesn’t have a proper type system. I’ve already shared some information with them about the ongoing efforts to address this, but they mentioned that they found the way Elixir might handle types in the future a bit strange. They say they would prefer to have type information right next to the function params. However, this could be a challenge because we need to support pattern matching on params, and if we also introduce information about types next to params it could become messy and noisy.
My concern is that some individuals might feel that Elixir’s approach to types is too different from how other widely used programming languages handle them. This difference in approach could discourage them from giving Elixir a try.
The correct way to handle types I think is still a very open ended question, because I know for a fact that languages like java/c# and all subsequent languages that implemented the same way failed this, their tooling is good, however the amount of boilerplate required to separate code into testable pieces is just beyond stupidly insane. One of the concerns is that it might introduce a lot of boilerplate just like in those other languages.
The other concern is as other mentioned a big split in the community, legacy projects that will most probably not adopt the typing and new ones. This also introduces 2 different styles of writing code that might be inherently different in approach.
My last concern is impact of all of this on metaprogramming and pattern match, those were inherently designed with dynamic types in mind, so I don’t see how types would play here, especially if we talk about backward compatibility.
My concern is echoed in a lot of other people’s concerns: basically that the problems types solve (which always seems to be some variation of “and later when the implementation of this function changes dramatically and apparently no one notices and no test fails”), isn’t worth the various downsides of types, in fact for me personally it’s not even worth the visual noise of types.
The most important one for me: I worry that the ecosystem will get split in two by projects who will support new type system and by projects who won’t. Since the type checks will work only for projects who adopt the new type system and that new type system will bring no guarantees unless every line of code written with it in mind.
And I don’t think that some projects (like those written in Erlang) will be rewritten to support new type system. This will lead to typed wrappers (who will reduce performance by wrapping every function) and forks (which rarely-rarely happens). TypeScript approach with types and specs specified externally can help to create projects-with-only-types which will contain types and specs for projects who don’t have them in the first place, and this will lead to problems with keeping two dependencies in sync.
With everything written above, I don’t think that new type system will actually help to solve any problems without bringing equal amount of different problems.
I worry that new type system won’t improve performance. I’ve showed several times that this is possible, but each time I’ve heard that nobody is going to do this. Performance is the biggest problem of whole BEAM ecosystem, and not the static typing, since statically typed languages existed there for quite a while now. It is really sad to hear that this problem will remain untouched by new type system.
I worry that new type system won’t have an interface for compilers and other compile-time tools. It would really help me in development of my optimizing compiler to have such interface to provide better guarantees. Introspection and RTTI would really help everyone to create type-aware macros and stuff.
Regardless of my personal opinion about types, my biggest worry is about the risk of splitting the community. And that neither those who prefer compiler-enforced user-defined types nor those who prefer dynamic types will be happy.
I agree with what you said, I prefer to have something that fits Elixir well than something that is familiar to most people. I’m just raising a concern that this might hinder adoption in some way due to unfamiliarity. Not that we have to do anything with it, just some food for thought…
Folks joining late, reminder to keep the answers concise and not engage in discussions, as outlined in the topic. Let’s let everyone say their piece, otherwise I will be removing comments.
