Are you sure? I would have expected it to use the normal OTP code upgrading features, and OTP uses the code_change callback to update the state of a gen_server.
@lpil Very interesting! But wouldnât it be easier to create a tool for gradual typing instead of creating your own entire language? I am just curious!
@chrismcg I saw the video, thanks for sharing!
It turns out that they started working on a type system! (yeey)
And then they stopped ⊠(ohhh)
At least they explored some alternatives, which is always good!
Thank you everyone for your kind feedback!
I have learned quite a lot here and I feel better for it.
I take it that the main reason no one is adding a typing system to Elixir now, is because of ROI and that the ecosystem currently doesnât have enough resources to devote to this challenge.
Additional, it is also very interesting to have the historical reason on why erlang didnât have strong static typing (thanks to @rvirding ).
I guess static strong typing is a lot more complex than I initially thought !
1 Like
I think the gap isnât as big as you might think. To add a type system to an existing language it needs to be gradually typed and carefully tailored to the semantics of the existing language, while if you create a new language you can design the semantics and the type system at the same time so they complement each other well.
The end result is somewhat different too. With a gradually typed language you need to add type annotations to the entire program in order to get full type safety, while with more conventional Hindley Milner type systems no annotations are required at all and you always get total safety.
8 Likes
I wouldnât say the implementation is that much more complex, the complex bit is making the choices. It always a trade-off: if I do it this then I will get XXX but I will lose YYY, which is best for our needs. For example ending up a functional language, or having non-sharing processes, or being dynamically typed.
TANSTAAFL
6 Likes
âpracticallyâ ^.^;
Exit signal would be an expandable variant type.
Messages between processes should be black boxed, thatâs the only logical way to do it, lol. ^.^
Gleam is looking awesome, people should look at it!
Black boxed type! ^.^
Of course. In 1 you can only handle things you know about anyway, itâs like receiving JSON, you have to validate it and handle when that fails. In 2 of course, thatâs how the beam works, you need to handle the unhandled message case, just like you do in Elixir now. Itâs a standard boundary problem, which like with JSON means you need to parse it out somehow, which a decomposable blackboxâd type can do.
Same as you do now, match on what you can, handle in a fallback (log a message?) what you canât.
Golang is very very verbose as a language, something built on the BEAM, like potentially gleam, can do far better.
You only need to verify what stays within the typed side. For things coming out either blackbox it and verify if you want to handle fallback, or just âlet it crashâ, as most erlang/elixir functions do when handed wrong data already.
Well it could program in guards, but those can potentially be quite slow (validating a list is only integers for example). ^.^;
I think the pattern of the BEAM already can still hold in a typed language on top, crash with invalid data, parse external data to something useful internally, etc⊠
Yep yep, I was waiting for this to pop up, the thread OP meant static typing, not strong typing. ^.^
Phoenix_live_reload is a dev only tool, it watches the filesystem for changes and recompiled and hot-loads changes. You wouldnât run it at release time.
Now for the bit I was waiting for someone to mention but it doesnât look like anyone did. Donât forget that the Gradualizer Static Typer for the BEAM is in progress. Still has some work left but it can strongly type most code already. It has revealed that a lot of typespecs in Elixir are just outright wrong (and some in erlang though not as many). ^.^
It has the ability to override types though so you can âfixâ them up without editing their source.
And yes, I have a Gradualixir library that wraps it for ease of running as a mix task, though do not that Gradualixir is in heavy flux so if it doesnât compile then please send a PR or at least an issue with the error and a reproducible file (or ignore that if it happens on all) to me. ^.^
3 Likes
If what you want is stricter build time guarantees that your functions actually implement the typespecs in @specs or @callbacks, you might find my library Hammox very useful. It contains its own strict type-value checker and you can set it up to automatically check that function calls you do in tests match the defined typespecs.
Itâs especially useful when using mocks â you want to ensure that the mock actually implements the same type signature as your real function. Hammox is actually an enhanced version of JosĂ© Mox (and the Mox readme now links to it too). You set up behaviour based mocks and all calls to them are automatically type checked.
For me it has dramatically decreased my needs for strong static type checking because I find that dynamic type checking like this, when done rigorously, can be almost as good as static. It also encourages you to actually test all code you write so itâs a win-win!
6 Likes
Forgive my ignorance, but Iâm very curious (I do not have a background in compiled languages and only a basic understanding of dynamic code upgrades). Is the takeaway here that having a statically typed language would have made dynamic code upgrades impossible because you canât have one version of the code that statically pegs a variable to a specific type while another version of the code pegs it to a different type? Would static typing end up pointing to different regions of memory? Whereas dynamic typing would allow for ârun-timeâ resolution of the variable values in memory?
Thanks for sharing your wisdom/experience!
Yes, sort of though not so much variables but functions and function interfaces. I might change an exported function so that it not only returns 3 element tuples like it did before but now also 4 element tuples. For this to work in a statically typed system I would have to find, modify and re-type all functions which are dependent on those return values. The dynamic typing may result in some calls crashing but the others will still work.
It is the difference between being able to manage modules as units and it being necessary to potentially manage the whole system as a unit.
4 Likes
Thatâs brilliant, and that makes total sense. Thank you for the response!
The static typing preventing the compile prevents those occasional calls crashing though, even if others would work.
If you added the new field of the tuple anyway onto the âendâ then it wouldnât crash in almost any language I see with static tuples though, now in the middle on the other hand⊠Lol.
Though at that size you probably want named fields via a record, which still compiles like a tuple internally. ^.^
1 Like
One thing that I really miss in Elixir is not be able to declare the types for each struct field, like we can do in GoLang.
Any technical reason for not having this implemented in Elixir/Erlang land?
You can define types for fields with Dialyzer:
defmodule Foo do
defstruct [:a, :b]
@type t :: %__MODULE__{a: integer(), b: binary()}
end
4 Likes
Check this thread Facebook is writing a new, statically typed language to run on the BEAM?!
Maybe that flows to Elixir too if itâs viable for Erlang.
2 Likes
Thanks for the suggestion, but I was not talking about Dializer, instead about Elixir itself.
Thanks for the link. I ma already following that conversation for sometime, and I hope that it would bring types to us too.
But I have the impression that the core ecosystem doesnât seem to willing for that, but I may be wrong 
I think our best chance is Gleam by @lpil.
1 Like
Sure for fastest available static typing. But Gleam is not Elixir, itâs a different language.
I suspect that even if a team stared work today it would be several years before static typing is ready for Elixir. Iâm not aware of any current work being done in this area Iâm afraid.
Not same as static typing but I can remember reading from somewhere that Elixir team is now looking into type inference.
Type inference is a part of static typing 
1 Like
I think Elixir could take inspiration from parts of Typescript for the following reasons:
- It uses a structural typing system. Meaning if two types have the same fields, they are treated as the same type. This matches very well with pattern matching.
- Typescript has similar constraints. It has to target javascript which is a dynamic language and play nice with the outside world.
That being said, I think most of typescriptâs concepts would be overkill in Elixir. (Generics for example.) But I think the following features from Typescript could be looked to for inspiration:
- Interfaces
- Union types
- type aliases
- typeof guards (could probably reuse the same guard syntax in Elixir)
I think, similar to Typescript, we wouldnât provide runtime guarantees. If a type is declared incorrectly, the code may still crash at runtime on something like a pattern match failure. The goal would be catching compile time errors and improved editor/refactoring support.
Even without the strong guarantees, this may be a worthwhile pursuit because of the productivity benefits we would get from refactoring and intellisense in vscode.
