Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Rust at a startup: A cautionary tale

mdwdotla.medium.com

Post reply on HN
Print view View original

41–50 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#41

Post by chrisco255 »

saurik wrote: post #19
yupis wrote: 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…

Data security in a SaaS application has more to do with proper role based access to databases than with memory safety. There is nothing in Rust that provides superior role-based security for SaaS than existing frameworks in every major backend language.

Re: Using Rust at a startup: A cautionary tale

#42

Post by saurik »

lolinder wrote: post #28
saurik wrote: 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…

> while the benefits of trading safety vs. velocity go to the company, the costs go to the user This is a problem in general, but it's not a good reason to use Rust in a startup, it's a good reason to use Java or C# or TypeScript or another well-worn high-level language with static typing. Rust's niche is solving a set of security problems that most high-level languages don't have. Choosing it for a startup only real…

FWIW, immediately after leaving my comment and definitely before seeing your response--but maybe after you opened my comment to read and start your reply--I added this:

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

Re: Using Rust at a startup: A cautionary tale

#43

Post by pclmulqdq »

satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

I agree with you about Rust and the web - it's a great fit for a performance-oriented web backend.

Personally, I actually think it's a worse fit for things like kernel/embedded development than for web backends. The ergonomics of Rust are so Javascript-y that the web is natural, and other environments where C is used are a lot messier and trickier.

Re: Using Rust at a startup: A cautionary tale

#44

Post by hu3 »

andrewmutz wrote: post #31

> This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app I would love to hear what tech stack (or stacks) the HN community thinks currently allows a small team to move fastest for this type of product.

From consulting experience (depends on the team):

- Laravel

- Rails

- Next.Js or similar

- Python

- C#/Kotlin/Go

Re: Using Rust at a startup: A cautionary tale

#45

Post by warent »

csomar wrote: 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…

  Rust forces that on them, to a certain degree. Sure, you can move faster without Rust for now; but you'll pay the price later on
If you're lucky enough to be paying any price later in a startup then your business is living.

The last thing on my mind when commercializing something is future technical debt.

Re: Using Rust at a startup: A cautionary tale

#46

Post by WirelessGigabit »

63 wrote: post #15

There's a reason why we see so many articles like "we rewrote x in rust." Rust makes sense when you've scaled to the point that you're seriously considering performance. Sure, starting with rust can potentially save you time, money, and refactoring down the line but only after you've reached a point that few startups ever hit. Otherwise you're limiting yourself with slow development times (compared to, say, Python) a…

The thing with Rust is that you are enforcing so many things from the start.

I feel that it is actually harder to write bad code in Rust than it is in say, Python.

Re: Using Rust at a startup: A cautionary tale

#47

Post by ninepoints »

saurik wrote: post #19
yupis wrote: 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…

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-sensitive and security-insensitive domains. Cherry picking problem spaces where security matters and making claims about Rust goes against the spirit of the argument.

Re: Using Rust at a startup: A cautionary tale

#48

Post by saurik »

andsoitis wrote: post #26
saurik wrote: 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…

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

Re: Using Rust at a startup: A cautionary tale

#49

Post by jeffparsons »

SevenNation wrote: post #2

> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. Those three things are actually just different facets of the same thing: ownership. The bad news is that you must learn Rust's ownership model to use Rust idiomatically. The good news is that you can do a lot without learning Rust ownership model at all. Just clone all your values. Not advisable for…

And once you've learnt those things and got some experience writing real world software in Rust, you may well find yourself more productive in Rust than, say Ruby on Rails.

Context matters a lot, and you shouldn't be making tech choices based on the way the wind is blowing ("tech radars", what's hot in the blogosphere, etc.). If hiring teams to work on your mostly-CRUD app easily is a high priority, then Rust probably isn't a good choice. If you have a team that already knows Rust, and you need to add some web app / service, then Rust is a perfectly fine choice, on the grounds that support for web stuff is "good enough" now, and the best tool for the job is often the one you already know well and are already supporting.

If I'm building stuff for _myself_ and it's getting too fiddly for a bash script, then I'll always default to Rust just because _personally_ I'm way more productive in it than anything else.

Context, context, context.

Re: Using Rust at a startup: A cautionary tale

#50

Post by candiddevmike »

satvikpendem wrote: post #36

I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…

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.
Post reply on HN