Earlier quoted context omitted.
> as it is the user whose data or identity will be stolen. that seems a little alarmist, don't you think?
I'm sorry, do you somehow think that is a theoretical concern? I seriously won a $2M bug bounty earlier this year because the CEO of a company wanted to "move fast and break things" their way to a financial product offering :/.
Using Rust at a startup: A cautionary tale
71–80 of 355 posts
Re: Using Rust at a startup: A cautionary tale
#72Interesting. By contrast, I wish I had used less Python and more Rust for my company's product because Rust is considerably more productive. We were building gRPC and web services. I just haven't found it to be the case that developers have a very hard time learning it, but we haven't grown to the point where that would maybe be the case. We also lean heavily into microservices so "oh there's no library in Rust but t…
> Rust is considerably more productive [than Python] Can you expand on this, please?
On a big project, you are going to be reading a lot more code than you are going to be writing.
Re: Using Rust at a startup: A cautionary tale
#73Earlier quoted context omitted.
God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.
Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.
Re: Using Rust at a startup: A cautionary tale
#74I'd say the author brought a good point of why you should use Rust even for a CRUD app. (and yeah, I am a Rust fanatic and quite biased too). But hear me out. > Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. At this point, Rust is providing security and protection from technical debt. You have lots o…
Re: Using Rust at a startup: A cautionary tale
#75"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial" Great point
If you don't need performance, you might be better off using any number of safe, GC languages. (That said, I actually find the ergonomics of Rust nicer than most other languages. A rust-like language with a GC would be very nice for web backends imo.)
Re: Using Rust at a startup: A cautionary tale
#76I'd say the author brought a good point of why you should use Rust even for a CRUD app. (and yeah, I am a Rust fanatic and quite biased too). But hear me out. > Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. At this point, Rust is providing security and protection from technical debt. You have lots o…
The flip side argument for an early stage company is that if they can’t move fast they may not survive. Not having tech debt is great, but it’s better to have tech debt and be alive than no tech debt and out of business.
To be clear, I’m not personally taking a hardline position on either side here. I think these kinds of choices are always a balancing act. Moving too fast can kill your business just as effectively as moving too slow: it’s just as hard to ship changes to a permanently on fire ball of spaghetti as it is a pristinely typed piece of clockwork, and sometimes harder.
Re: Using Rust at a startup: A cautionary tale
#77Interesting. By contrast, I wish I had used less Python and more Rust for my company's product because Rust is considerably more productive. We were building gRPC and web services. I just haven't found it to be the case that developers have a very hard time learning it, but we haven't grown to the point where that would maybe be the case. We also lean heavily into microservices so "oh there's no library in Rust but t…
In my experience, Python is one of the least productive programming languages for projects with more than 3 people. If you have a big project, you are going to spend a lot more time reading code than writing it. Python is write-optimized. By contrast, using Rust makes it easy to force a readable coding style on yourself and others.
Re: Using Rust at a startup: A cautionary tale
#78Earlier quoted context omitted.
Your profile link doesn't work. Regarding `if err`, it's one thing to add it everywhere, it's another to forget and then have something break. If Go also checked for exhaustive error handling, I wouldn't mind it either.
This is pretty trivial to accomplish with linters. Where I work your build will fail if you have unchecked err's hanging around, along with a lot of other sorts of issues. No, it's not built into the language by default or anything, but is that dealbreaking?
Anecdotally this is the same argument many C++ devs make in regards to Rust safety guarantees. The difference is just...different.
Re: Using Rust at a startup: A cautionary tale
#79Earlier quoted context omitted.
The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…
You're just reiterating the author's point. Not every piece of software written faces dire security ramifications like leaking user identity. Not all software is loading or touching user data at all. Not all software is running in trusted environments. The premise is that Rust may be a good fit if security is a key concern, and even then I would argue it's likely possible to partition the domain into security-sensiti…
Re: Using Rust at a startup: A cautionary tale
#80"Rust has made the decision that safety is more important than developer productivity. This is the right tradeoff to make in many situations — like building code in an OS kernel, or for memory-constrained embedded systems — but I don’t think it’s the right tradeoff in all cases, especially not in startups where velocity is crucial" Great point
The problem is that, while the benefits of trading safety vs. velocity go to the company, the costs go to the user, as it is the user whose data or identity will be stolen. And this goes well beyond Rust and "mere" memory safety: this extends to every kind of taking things slow and being careful in your coding rather than just throwing something together and later finding out you've made a serious error. This is why…