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

201–210 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#201

Post by 3a2d29 »

arcticbull wrote: post #6
paulddraper wrote: post #5

> Rust is awesome, for certain things. > This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices Of course. Use Java/Kotlin or Node.js/Typescript or Go or Python for your basic web services. Easy test: Would you at least seriously consider usin…

The difference between C++ and Rust here is that Rust has a large variety of easily-accessible third-party libraries you can drop in with a one-line change to your Cargo.toml. I think the assessment is no longer that straight-forward. There's some solid crates for building these types of endpoints now, but an honest self-assessment is required to see if it really meets your needs from a staffing perspective. I'm a Ru…

You can find a GC language that does all those things that rust does but without:

1. The risk of future unsafety (a GC language will always safer than rust)

2. Faster development that's easier to change on a dime.

3. No risk of memory leaks (which can happen in safe rust)

Re: Using Rust at a startup: A cautionary tale

#202

Post by 3a2d29 »

satvikpendem wrote: post #197
3a2d29 wrote: post #195

Earlier quoted context omitted.

I would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible. Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue? If you like Result or concurrency, use a GC language wi…

Can doesn't mean will . I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue?

"Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.

I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust.

GCs prevent memory leaks, which safe rust can do. So even if you somehow make sure no unsafe is ever used, you can still introduce a hard to debug issue just because you want to use rust.

Re: Using Rust at a startup: A cautionary tale

#203

Post by 3a2d29 »

thayne wrote: post #170
candiddevmike wrote: post #50

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.

That just means you have written a lot of go. I truthfully don't notice lifetimes or the borrow checker most of the time when I write rust. I actually think that, ironically, the if err problem with go is worse for reading code than writing code. If you are used to the pattern it's not that difficult to add the `if err != nil` after a fallible function call, and as is mentioned elsewhere, linters can help catch if yo…

I feel like the err != nil issue combines with GO using initialization to 0 values to be annoying.

If you forget err != nil, well your value does actually have a value and you would think your result was 0.

Re: Using Rust at a startup: A cautionary tale

#204

Post by 3a2d29 »

satvikpendem wrote: post #197
3a2d29 wrote: post #195

Earlier quoted context omitted.

I would say that using Rust for backend APIs seems a bit off. I like Rust, but introducing languages that can be made unsafe / can at a minimum memory leak seems irresponsible. Its dumb when the C++ community refuses rust when it guarantees memory safety, so why would you bring in a language you prefer to an area that doesn't need it if it introduces that issue? If you like Result or concurrency, use a GC language wi…

Can doesn't mean will . I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

> borrow checker ensures that I don't leak memory when not using unsafe

Also to point out, you can 100% leak memory in safe rust

Re: Using Rust at a startup: A cautionary tale

#205

Post by satvikpendem »

3a2d29 wrote: post #202
satvikpendem wrote: post #197

Earlier quoted context omitted.

Can doesn't mean will . I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue? "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust.…

> "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can.

They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention.

There are no GC vs non-GC spaces. The point of Rust is to be able to have memory safety without a garbage collector, that's literally why it was made. Thus, it is expected based on that premise that we be able to use Rust wherever a GC could be used. The fact that unsafe exists does matter, as long as unsafe isn't used. I too can turn a GC language like Java into an unsafe monstrosity, by for example doing raw bytecode tinkering, does that mean that Java is now unsafe? No, unsafe is merely an escape hatch.

Re: Using Rust at a startup: A cautionary tale

#207

Post by satvikpendem »

3a2d29 wrote: post #204
satvikpendem wrote: post #197

Earlier quoted context omitted.

Can doesn't mean will . I have not once used unsafe in my API code, the API acts just as it would in a GC language. In return I get more throughput, more speed, less memory used. The borrow checker ensures that I don't leak memory when not using unsafe, so I don't worry about it.

> borrow checker ensures that I don't leak memory when not using unsafe Also to point out, you can 100% leak memory in safe rust

Yes, you're right. However, it's much harder than in other languages, and the likelihood of doing so therefore is lower. I can also leak memory in GC languages too, just to note.

Re: Using Rust at a startup: A cautionary tale

#208

Post by UltraViolence »

"I would much rather have my team sink time into debugging the occasional memory leak or type error for code written in, say, Python or Go, than have everyone on the team suffer a 4x productivity hit for using a language designed to avoid these problems entirely."

I'm not sure if I agree with this. In fact, I'm pretty sure that I don't. These "occasional" nuisances become big blockers after a while and not only decrease productivity but hurt customer goodwill as well when they're not discovered in time.

Re: Using Rust at a startup: A cautionary tale

#209

Post by kazinator »

3a2d29 wrote: post #196
kazinator wrote: post #187

Earlier quoted context omitted.

> I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type That's going to get tiresome after about half a day. Exceptions or GTFO.

I will die on the hill that Exceptions are absolutely terrible for readability and control flow and should die. Result or Go returning many values is wayyyy better.

I will bury you and then unwind your stack, and clean up everything.

Re: Using Rust at a startup: A cautionary tale

#210

Post by 3a2d29 »

satvikpendem wrote: post #205
3a2d29 wrote: post #202

Earlier quoted context omitted.

What would you say to a C++ dev refusing to use rust because their code is memory safe and they have never had a memory safety issue? "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. I like rust and do what you want in personal projects, but introducing it to a GC space when there are langauges that "can't" be unsafe is irresponsible when a GC language can offer all the upside of rust.…

> "Can" is the whole thing. A rust dev risking can is like a C++ dev risking can. They're not the same because how C++ does memory safety and how Rust does it is unequivocal. C++ is unsafe by default, Rust is not, and you are ensured it is not, as I mentioned, via things like the borrow checker. To equivocate them is to fall into the same trap you yourself mention. There are no GC vs non-GC spaces. The point of Rust…

Right but my main point is this:

Rust comes with additional risk. It is easier to leak memory, it is easier to be unsafe (especially since you can't guarantee what future other devs will do), but you gain nothing.

You get all that risk, but fearless concurrency can be done in GC languages (like Elixir) and many people have created the Result type before. So you have added risk for no benefit. Not to mention its easier to hire devs (and train devs) for other GC languages cause not everyone knows or understands the borrow checker.

Is there any advantage?

Post reply on HN