Celebrating the 10 Years of Elixir | José Valim | ElixirConf EU 2022

Learning Resources Talks
,
1

Code Sync: Celebrating the 10 Years of Elixir | José Valim | ElixirConf EU 2022

Comments welcome! View the #code-sync and #elixirconf-eu tags for more Code Sync and ElixirConf EU talks!

15 Likes
2

If you’re interested in types… you may be interested in this talk :lol:

7 Likes
3

And here is a link to the paper José talks about: https://www.irif.fr/~gc/papers/set-theoretic-types-2022.pdf

5 Likes
4

If you’re not interested in types … you too may be interested in this talk :lol:

3 Likes
5

That’s what I was going to post first… but I chickened out :lol:

6

Most of my social circle, and my parents, worked at the CNRS in some capacity. I thoroughly appreciate the collaboration (even if the institution is a weak shadow of its former self).
I also think it’s great that José invests some of his time in a project that might not pan out, and acknowledges that. This makes me think that his views align with mine and I like it (the language and toolset stays pragmatic, but it might be an option to push it further, and if it fails, we’ll learn at least how it has failed).
One thing that rubbed me the wrong way -and it’s not essential to the point, and I haven’t read the original article- but it seemed that the measure, when comparing ts and js was the number of bug fix commits. An explanation that in js the bugs are never caught, thus never fixed. Anyway, I would still agree on the conclusions presented in the talk: it’s complicated.

1 Like
7

Also, using random in the example as to why bugs wouldn’t get caught is not great, since a nitpicker might argue that random being side-effecty it should really be wrapped in another structure in a pure language. (Again the point holds and this is a minor nitpick).

1 Like
8

If they are never caught, then they aren’t an issue :slight_smile:

Worked today at further Typescripting a project. All bugs found were typing issues (hello Immutable.js v3) and they were pretty hard to solve, even for the Typescript-addicted at my team. Added business value today: 0.

1 Like
9

José’s blog post about this has just gone up :023:

Here’s a copy of José’s post on EFS:

Hi everyone,

I would like to announce there is an open position for a post-doc project to research polymorphic records in the context of Erlang/Elixir: Giuseppe Castagna: Post-doc project description

The proposal mentions Elixir, but the data types and their usage are the same in Erlang and Elixir, so the project and its theoretic results apply equally to both languages.

For more context, I have published an article about set-theoretic types in the context of Elixir (which, once again, would fully apply to Erlang) here: My Future with Elixir: set-theoretic types - The Elixir programming language

So if typing theory is an area of interest, please do consult the linked page.

Great opportunity for a typing fan :003:

1 Like
10

This is really nice, types and better IDE support, both things that I enjoy a lot being a Java dev :sweat_smile:

1 Like
11

I finally had the chance to read Jose’s blog post and I found myself agreeing with it through and through. The point that most stuck with me is that we shouldn’t try to achieve with types in Elixir what can be achieved with them in e.g. Rust; that we should focus on reusing existing typing info in guards and typespecs and try introducing some compiler warnings (or errors) through that (he mentioned programming by contract in relation to that). Absolutely!

@josevalim If I may: I realize this effort is long term and will be “gradual introducing of gradual typing” and I 100% agree with that plan. I have to mention what I’d like to see first made possible by this effort:

Exhaustive pattern matching wherever possible. A lot of APIs explicitly document that they will only ever return an :ok or :error two-tuple. So code like the following should probably yield a compiler warning?

case Repo.update(...) do
  {:ok, record} -> record
  other -> other
end

I’d like to see something like the following printed by the compiler:

“Consider replacing other with {:error, reason}”

Rust’s Result and Option have saved me from making mistakes, many times. I’d love seeing those put in Elixir somehow (even if not mandatory which is what will happen anyway; too much code to modify otherwise).

RE: assertive coding style, I am 50/50 on that. I have seen it working in practice: people notice a crash in their error reporting system and just tighten the code in question. While that works I’ve also been in projects where this introduces extra workload on other people e.g. support that now has to call Stripe and their bank and the customer who still wants to spend money but right now can’t (or they spent the wrong amount and now support has to patch all this up through meat-space means).

Assertive coding style is great until one day it isn’t. A bit more potential for eliminating potentially real-life harmful events in the code would be highly appreciated.

As you yourself allude to, I don’t expect Elixir to turn into Rust. I only want a bit more compiler insights.

Thank you for the write-up, it was very illuminating and interesting.

1 Like