I agree.
Readable and clear.
arcyfelix
sergio
I think deft is a little more specific and unmistakable. Easier to global search, parse at a glance, etc. It could live tight right next to the function definition.
deft User.t() -> list(User.t())
def list_companies_for_user(user) do
query =
from c in Company,
join: cu in assoc(c, :company_users),
where: cu.user_id == ^user.id,
select: c
Repo.all(query)
end
$ can be a part of an ENV var, jquery, javascript, hooks, or just plain old cash reference in a template somewhere. Too messy and overloaded.
1
sodapopcan
It’s $ (note the space) and always the start of a line, so I’d say it’s unique enough in terms of grepability. Just limit to Elixir files.
5
saleyn
Regarding deft - that name is more appropriate for private functions that need to have visibility to test suites. This is easily accomplished by using macros, and has been used in a number of projects. So it doesn’t sound like a good idea to select that keyword.
Why not using @type or @spec instead of $ for this purpose?
1
sergio
I don’t think Elixir should usurp @type or @spec and pull out the rug from devs. I remember reading somewhere that the intent behind this is gradual typing for those that want it. Not “hey you’re on Elixir 1.7, it’s typed now”.
5
barttenbrinke
Nice work @josevalim ! I only know typing from Typescript and there I hate it with a vengance, but in Elixir I really like the guards and multiple function heads to catch errors early so I hope this will also help with that. My main beef with Typescript is that for me the spec gets in the way of the creative development process, so I am excited to see how this will work in Elixir. 
4
Aadmaa
It’s interesting how many of us experience the same tooling differently. I love Typescript. Having types speeds up my process a lot more than writing types slows me down; and writing types often helps me think through what I am trying to create - similar to writing a test before a function in TDD. But I can see how that’s not true for everyone and that’s a great thing about this gradual typing approach.
I’ve gotten to play with Elixir and Phoenix for just a couple months now and it is super cool. But trying to figure out what types some function takes, and what it returns, burns quite a lot of extra time and mental energy. For an experienced Elixirist it may be second nature to know if something might return a tuple or a value; and whether it takes a string or an atom; that sort of thing. But for learning/onboarding - I’m pretty stoked about this project.
It’ll save newer Elixir devs like me so much time of constantly trying to figure out what arguments a function is supposed to take, and what it’s supposed to return, when the IDE knows and you can just “hover” or open the parentheses for a new function call - and there are the argument types. And hover over the return variable, and there’s the return type. Dreamy…
2
hubertlepicki
I would 100% quit and never look back if they turned Elixir to TypeScript-like typed language. I understand people like it but I fully agree with @barttenbrinke here, for me it’s a nightmare and entirely unnecessary complication.
4
redrapids
Author of Adopting Elixir
I for one think this is the most significant development in Elixir since NX. Since Seven Languages in Seven Weeks, I have looked at dozens of languages. To me, the thing that sets Elixir apart is the amount of thought and foresight that’s gone into considering the constraints of Elixir, Erlang, and all of the disparate users on the platform.
The work is amazing, and far surpasses my expectations.
11
D4no0
Generally speaking, if elixir team manages to pull this off, this might as well be the future of typing in the languages to come.
For example currently you want to type a parameter that is the port, the only way in all languages (as far as I know) is to mark it as integer, when in reality the range is 0 to 65535. This can lead to finding a series of bugs that was possible only at runtime previously, even in statically typed systems.
5