[Vaguely2178]

Were you using Typescript with Node? I really can't imagine working on a project that's even moderately complex without static typing. Having a static type checker is like having an assistant that writes automated tests on its own, and having those tests constantly running in the background.

Refactoring code without static type checking is a nightmare. If you're using a strict statically typed ORM like Prisma [1], you can change your data model then run tsc --noEmit --watch in your terminal and the compiler notifies you of every error with their associated file names and line numbers. In VSCode you can even click the line number and it'll open the specific file where the error occurred. Before adopting Typescript, I basically never attempted large refactors, and when I did it consisted of a long process of grepping for specific symbols in the project, and manually writing lots of tedious and verbose tests to do a fraction of what the compiler does automatically.

I remember developers from the Elm community years ago constantly advocating for static typing, and thinking "this has to be hyperbolic". Richard Feldman gave a talk about how he wrote code on an airplane for hours without an internet connection, and without actually running the code, and how the compiler ensured that the code just worked [2]. Typescript is not as sound as a Hindler-Milney type system, but the benefits are similar (especially if you're running Typescript in strict mode).

[1] https://www.prisma.io/

[2] https://youtu.be/sKxEwjKQ5zg?t=384

[Kamq]

It's unlikely that the typing is their grief is around static typing, since the language they're comparing node to (elixir) is dynamically typed.

[Vaguely2178]

I'm not saying the lack of static typing is their grief, I'm saying it should be their grief.

[Vaguely2178]

Or in other words, the presence of a static typing ecosystem is one of the advantages Node has over Elixir. So while the original commenter might not care that Elixir lacks static typing, they should care because it increases productivity.

[hmmokidk]

The only reason I would want types is for specific error types that I could ideally match against instead of them being raised (in Node.js or Typescript).

In Elixir you have the option of calling functions that raise vs functions that return an error tuple so there's no contention there (the difference between function() (this does error tuple) and function!() (this raises).

Elixir also has this idea of a typespec and I have never felt I needed more, personally.

[Vaguely2178]

Typespecs in Elixir (combined with Dialyzer) give you a very limited version of what TypeScript offers. From what I understand Dialyzer is designed to only raise an error when it's absolutely certain that you're mistaken about the types in your program. While this does prevent Dialyzer from complaining about false positives, it only catches the most trivial of bugs [1].

Also even with Elixir's typespecs, static typing is only fully useful if the entire ecosystem around a language embraces it. If some of the libraries you use don't ship with type definitions, it's going to be difficult for any static analysis tool to do a decent job. Almost every major JS library either ships with its own types, or has quality third party types available via Definitely Typed. It doesn't seem like the Elixir community has really embraced static typing to the same extent that TypeScript developers have. The creator of Phoenix for example hates dialyzer [2].

[1] https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi....

[2] https://elixirforum.com/t/do-you-use-dialyzer-in-your-projec...

[h0l0cube]

> While this does prevent Dialyzer from complaining about false positives, it only catches the most trivial of bugs

Is this coming from experience? Because it surely doesn’t match mine

[erszcz]

If you're into trying out static typing in Elixir, please check out https://github.com/esl/gradient. It's still experimental, but already functional. We're happy to get any feedback or, better yet, contributions.