[pkos98]

I've been writing Elixir on-and-off since 2017 for personal projects and since 2024 professionally, at a big tech company.

The two experiences couldn't be more different. While I loved the great development speed for my personal projects, where I am writing more code than reading it, joining an existing project needs the opposite, reading more code than writing it. And I can only repeat what many people say, dynamic typing makes this so much more difficult. For most code changes, I am not 100% certain which code paths are affected without digging a lot through the code base. I've introduced bugs which would have been caught with static typing.

So in my conclusion, I'm bullish on gleam, but also on other (static) languages embracing the cooperative green-thread/actor model of concurrency like Kotlin (with JVM's virtual threads). (On another note, I personally also dislike Phoenix LiveView and the general tendency of focusing on ambiguous concepts like Phoenix Context's and other Domain Driven Design stuff)

[sethammons]

I worked a year or so at an Elixir shop, and this mirrors my experience. I had to navigate to call sites to understand what I was being passed and type hints were not sufficient. Dynamic typing fails larger orgs/teams/codebases.

Fun to develop and solo administer. Small teams with a well known codebase can do amazing things. I work at orgs with multiple teams and new hires who don't know the codebase yet.

For me, the sweet spot is Go.

[Miner49er]

Out of curiosity, at the tech company, did the team use typespecs and dialyzer?

[conradfr]

The lack of type hint for function parameters is definitely a productivity killer (in my case).

[dmytrish]

There are type hints for function parameters. With some care and guards, Dialyzer can be somewhat helpful.

What actually drove me nuts was absence of guards and meaningful static analysis on return values. Even in my small but nontrivial personal codebase I had to debug mysterious data mismatches after every refactor. I ended up with a monad-like value checking before abandoning Elixir for my compiler.

[foldr]

Fully agree with this based on similar experiences. IME most devs hired without previous Elixir/Phoenix experience don’t end up liking the tech stack very much, even though they become productive quite quickly and don’t struggle too much with Elixir. A lot of Elixir/Phoenix fans make the mistake of thinking that everyone is going to love it as much as they do once they get up to speed.

[mhitza]

Isn't there some kind of optional typing in Elixir?

What you're describing are the same uncertainties I've used to have writing PHP a long time ago, but since using optional types and PHPStan checker, it kind of serves as a compiler pass that raises those issues. The benefit being that I still can be lazy and not type out a program when I prototype the problem on my first pass.

[foldr]

>Isn't there some kind of optional typing in Elixir?

It’s in the works and recent versions of the compiler already catch some type errors at compile time, but it’s nothing remotely close to what you get from Typescript, or from any statically typed language like Go, Rust, Java, etc.

[bevr1337]

> Isn't there some kind of optional typing in Elixir?

Sort-of. Developers provide typespec which is like a hint and use dialyzer to find issues before runtime.

[phplovesong]

This is why Gleam exists.

[SwiftyBug]

Also, Gleam fully supports Elixir packages.

[fteem]

I am now super curious which big tech company is betting on Elixir?

[SwiftyBug]

Nubank, Latin America's most valuable bank, relies heavily on Elixir and even acquired Plataformatec, the company where Elixir was created.

A blog post by them about this: https://building.nubank.com/tech-perspectives-behind-nubanks...

[pkos98]

it's just an internal I/O-bound project, where BEAM concurrency makes lots of sense. Grown from an engineer's side project as it was useful and working well, not a company-wide effort to bet on Elixir