Good read. 6 years is some solid experience. Thanks for writing this up @crowdhailer.
It was quickly obvious that working in Gleam was more productive than Elixir.
[…]
Fearless refactoring is real and a type system with essentially full inference allowed us to make changes faster and try more things.
I’ve had the exact same experience with Rust and Python. At my previous job we had a lot of discussion on the merits of using Rust (some teams used it, others didn’t want to touch it), and the development speed was an argument I couldn’t even use because it was so unthinkable that it could be faster to build micro services in Rust than in Python.
You are missing a lot of context and clarity that I did not provide. ;-) My bad.
In discussions where I was arguing for Rust (against developers who hadn’t tried it), I could not use the argument that it was faster to write new services in Rust than in Python. The reason I could not use that argument was that it was completely unthinkable that this could be true. I had to use arguments about maintainability, stability, hardware cost, etc. But never raw speed of development.
Another reason was that it’s a very subjective measurement. What’s true for me (or our team) wasn’t necessarily true for others.
Why was it faster for us though? Because the editor does half the (tedious) work for you when you have a good type system.
OP is saying that development in Rust, with its strong type system and type inference, is faster than Python. Modern editor/IDE support really makes this pop.
During my experiment with Gleam a few Advent of Codes ago, this stood out to me as well. In general I prefer Elixir as a BEAM language, but having pervasive type inference in VS Code when I was using Gleam was reeeeally nice.
The IDE constantly annotating types in my code was really good. I wish Elixir did this. We might get there, with the gradual typing work that the Elixir team has been working on for the last couple years.
Why do I prefer Elixir? Two main reasons:
Elixir is a language that is designed to take advantage of Erlang/OTP’s strengths (GenServers, Supervisors, ETS to name a few). Gleam, at the time I used it around two years ago, had only middling support for that, though I see the gleam_otp library has come a long way since. Calling into Erlang code is effortless from Elixir, but requires a shim layer in Gleam in order to advise the compiler about types.
Elixir macros are great. Being able to execute code in the caller’s context is a real power tool. There’s nothing stopping Gleam from growing a macro system, but it has none to date.
For the most part, Gleam and Elixir have the same, comfortable FP style: impure, fully namespaced, pipeline-oriented. I enjoy both languages for this reason. I’m just not ready to trade away a macro system and free access to OTP for better IDE hints.
It’s so non-obvious to me that I’m not even sure if you’re saying it’s faster in Rust or faster in Python
I think @Casperin is saying that it’s faster to write code in Python because anything in Python runs and hopefully won’t throw exceptions. It’s harder in Rust because you spend more time making sure the types and lifetimes are correct. But these benefits flip when you stop talking about writing code and start talking about maintaining code. All of that up-front work in Rust makes refactoring a lot easier when the requirements change and so the total time in Rust is lower, even though the time to first working version may be longer.
Good read. 6 years is some solid experience. Thanks for writing this up @crowdhailer.
I’ve had the exact same experience with Rust and Python. At my previous job we had a lot of discussion on the merits of using Rust (some teams used it, others didn’t want to touch it), and the development speed was an argument I couldn’t even use because it was so unthinkable that it could be faster to build micro services in Rust than in Python.
It’s so non-obvious to me that I’m not even sure if you’re saying it’s faster in Rust or faster in Python. What am I missing?
You are missing a lot of context and clarity that I did not provide. ;-) My bad.
In discussions where I was arguing for Rust (against developers who hadn’t tried it), I could not use the argument that it was faster to write new services in Rust than in Python. The reason I could not use that argument was that it was completely unthinkable that this could be true. I had to use arguments about maintainability, stability, hardware cost, etc. But never raw speed of development.
Another reason was that it’s a very subjective measurement. What’s true for me (or our team) wasn’t necessarily true for others.
Why was it faster for us though? Because the editor does half the (tedious) work for you when you have a good type system.
OP is saying that development in Rust, with its strong type system and type inference, is faster than Python. Modern editor/IDE support really makes this pop.
During my experiment with Gleam a few Advent of Codes ago, this stood out to me as well. In general I prefer Elixir as a BEAM language, but having pervasive type inference in VS Code when I was using Gleam was reeeeally nice.
You’re saying it was really good but you still like Elixir better? Care to elaborate?
The IDE constantly annotating types in my code was really good. I wish Elixir did this. We might get there, with the gradual typing work that the Elixir team has been working on for the last couple years.
Why do I prefer Elixir? Two main reasons:
For the most part, Gleam and Elixir have the same, comfortable FP style: impure, fully namespaced, pipeline-oriented. I enjoy both languages for this reason. I’m just not ready to trade away a macro system and free access to OTP for better IDE hints.
I feel like this is getting too OT but what do you mean by pipeline oriented?
I mean that libraries are optimized to use the
|>pipeline operator.I think @Casperin is saying that it’s faster to write code in Python because anything in Python runs and hopefully won’t throw exceptions. It’s harder in Rust because you spend more time making sure the types and lifetimes are correct. But these benefits flip when you stop talking about writing code and start talking about maintaining code. All of that up-front work in Rust makes refactoring a lot easier when the requirements change and so the total time in Rust is lower, even though the time to first working version may be longer.