I am working on a few new elixir projects and am finding I want to encode more type information than vanilla elixir syntax allows as I understand it. For example, the return values of functions.
I could adopt dialyzer and the @spec convention, but
I’m not going to lie… in those projects where they’re missing I find it frustrating sometimes. Not because there’s huge missed value in Dialyzer… I think Chris’s view on that is absolutely reasonable and while I’ve ended up on the other side of that thinking, I can’t blame him for his position. No what drives me crazy about the missing typespecs is the lost documentation value. I often times will look at the documented typespecs, as the client developer using a library, to understand if… at the very least… I’m understanding the intention of a given API correctly. Even in my own code, they’re great to remind me of what I was thinking particularly if I haven’t touched that part of the application in awhile.
Assuming the existing typespecs get phased out in favor of some other approach, it’s still going to be awhile and the set-theoretic types (and its notation) may be likelihood at this point, but I haven’t heard anyone say its a certainty yet. Also, that transition would have a pretty long window, I imagine, just thinking of the consequences of such a deprecation.
So I continue to write typespecs and will do so until the actual replacement is released.
There is a very good chance the set-theoretic types will not make it very soon IMO, the complexity and intricacies involved in solving that problem is night and day compared to plain types we have in static languages, not to mention that even those are extremely hard to get right.
I personally tend to use typespecs on new projects, but they are more like mentioned by @sbuttgereit, for documentation purposes, even though in 95% of cases I always read documentation from source code . I found they sometimes can catch some nasty bugs that you never anticipated, however that is very rare and it’s more related to you passing around random data structures.
Yes, I definitely appreciate them for documentation purposes in libraries, I should have said that, but I’m working and keep getting distracted by Elixir Forum
But ya, that’s been my experience, at least writing CRUD web apps As a pro-dynamic language person, I’m always cognizant of types and find it pushes me to write code in a way where the args and return types are obvious more-or-less from a glance. Of course it’s not as clear as a spec (especially the return type). I always get annoyed during type discussions when people seem to think people are into dynamic languages so “they don’t have to think about types.” I always thought, “Other than juniors those people don’t actually exist…” but of course, we only know our own experiences and the codebase I most recently inherited was written by experienced people where functions return random types so… d’oh, ok I understand now. I’m certainly not against added safety, though, which is why I’m excited about Elixir’s proposed implementation using existing constructs with a cleaner spec syntax.
But yes, I believe José has said it’s good five years out before the type system is “done.”
I recently worked in a huge elixir project that is one big web app. There is a huge amount of devs (there are about 400 MRs per day) working at the same time on that app, so the rules are pretty constrained on what can you do there.
The reality I saw is that in some cases you have to break the rules to make the code more readable/testable and the dynamic nature helps at that a great lot. I personally hate statically typed languages because of the constrains they bring around testing, you have to make some abomination of abstractions to play around the type system, seems like a hack around limitations of the language.
That’s interesting. I have heard this before but I’ve never used a statically typed language for a serious project in my life. I recently started writing my Vim plugins in vim9script which statically typed and I did notice a large improvement in the quality of code I was writing, but that’s because legacy vimscript allows you to do some dumb stuff that I would just do because it was what I was used to (and it’s just an editor plugin). I don’t have this pain in Elixir. The 1.17 warnings are very nice, though.
There doesn’t seem to be any info about the new signatures syntax being added to the language right now or in the near future. I believe it might be added in the future, when/if it’s really needed.
The most recent pieces of info about set-theoretic types seem to be:
The spec syntax has been discussed in conference talks and on this forum. I don’t believe it’s officially documented anywhere since it’s basically an “example” at this point. I don’t have any insider info or anything but based on what I’ve heard and read it’ll be a later-stage thing.
My advice - just try using @spec and dialyzer for a while; if it starts to feel likea chore, re-evaluate.
The overhead of adding the specs is very low, and the easiest time to add it to a project is in the beginning. If nothing else, you’ll be forced to think for a second or two about the input and output types of your function.
Without typespecs, I lose a lot of autocomplete on struct fields.
Exactly. Language servers use dialyzer specs as metadata source for structs, keywords, callbacks etc. At least until there’s no replacement in elixir APIs
. I found they sometimes can catch some nasty bugs that you never anticipated, however that is very rare and it’s more related to you passing around random data structures.
As a pro-dynamic language person, I’m always cognizant of types and find it pushes me to write code in a way where the args and return types are obvious more-or-less from a glance. Of course it’s not as clear as a spec (especially the return type). I always get annoyed during type discussions when people seem to think people are into dynamic languages so “they don’t have to think about types.” I always thought, “Other than juniors those people don’t actually exist…” but of course, we only know our own experiences and the codebase I most recently inherited was written by experienced people where functions return random types so… d’oh, ok I understand now. I’m certainly not against added safety, though, which is why I’m excited about Elixir’s proposed implementation using existing constructs with a cleaner spec syntax.
