[lolinder]

> 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 really improves your security if the other language you're considering is C or C++.

[dylan604]

>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 not collect/store information in the first place. If your startup depends on the collection of your user's PII, then I'd seriously question if there's a real purpose to your startup. IF your startup 100% does require the use of PII, then yes, slow the fuck down, and do it right.

[robotastronaut]

I think that’s a bit reductive. The health tech industry as a whole fits this bill — do you question if startups in that sector have a real purpose? There are loads of green engineering teams that have to figure out how to comply with really tricky data handling regulations.

[dylan604]

I'm saying that if that is your business, then don't move fast and break things. Health sector isn't going anywhere. It's not a first to market kind of situation. Take your job seriously and secure your data.

If you're some other startup that doesn't actually need PII, but realize it is a fast way to make money, then you should really soul search to ask if you're as amoral as you look to others and if you're okay with that. If not, make a better product that doesn't mean selling your soul to make a buck.

[saurik]

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.

[bryanlarsen]

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.

[tptacek]

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.

[bryanlarsen]

Ignoring error codes and left-pad style issues are common sources of security issues.

Java is more left-pad resistant than Typescript, granted.

[tptacek]

No. Rust doesn't do anything interesting to avoid supply-chain attacks.

[foundajob]

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

[bryanlarsen]

expect is a lot safer than ignoring a return code.

[lolinder]

Java and Python don't use return codes, they use exceptions. If you ignore an exception your program crashes, same as a panic in Rust.