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

131–140 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#131

Post by tptacek »

saurik wrote: post #66
chrisco255 wrote: post #41

Earlier quoted context omitted.

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.

I don't disagree, but it sounds like you somehow magically think someone who refuses to trade off velocity for safety--which was a genetic premise that doesn't have much to do with Rust in specific--won't also mess up everything else they touch, which seems far fetched.

I think you're excluding too much of the middle here. Exchanging Rust for Java isn't a meaningful concession to safety, but it is a significant boost to velocity. If you can use Java for your problem domain, Java is probably just objectively better suited to your problem than Rust is.

Re: Using Rust at a startup: A cautionary tale

#132

Post by brundolf »

tejinderss wrote: post #129
brundolf wrote: post #22

Earlier quoted context omitted.

I cast glances at it every time my company's Python services break because of a runtime error that could have been caught with a better type system, or because they ran out of memory and need bigger boxes, or another developer has to spend a week debugging their environment to get the complex web of dependencies aligned for five minutes, or my laptop strains under the weight of a dozen docker containers attempting to…

> I realize Go has at least some of these benefits, but its type system is hard for me to stomach Can you elaborate on the issues of Go's type system?

Biggest one is lack of null-safety. The preference for implicit value defaults, sketchy error-handling, and similar choices also rub me the wrong way. The whole thing just feels too fast-and-loose for my tastes

I'm the thousandth person to suggest this, but my ideal language for web servers and lots of other things would be Rust with a GC instead of a borrow-checker. But Rust has its unique killer-feature to thank for a lot of the traction it's gotten, so it's very possible this hypothetical language never would have taken off in the first place. We've got what we've got, languages are social constructs just as much as technical ones, maybe even more so

Re: Using Rust at a startup: A cautionary tale

#133

Post by jvanderbot »

dap wrote: post #84
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

This doesn't match my experience. It took some time to get up to speed, but at this point it's much faster for me to write something in Rust than in other languages that I'm proficient in that are ostensibly faster to develop in (e.g., JavaScript). Part of this depends on one's bar for quality. In Node.js I could write `JSON.parse(input).foo.bar` really quickly. In Rust, I'd probably write two struct definitions with…

If you're comparing Rust favorably to JavaScript, and then concluding it's the right tool, I think you need more data points.

Re: Using Rust at a startup: A cautionary tale

#134

Post by foundajob »

saurik wrote: post #79
ninepoints wrote: post #47

Earlier quoted context omitted.

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.

Well, no, the prudent choice for someone concerned with "safety" in this context is any high-level memory managed (GC) language. It's any boring language that has no `unsafe` at all. What you're actually saying is "I'm willing to sacrifice safety for performance," as invariably the objection to a high-level GC language by Rustaceans is that it lacks the necessary lolspeed.

Re: Using Rust at a startup: A cautionary tale

#135

Post by bgoldste »

Patrol8394 wrote: post #121

Rule number one at startups: write things that don’t scale and use mature, boring frameworks/languages. The goal is to deliver products and iterate as fast as possible. Productivity is key to success. IF (and it is a big IF) your startup ever gets to the point of having to scale up (nice problem to have) then just throw money at AWS, hire senior engineers and let them figured it out. What matters is customer experien…

This guy startups.

Re: Using Rust at a startup: A cautionary tale

#136

Post by bryanlarsen »

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…

Rust's safety goes far beyond memory safety. Java or C# or Typescript don't force you to handle errors and don't force you to exhaustively match and don't have an ecosystem that prioritizes safety etc.

Re: Using Rust at a startup: A cautionary tale

#137

Post by bacon_waffle »

willgleich wrote: post #113
bacon_waffle wrote: post #98

Earlier quoted context omitted.

Could you expand on this? It doesn't really make sense to me, but I'm also a Rust fan. The premise that Rust prioritizes safety (or performance) over developer productivity also doesn't resonate. As a consumer, I tend to prefer the thing that is available a bit later (or more expensive) and works well, versus the one that is available sooner (or cheaper) and is less reliable. Maybe that preference is a result of year…

I believe the point TylerE is trying to make is that features that take longer to deliver are a cost to the user. If a user is waiting on a feature, or perhaps a bug fix and that is taking 4x the time to deliver - the cost is right there on the user's clock waiting. Many people would argue you with you that the "easier" programming languages are no less reliable, context depending. Framing this in the context of the…

I feel like that boils down to "time is money", and I don't disagree in a commercial context.

Re: Using Rust at a startup: A cautionary tale

#138

Post by [deleted] »

Patrol8394 wrote: post #121

Rule number one at startups: write things that don’t scale and use mature, boring frameworks/languages. The goal is to deliver products and iterate as fast as possible. Productivity is key to success. IF (and it is a big IF) your startup ever gets to the point of having to scale up (nice problem to have) then just throw money at AWS, hire senior engineers and let them figured it out. What matters is customer experien…

[deleted]

Re: Using Rust at a startup: A cautionary tale

#139

Post by tptacek »

bryanlarsen wrote: post #136
lolinder wrote: post #28

Earlier quoted context omitted.

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

Rust's safety goes far beyond memory safety. Java or C# or Typescript don't force you to handle errors and don't force you to exhaustively match and don't have an ecosystem that prioritizes safety etc.

Very little --- I'll go ahead and say, to a first approximation, none --- of that safety has anything to do with software security. The same kinds of bugs that hit Java programs hit Rust programs, with maybe the sole exception of deserialization (which has nothing to do with error handling or type safety).

That matters because that's the kind of "safety" we're talking about when we discuss externalities for end-users --- not servers that need extra monitoring because they might crash.

Re: Using Rust at a startup: A cautionary tale

#140

Post by bessiesboobies »

brundolf wrote: post #132
tejinderss wrote: post #129

Earlier quoted context omitted.

> I realize Go has at least some of these benefits, but its type system is hard for me to stomach Can you elaborate on the issues of Go's type system?

Biggest one is lack of null-safety. The preference for implicit value defaults, sketchy error-handling, and similar choices also rub me the wrong way. The whole thing just feels too fast-and-loose for my tastes I'm the thousandth person to suggest this, but my ideal language for web servers and lots of other things would be Rust with a GC instead of a borrow-checker. But Rust has its unique killer-feature to thank fo…

Kotlin and Scala exist
Post reply on HN