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

151–160 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#151

Post by tikhonj »

pornel wrote: post #85
WirelessGigabit wrote: post #46

Earlier quoted context omitted.

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.

Trying too hard to write good code can be a deadly mistake for an early-stage startup regardless of the language you use. If you're really a startup, looking for a product-market fit, then you don't know exactly what you're building yet. There's a high change you're going to throw away a lot of code. e.g. you spend effort caring about scalability, flexibility, proper architecture, full test coverage — only to hand it…

Sure, but good code saves time even on really short timeframes.

Every time I've worked on—or seen other people work on—a "we must hurry at all costs project", enough time is wasted on debugging, firefighting and friction that just building a decently clean system from the get-go would have been faster. I've seen this unambiguously on "throw away" data science code meant to produce a single report (or normal science code meant for a single paper), and that's a much shorter-term effort than anything at a startup. The tradeoff is even clearer once you start working in weeks and months, much less quarters or years.

Re: Using Rust at a startup: A cautionary tale

#152

Post by Dhghomon- »

shrubble wrote: post #144

Just once I wish I could force a Rust person to use either Ada, or even an Oberon-2 derivative that spits out C code and which compiles in a flash. Then compare the experience...

As a Rust monolingual the idea of being forced to use Ada sounds like a ton of fun. (I'm really curious about it)

Re: Using Rust at a startup: A cautionary tale

#153

Post by yowlingcat »

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…

I don't think you can reasonably draw any of the conclusions you've made from the individual statements you've said. User PII being misappropriated is far more likely to come from poor InfoSec practices than from the application layer. Memory safety issues are far more likely to accrete to application layer instability and crashes more than not; now that isn't materially good, but it's apples and oranges.

Then you talk about why "startups need regulation" and the lack thereof is why "the world remains an insecure mess" which is another non sequitur drawn from statements which, while individually correct, would never combine to imply that conclusion.

The world is an insecure mess because some societies have not collectively agreed that it is more expensive to be insecure than secure.

Startups don't "need" regulation anymore than regulation is a cure for any problem. In practice, poorly drafted regulation exacerbates rather than solves the problem it is scoped to solve because it opens the door for regulatory capture based monopolies.

That said, I do agree with parts of many of your individual statements: more effective regulations would be good not just for citizens but for startups and society in general; memory safety oriented code tends to be higher ROI for everyone; the world remaining an insecure mess is a pox on global societies whereupon well deployed investment into secure infrastructure would produced significant ROI compared to the present state of the world.

Re: Using Rust at a startup: A cautionary tale

#154

Post by ocschwar »

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

That's not actually the tradeoff in my experience.

If you're willing to blindly follow the suggestions given you by the compiler about references, and clone() things when it doesn't seem to work, you'll be just as productive as a Python/Java ... programmer. You'll just not be as memory efficient as a Rust programmer who actually groks that stuff. That's the tradeoff: coder productivity versus memory efficiency.

Re: Using Rust at a startup: A cautionary tale

#155

Post by lamontcg »

The arguing about Rust seems to miss that Rust protects against more than just security bugs.

If you've ever generated some object out of some factory and then tossed it on a list of things and then gone back to generate a new object out of the factory and found that the first object you put on the list got scribbled over because you forgot to clone it, then that's a category of bugs that rust entirely prevents.

And I thought I was pretty good about reasoning about data ownership in other languages, but the borrow checker is teaching me how to be a lot more careful.

Re: Using Rust at a startup: A cautionary tale

#156

Post by TheDong »

tptacek wrote: post #126
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…

Rust is essentially not doing anything to prevent the kinds of attacks you're talking about that other mainstream languages aren't already doing. It's a clear win over C and C++! But to a first approximation zero startups are shipping ordinary applicatioins in C/C++. Rust simply isn't meaningfully more secure than Java.

I would argue that a stronger type system will generally reduce bugs, and some of those bugs will impact users (whether by corrupting their data, or breaking a feature, or even causing a security issue).

Most bugs are from the programmer having a misunderstanding about how the system works as they change it. The stronger the type system, the more potential misunderstandings can be verified statically by the compiler before they reach the user.

Other, dynamically typed languages, will require either having unit tests, or running it in prod to find that user who has a null email or whatever, and results in things going awry. Since we're talking about startups, there are of course no unit tests or users, so this is all largely academic. Like, if there are 0 users to trigger bugs, and a bug that could be statically detected by a good type system exists, does it make a sound?

Re: Using Rust at a startup: A cautionary tale

#157

Post by iepathos »

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…

Ok, for some perspective here, that 45 seconds longer is about 50-100 times how long it took to do the one liner in javascript. Extrapolate that to generally 50-100x development time for the development of an entire project and you're looking at weeks to months longer development time to solve the same problem. Rust is slower to develop in by a significant factor than js, python, ruby etc.

Re: Using Rust at a startup: A cautionary tale

#158

Post by kolbe »

justaguess2234 wrote: post #125
kolbe wrote: post #112

Earlier quoted context omitted.

I can only give you some guesses, but I think there's some false sharing type of bug going on. There's also an issue with the fact that LLVM hasn't released a target for my CPU yet (I use a Zen 4), and who knows what bugs are caused by targeting the wrong CPU. In a single threaded version, it beats C#, though not by as much as I would have expected. The essence is that I have to run the same calculation on a large ar…

Is it not because AVX-512 sets your CPU frequency to be lower?

Unclear, but the sources I've read say that's just an Intel issue.

https://www.phoronix.com/review/amd-zen4-avx512/6

Re: Using Rust at a startup: A cautionary tale

#159

Post by foundajob »

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.

> an ecosystem that prioritizes safety etc.

Idiomatic Rust code is just as cavalier regarding NPEs as Java or Python code. Because the language starts to look really gross when you make your code panic-safe. So you have an `expect` here, an `unwrap` there, and now you're going to have the exact same runtime issues as the more expressive managed languages. No Rust programmer thinks their `expect` will panic, just like no Java programmer expects something will be null. Rust does not force you to "exhaustively match".

Re: Using Rust at a startup: A cautionary tale

#160

Post by tptacek »

TheDong wrote: post #156
tptacek wrote: post #126

Earlier quoted context omitted.

Rust is essentially not doing anything to prevent the kinds of attacks you're talking about that other mainstream languages aren't already doing. It's a clear win over C and C++! But to a first approximation zero startups are shipping ordinary applicatioins in C/C++. Rust simply isn't meaningfully more secure than Java.

I would argue that a stronger type system will generally reduce bugs, and some of those bugs will impact users (whether by corrupting their data, or breaking a feature, or even causing a security issue). Most bugs are from the programmer having a misunderstanding about how the system works as they change it. The stronger the type system, the more potential misunderstandings can be verified statically by the compiler…

Stronger type systems do reduce bugs. But not all bugs are equal. When we talk about "velocity vs. safety" tradeoffs in SAAS software, we're virtually always talking about security vulnerabilities. There, it's much less clear that stronger type systems reduce vulnerabilities; in fact, the evidence mostly cuts the other way. As far as security is concerned, the major win is memory safety, and you can get that with plain 'ol Java or Python.

I'm bringing this up because in discussions like this, people tend to play fast and loose with the definitions of "safety". The kind of safety we're talking about in a decision between Rust and Java is mostly an externality to the SRE team, not to customers --- in other words, not an externality at all. An internality, if you will.

Post reply on HN