My main concern is when it would be safe to add to libraries for older version support.
I would love to see a couple of versions of Elixir released that know how to ignore any planned new types syntax before the syntax is enabled so that it is easier to offer older version support while taking advantage of new features like typing.
Result | Error vs {:ok, result} | {:error, error} issues?::) and I always need to have the docs open to declare a behaviour. Mixing types with other code negatively impacts the readability.mistake.
First of all - thanks a bunch for involving the community so early on in this journey that hopefully leads to an awesome type system @josevalim! I really enjoyed reading your early discoveries on what the type system might look like. Here are my top three worries:
An obtuse syntax which makes Elixir type definitions a lot more confusing to read and write. Coming to Elixir from other languages about a year ago one of the hardest things to grokk was actually how to write idiomatic function signatures. Elixir has pattern matching, guard clauses, and @specs, that all hint at what the function params are expected to be. Adding a fourth thing that’s at least semi-related could potentially make function sigs even more complex.
Language server / IDE integration not being robust enough. Right now the Elixir LS semi-regularly errors out for me and needs to be restarted (when using VSCode). I’ve often been in situations where the LS has stopped working, and Dialyzer therefore gave up on highlighting issues (or even worse, highlighting issues that aren’t there any more). If a type system is to be helpful for developer feedback I think these integrations need to be solid as well.
Hard to understand error messages from the type system. I dread reading whatever Dialyzer spits out, and often end up just trying to figure out what the issue is myself instead.
Looking forward to watching the ElixirConf US talk! 
I am also concerned about the $ syntax. Most elixir code verbally describes what it’s doing, and creating something that would, unlike the & syntax, be sprinkled throughout almost all files that isn’t self-describing feels wrong. I personally would prefer a new keyword or something in combination with the $ syntax that is self descriptive, but there are challenges with doing that too, right?
From my experience as a learner and a teacher any boilerplate adds complexity to understanding. People wouldn’t be able to make simple programs fast (in iex) while they are learning and will give up.
I came to Elixir to learn about concurrency, faced easy to read syntax and this gave me ability to learn more about functional like programming and work with processes (actors, real OOP). And oh my processing Is not something simple to get used to even with such concise syntax. I am afraid that language will get complicated and will start to compete with mainstream languages like C++, Java. And I’ll just move to Erlang because I don’t understand the point of mainstream languages. I droped Python because it’s a divided language now: there are several ways of types, several ways of concurrency (standart library doesn’t work with concurrent frameworks). And I feel more like Defensive Programming aproach with types and it’s not an easy way for programming.
Are we getting rid from REPL?
For me type system is something more about compilation time errors. I’d like to let it crash during runtime.
Typecasting: I want to somehow type data structures, and ensure that either I have something like this in my hands or fail hard and fast in my code. Like, interacting with external APIs where I cast/transform received data into something more usable first thing in my code - the ability to hard cast eliminates a lot of “if” branches later on in the code. My fear: we get types without the casting, like in typescript. I want: in an ideal world something like serde in rust, where I can encode/decode stuff right From/Into (json/xml/…). A huge percentage of company business code usually is concerned with casting data shapes back-and-forth, so for me personally this would be a killer feature.
duplication: the new types should automatically generate dialyzer specs or vice versa somehow - additional markup ontop of functions would be bad.
compilation times: this already is noticeably bad when there is a big phoenix monolith with lots of code and dependencies and then ontop of it dialyzer runs from scratch for a significant amount of time. I see why it is that way and understand the reasons, but at least it shouldn’t get much slower.
Yesterday evening I finally watched it as well as your 2023 talk. I agree with most of the things you said in defense of a typing system (in Elixir). Naturally, I also agree with all the cons.
As for how this typing system will look like the only thing I understood was it would be used for interfaces (functions, callbacks) and structures. Now, since I myself already use typespecs for all non-trivial functions, I could get used to it but would still prefer it be optional, just like the typespecs, especially if the ambitions is to type variables within the function body one day. (I would, however appreciate if all your code in LV and other libs/frameworks had typespecs :).
Re the fear of a community split:
In my view there’s no room for fear that an optional typing system would “split the community” for as long as this optionality is implemented the same way the typespec’s is i.e. relying on typing where one sees fit. There where it’s not used the compiler should simply assume (correctly) that the proofs and restrictions might not be desired or that the user finds it unnecessarily litter the code. If a typed function invokes a non-typed function, by default the user will get a warning that can otherwise be suppressed on a case by case, module by module or even the application as whole basis. And that’s it. The time and the market will then judge best where and where to use it or not to use it while no “legacy” code would be ever jeopardized.
My 2c
I worry that the type system may:
I worry that the type system will make the macro system more complicated or less powerful. Also, I worry that if Elixir does not have some type system it can never be adopted more broadly.
My concern: I hope types do not lead to a break in language continuity. The leap from Python2 to Python3 was IMO disruptive.
I hope types are introduced over a very long time period, in a series of small incremental improvements, with time for the community to absorb each change.