Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

71–80 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#71
post #48

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 :/.

It's alarmist because not all software is a financial product and your original statement lacks necessary qualifiers.

Re: Using Rust at a startup: A cautionary tale

#72
post #33

Interesting. 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?

Python is extremely easy to write, but hell to read. Rust code tends to be very easy to read.

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

#73

Earlier 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.

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?

Re: Using Rust at a startup: A cautionary tale

#74
post #39

I'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…

Sweet, well the large feature we just spent 9 months building at a company that has yet to turn a profit is not anything that anyone wants to use so we’re throwing your beautiful porcelain dollhouse down the basement stairs and building something else.

Re: Using Rust at a startup: A cautionary tale

#75
post #11

"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

I don't really agree with that framing. Most of the languages people use to write web apps are safe! The actual tradeoff rust is making is that performance is more important than developer productivity. It's not willing to sacrifice safety for productivity, but fundamentally the reason to use rust is that it's fast.

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

#76
post #39

I'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…

> Sure, you can move faster without Rust for now; but you'll pay the price later on.

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

#77

Interesting. 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.

Wait what? Python, if anything, has a reputation for being readable! Perhaps this is more of a criticism of dynamically typed languages in general? As the team grows, adding mypy types can help a lot.

Re: Using Rust at a startup: A cautionary tale

#78
post #73

Earlier 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?

It is dealbreaking. These days I gravitate more and more towards strongly statically typed languages over weakly dynamically typed ones, which I definitely used to use when younger. Fact is, linters are simply not the same as something built-in from the ground up. Trust me, I have written many thousands of lines of Python and Ruby, and even with linters, they don't hold a candle to even something like TypeScript in terms of type ergonomics and refactorability, not to mention even stronger languages like Haskell or OCaml.

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

#79
post #19

Earlier 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…

I would claim the author has an extremely narrow view of where safety matters. Hell: he's even using a pretty safe language (Go) as his alternative! I think the most charitable interpretation I have for the article is that he doesn't actually want to say "I refuse to sacrifice safety for velocity" but "I refuse to sacrifice performance for velocity", which just isn't the same thing.

Re: Using Rust at a startup: A cautionary tale

#80
post #19
post #11

"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…

The idea that a clever memory leak is the root cause of most stolen data instead of a phishing attack is ridiculous
Post reply on HN