I haven’t built a startup in rust, but having worked a little in rust this stood out to me:
The Rust compiler is a thousand unit tests that you don’t have to write, it’s your best friend that never stops loving you.
In the beginning of a project, you can move fast because your business logic is small and poorly defined. As a project gets older, you start to realise a lot of your assumptions stop holding: ‘wait, these two things can happen at the same time, this has to happen before this, x needs set before y and actually z can’t exist at this stage.’
A lot of my time in the last 3-6 months has been spent investigating mysterious concurrency bugs that have built up over the last 5 years of a project. Having to address them now involves figuring out the assumptions made by somebody up to 5 years ago which is time-consuming and full of landmines! Ah how I think to myself ‘if this had been written in rust, this bug probably wouldn’t exist’.
Of course nothing is a silver bullet, but there’s something to be said for getting the hard questions asked at the beginning (when they’re fresh!).
I know it’s not central to the point of the article, but I don’t think Pulumi will be relevant in ten years except at businesses that start to use Pulumi in the next ten years. The upside to Pulumi of it using a language you already know the syntax of is cool and quirky but I don’t care if technically it’s declarative because you build a DAG, it’s still written in imperative, turing-complete code with all the footguns that brings.
So far every time I’ve had to deal with infrastructure, I’ve ended up using “imperative, turing-complete code” to “build a DAG”, because traditional tools just aren’t good enough. And I think that’s mostly because there is very little abstraction capabilities using tools that are essentially configuration languages with some primitive templating support. Just look at what has to be done in Terraform to have optional components - you have to set the count of them to imitate a simple if.
The main benefit of such tools isn’t that they bring you the syntax of conventional languages, but that they bring you abstraction capabilities of conventional languages - and I feel like that’s not being properly advertised by any of the existing tools. But I can say that the abstraction capability has helped people in my team that aren’t “infrastructure specialists” to regularly contribute to infrastructure, and not because they don’t need to learn Terraform, but because they can freely compose abstractions that people with more experience in infrastructure have already built.
A “simple if” is only simple because you’re doing something simple and I assume you’re a pretty smart, switched-on guy with good coding hygiene. The logic behind count is perfectly fine - it’s not “imitating” an if-statement, it’s a loop with a counter, which will happily be set to 0.
Enabling or disabling components by setting their count leaves the same taste in my mouth as only using lambdas to program in Python does - you can do it, but it’s definitely not the best way of doing it and you are loosing a lot of clarity by doing it this way.
I was thinking about settling on Rust for a web app, but I got stuck on the number of things that I would need to build from scratch or replace because they weren’t done right. For example, this project encrypts data into a cookie for sessions instead of putting a nonce session id in a cookie and keeping the necessary information on the server.
I’m still debating whether I take the plunge and build this stuff out correctly or go use a mature stack like Spring.
For example, this project encrypts data into a cookie for sessions instead of putting a nonce session id in a cookie and keeping the necessary information on the server.
That is a standard practice for saving on database load, and depending on a few things (what you’re storing, strength of your secret, algorithm being used) doesn’t fall under a blanket “wrong” label. Not saying it’s right for every use case, but what were your specific concerns?
It can’t save on database load, though, because I still have to check for session revocation.
If I have to hit the database anyway, then on one hand I have keeping an encryption key secure and getting it deployed to my servers and making sure I get my crypto right. On the other hand I have generating a uuid or similar and sticking it in a cookie with no encryption necessary. One of these is drastically safer and less error prone than the other.
I haven’t built a startup in rust, but having worked a little in rust this stood out to me:
In the beginning of a project, you can move fast because your business logic is small and poorly defined. As a project gets older, you start to realise a lot of your assumptions stop holding: ‘wait, these two things can happen at the same time, this has to happen before this, x needs set before y and actually z can’t exist at this stage.’
A lot of my time in the last 3-6 months has been spent investigating mysterious concurrency bugs that have built up over the last 5 years of a project. Having to address them now involves figuring out the assumptions made by somebody up to 5 years ago which is time-consuming and full of landmines! Ah how I think to myself ‘if this had been written in rust, this bug probably wouldn’t exist’. Of course nothing is a silver bullet, but there’s something to be said for getting the hard questions asked at the beginning (when they’re fresh!).
Cool to learn a new word “elide”.
I know it’s not central to the point of the article, but I don’t think Pulumi will be relevant in ten years except at businesses that start to use Pulumi in the next ten years. The upside to Pulumi of it using a language you already know the syntax of is cool and quirky but I don’t care if technically it’s declarative because you build a DAG, it’s still written in imperative, turing-complete code with all the footguns that brings.
And terraform is the lingua franca of infrastructure as code as of today anyway.
So far every time I’ve had to deal with infrastructure, I’ve ended up using “imperative, turing-complete code” to “build a DAG”, because traditional tools just aren’t good enough. And I think that’s mostly because there is very little abstraction capabilities using tools that are essentially configuration languages with some primitive templating support. Just look at what has to be done in Terraform to have optional components - you have to set the count of them to imitate a simple
if.The main benefit of such tools isn’t that they bring you the syntax of conventional languages, but that they bring you abstraction capabilities of conventional languages - and I feel like that’s not being properly advertised by any of the existing tools. But I can say that the abstraction capability has helped people in my team that aren’t “infrastructure specialists” to regularly contribute to infrastructure, and not because they don’t need to learn Terraform, but because they can freely compose abstractions that people with more experience in infrastructure have already built.
A “simple
if” is only simple because you’re doing something simple and I assume you’re a pretty smart, switched-on guy with good coding hygiene. The logic behind count is perfectly fine - it’s not “imitating” an if-statement, it’s a loop with a counter, which will happily be set to 0.Enabling or disabling components by setting their count leaves the same taste in my mouth as only using lambdas to program in Python does - you can do it, but it’s definitely not the best way of doing it and you are loosing a lot of clarity by doing it this way.
I’m sorry you’ve reached the conclusion that bloat is better.
I was thinking about settling on Rust for a web app, but I got stuck on the number of things that I would need to build from scratch or replace because they weren’t done right. For example, this project encrypts data into a cookie for sessions instead of putting a nonce session id in a cookie and keeping the necessary information on the server.
I’m still debating whether I take the plunge and build this stuff out correctly or go use a mature stack like Spring.
That is a standard practice for saving on database load, and depending on a few things (what you’re storing, strength of your secret, algorithm being used) doesn’t fall under a blanket “wrong” label. Not saying it’s right for every use case, but what were your specific concerns?
It can’t save on database load, though, because I still have to check for session revocation.
If I have to hit the database anyway, then on one hand I have keeping an encryption key secure and getting it deployed to my servers and making sure I get my crypto right. On the other hand I have generating a uuid or similar and sticking it in a cookie with no encryption necessary. One of these is drastically safer and less error prone than the other.