I haven’t read all the threads related to the new type system so maybe I am wrong
I worry about the type signature in the Docs, will Elixir maintain the Dialyzer style in the docs or will it move to the new one? Will it use both?
I think it could increase the learning curve of learning Elixir from Erlang or vice versa
PS: Thank for all the work
My worry is that it will add bloat/boilerplate to the elegance that is Elixir. I see a type system as something that forces the developer do the job of the computer/compiler and it has predominantly theoretical benefits. I hope it can be fully inferred, like Roc has.
Before watching the conference video I was strongly against the introduction of static typing in Elixir. I’m not without stereotypes about static typing in general, probably just like the next guy.
In the video José did a great job explaining the Elixir’s perspective, and to me the core team’s approach looks very reasonable. In particular, the effort doesn’t look hype-driven, and the language’s idiomatics is getting preserved. So I don’t worry anymore, instead I trust the core team.
PS: To anyone answered or going to answer without watching the conference video, please watch.
Fears:
primary: true or primary_key: true?).int | float), maps with only defined type for keys/values become clunky without keywords like map or struct or keywordlist.Hopes:
@hint and duck typing.
$ offered seems really out of place
I hope that the new type system is so clear and easy to use that it quickly wins widespread adoption and we can bury specs and dialyzer in an unmarked grave. That’s a pretty tall order though.
I like the idea of type checks, but I’m ambivalent about type specs. If my function takes a list and returns an integer or an atom, ideally the language could understand that, add that fact to the generated docs, and warn me if another function expects to get a string from that function. If I have to declare a typespec, it feels like a violation of DRY, and in my experience, most of the time it’s the typespec that’s wrong when the typespec and function disagree.
Hopes:
Makes the language easier to refactor.
Makes errors more apparent in the IDE reducing the need to write boilerplate unit tests.
Makes code easier to understand, rather than a function just taking a list of something, give the developer confidence that the list only contains elements of a particular type
It’s as good a Java generic type/typescript as a baseline.
It doesn’t get too complicated, it should be pragmatic and add value
My concern is diversion: that disproportionate resources will be diverted towards a new focal point. Discourse will become dominated by the type system, at the expense of other concerns. Soon enough, the very course of the language will be perceived as resting on the resolution of formerly subordinate issues.
Brexit is the closest analogy I can think of.
I’m unsure if static typing would solve issues that existing solutions don’t. I’m concerned that Elixir’s flexibility could be compromised.