I worry about how types will interact with macros. Will there be a special “code” type needed when defining macros?
djaouen
Awlexus
My concern would be how long it would take for devtools to catch up. I prefer seeing the same errors/warnings in the editor and while running/compiling the project
1
michallepicki
I know this was the example, but it’s my main (if not only) concern: I worry it could significantly hurt compiler performance. Creating a typechecker for such flexible typesystem as described in the initial research is surely a challenge to make fast and not explode in memory usage in some edge cases.
And a related concern: I worry that the typechecker will sometimes have to simplify type information (like Dialyzer does), which would make it less reliable and less pleasant to work with.
4
wmnnd
My concern is an entirely emotional one: I have the impression that $ doesn’t feel very Elixir-y. For most similar constructs, we use @something and I think I would prefer that for the new type system as well. Maybe we could stick with @type and add an additional attribute like @strict to modules?
6
elixirium
1. Slow compile times. Slow compile times affect developer productivity. I consider slow compile times in Rust one of its greatest weaknesses that is solvable with very expensive high end hardware and making design decisions in consideration of slow compile times. Designing for faster compile times usually involves sacrificing user friendly functionality such as proc macros in exchange for verbose boilerplate.
2. Phased compiles. Compiler doesn’t show everything wrong during compilation but rather what is wrong in the current phase of compilation. This creates a demoralizing experience for a developer who sees the finish line as a mirage, an illusion.
3. Compiler error messaging is insufficient for problem solving. It takes a lot of effort to produce accurate, meaningful error messages about what is wrong. Elixir will need a lot of dedicated, long term resources to improve compiler messaging.
7
theoldguy
binarytemple
I am concerned that the type system will be abused and people will write unnecessarily complex type specifications as happened with Scala (scala-z, turing complete type systems, need to understand category theory in order to decode JSON).
I am concerned that if the implementation is complex and buggy that it will become tedious to write code for Elixir.
I am concerned that some developers will write unnecessarily convoluted code, as sometimes happens with macros, life is short, I don’t want to spend it debugging something that is unnecessarily complex - don’t lose track of the pragmatism and ergonomics that make Elixir popular.
12
brightball
Biggest concern is how it will impact communication between nodes and that developer experience, since as far as I know there’s no way to exchange the type information of each node.
3
rvirding
Creator of Erlang
For me the main question is: what is the actual problem they are trying to solve with static typing? Do they actually have a problem?
32
connected-cjohnston
My biggest concern is that types will be added for no other reason than because a bunch of noisy people are requesting types because they are trendy right now and developers think they that removing compiler time errors will solve all their problems. My other concern is that they will added in a non-optional way and ruin one of the best languages in existence today.
18