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

211–220 of 355 posts

Re: Using Rust at a startup: A cautionary tale

#211

Post by satvikpendem »

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

Earlier quoted context omitted.

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

I mentioned the benefits elsewhere. Faster, more throughput, uses far less memory, more ergonomic developer experience (Elixir for example is not statically typed), rock solid stability (my API and anecdotally those of others I hear have never crashed). The risk is small compared to the benefits. I'm not sure why you keep saying there aren't benefits because there are. Now you might not agree they're good enough for you, but they exist.

Re: Using Rust at a startup: A cautionary tale

#212

Post by UltraViolence »

3a2d29 wrote: post #195
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 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…

The big win with Rust is that it's not only memory-safe but also thread-safe, which is hugely important in a web application.

IMHO C# is also an excellent choice, but there's a lot going on behind the covers to keep it working properly in a multi-threaded web environment. This mostly doesn't concern you as a developer, until it bites you.

Re: Using Rust at a startup: A cautionary tale

#213

Post by MrJohz »

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

The difference is that it's fairly easy to prevent unsafe code from occurring: a "forbid(unsafe_code)" directive prevents unsafe code from even being accepted by the compiler. In C++ there is no equivalent - good linting can prevent some obvious errors, but a lot of valid code is inherently unsafe (in the Rust sense) if used incorrectly or under the wrong assumptions.

It's also worth pointing out that most GC languages can have the same issues as a Rust program (if not more) just by virtue of having FFI. In Python, I can quite happily load a C extension and ignore all the rules. Whereas in Rust, if I want to use a C library, I still need to explicitly declare it as unsafe code.

In practice, I tend to find that I have to think more about how I approach parallel/multi-threaded code in Rust than I do in other languages - not because it's dangerous, but because the compiler doesn't allow code that would break memory safety guarantees. In some ways, that's obviously a bad thing if I'm having to think more, but in my experience, the thoughts often lead to a better design anyway. So in the end, I'm more confident in my Rust code than I am in equivalent code in a GC language.

Re: Using Rust at a startup: A cautionary tale

#214

Post by virtualritz »

fooker wrote: post #101

This matches my experience. I have been doing compiler development in C++ for about 10 years, lisp before that and a bit of python more recently. We could not figure out how to be productive in Rust after starting a greenfield project and sticking to it for a month. Luckily this was not a project which requires incremental updates, we were on the verge of rewriting it in C++.

Yes, this matches my experience.

It took me almost a year to be as productive (and my code as canonical) in Rust as I was after over two decades of C++.

After a month of Rust I was still fighting the borrow checker and grokking basic concepts of the language. So no surprise in what you wrote.

However, after that year I am probably a factor of two to ten more productive in Rust.

The speedup is about two for everyday code (if it compiles it runs and doesn't crash). Ten (or more) when I need to bring in a dependency.

To qualify the latter: if a crate with same functionality or a Rust wrapper for a C/C++ lib exists, the factor can be much, much higher than ten since it is just adding a line to Cargo.toml.

If the dependency is a C/C++ lib it is as slow as using it from C++. It needs to be integrated with the build and that takes about the same time plus writing/generating a wrapper.

All that said: I had to write code in C++ the other day again. It almost felt painful after three years of only Rust.

Re: Using Rust at a startup: A cautionary tale

#215

Post by MrJohz »

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

You can 100% leak memory in pretty much every language though: just use a bad caching/memoisation strategy, and you'll have memory leaks for days. Leaking memory isn't in of itself a problem, and it can be a very valid strategy for short-lived programs where you can rely on the OS to do the ultimate garbage collection run anyway. It's only a problem in the sense that uncontrolled memory acquisition will inevitably lead to the system running out of memory to acquire, but that's also true if you're accumulating memory for perfectly legitimate reasons.

Re: Using Rust at a startup: A cautionary tale

#217

Post by n30phyte »

satvikpendem wrote: post #83
necubi wrote: post #75

Earlier quoted context omitted.

I don't really agree with that framing. Most of the languages people use to write web apps are safe! The actual tradeoff rust is making is that performance is more important than developer productivity. It's not willing to sacrifice safety for productivity, but fundamentally the reason to use rust is that it's fast. If you don't need performance, you might be better off using any number of safe, GC languages. (That s…

Have you tried ReasonML?

Isn’t it called ReScript or something now?

Re: Using Rust at a startup: A cautionary tale

#219

Post by Aeolun »

candiddevmike wrote: post #50
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.

I dunno, if my exceptions would have to be manually rethrown every time, I’d get really cranky very quickly.

I don’t think that’s any better in Rust though.

Re: Using Rust at a startup: A cautionary tale

#220

Post by RamblingCTO »

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.

If it's complex business logic and will grow bigger: Kotlin + Micronaut/Spring Boot + Krush/Hibernate If it's quite simple and has a clear outlined border: Go + Gin

Add login and auth and stuff via ory/keycloak

Post reply on HN