Live data from Hacker News

I love building a startup in Rust but wouldn't pick it again

propelauth.com

231–240 of 496 posts

Re: I love building a startup in Rust but wouldn't pick it again

#231
I write a lot of Rust. I think you can do a startup in rust but you need to explicitly go against the natural inclinations of rust. Rust is a great language partially because it cares about the details. It’ll do stuff like distinguish between Path and String because it treats the edgecases as important. In a startup that’s not really a priority. In fact focusing on edgecases and doing things the “right” way is completely not the point of writing code in a startup. Rust is also a great language to refactor, something that’s also not ideal for a startup to be spending cycles on.

Would I do a startup in rust? Maybe. It’d depend on the idea. But I’d take measures to avoid the natural orthodoxy of Rust.

Re: I love building a startup in Rust but wouldn't pick it again

#232

I find it surprising that so many people are arguing about the benefits and drawbacks of `?`, when in my experience the handling of Result and Option haven't been an issue in practice on the consuming side (`?`, `.unwrap()`, `.map()`, `.ok()`, if let, match, let chains, let else, etc. help a lot), but where all the pain comes from is having to declare the appropriate error type itself. Libraries like `anyhow` takes s…

I've run into similar issues and found that the `thiserror` crate ( https://crates.io/crates/thiserror ) combined w/ anyhow makes a lot of that pain go away

I would add `snafu`(https://crates.io/crates/snafu) here as a good alternative to thiserror+anyhow.

Re: I love building a startup in Rust but wouldn't pick it again

#233

I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. In the bad old days of C there were two kinds of programs: programs without correct error handling, and programs where half the loc are unhappy paths that do what exceptions do... with a huge amount of work. Today people are repeating the same mistakes of the past, putting a "?" on everythin…

The problem with exceptions isn't the syntax, but the hidden control flow (they are essentially a goto in disguise). Error union return values make a lot more sense, the rest is just syntax sugar details (and that's where opinions differ I guess).

My two main languages are C# and Go.

* C# uses exceptions, and when I code it feels exactly the right choice

* Go uses error return values, and when I code it feels exactly the right choice

For some reason both feel very much ideal in use. Maybe it is because in each case the language syntax/ethos fits very well with the choice made, and so is frictionless when developing in the flow (and if used properly of course)? Maybe some other reason. Hey ho.

Re: I love building a startup in Rust but wouldn't pick it again

#235

I find it surprising that so many people are arguing about the benefits and drawbacks of `?`, when in my experience the handling of Result and Option haven't been an issue in practice on the consuming side (`?`, `.unwrap()`, `.map()`, `.ok()`, if let, match, let chains, let else, etc. help a lot), but where all the pain comes from is having to declare the appropriate error type itself. Libraries like `anyhow` takes s…

I've run into similar issues and found that the `thiserror` crate ( https://crates.io/crates/thiserror ) combined w/ anyhow makes a lot of that pain go away

`anyhow` + `?` make writing an application as smooth as butter. You won't miss exceptions.

Don't use `anyhow` for libraries, though. You want to provide your consumers the ability to `match`.

Re: I love building a startup in Rust but wouldn't pick it again

#237
post #37

If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…

> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice.

I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested.

A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready.

Perhaps Rust is fighting the last war - the mess inside C++.

Re: I love building a startup in Rust but wouldn't pick it again

#238
post #91

I can't get it why people would prefer to add "?" to everything instead of just having exceptions which automate that behavior. In the bad old days of C there were two kinds of programs: programs without correct error handling, and programs where half the loc are unhappy paths that do what exceptions do... with a huge amount of work. Today people are repeating the same mistakes of the past, putting a "?" on everythin…

Exceptions make it considerably harder to reason about state by reading the program text. As the notion that programmers should have some actual understanding of what they write slowly becomes less unfashionable, language features that make understanding code needlessly harder are losing some of their appeal even though they speed up writing the code.

What really makes code hard to read is having multiple paths to disentangle. There is one little error deep in the call stack but you have to vandalize the 10 functions above it in the call stack to carefully separate the error and non-error paths -- what's the probability that you will end up cleaning up properly in both paths when it isn't done for you with finally? What's the probability that somebody looking at this code is really going to find the subtle error in the error path or an error in the happy path caused and hidden by the complexity of the unhappy path?

I think the first C program I saw was a type-in terminal emulator from Byte magazine around 1985 and I was struck by the akwardness of the error handling in the C stdlib, spent a lot of time looking at the code when I realized the author had "spaced it" at one point such that the error handling was wrong and thought "this sucks" but learned how to write C programs with 3x the LOC because of all the alternate paths I had to put in to handle errors.

When I saw exceptions for the first time I felt strongly liberated because I got for free what I was working for so hard in C so I got to spend more time thinking about algorithms, the needs of the customer, things like that.

Re: I love building a startup in Rust but wouldn't pick it again

#239
post #80

I disagree, I believe that Rust is a fabulous language for early prototypes. Sure, if you're going to throw away your early prototype there are better languages. But nobody ever does that. Instead your prototype evolves into your product and early expedient decisions you made that were appropriate for a prototype aren't appropriate for your product and you have a significant refactor. And Rust is the best language I…

One of the things I’ve vowed to do for my next interview cycle is set myself up an empty project with test, and it is appalling how many interviewers assume that implementation without any tests is something a senior developer won’t simply laugh at the suggestion and leave the room. It takes too long to do these basic steps and then copy them to new projects. And generators only work once, if then, which means they a…

You have to remember though that coding interviews != production code. Taken to the extreme, are you also adding logging, metrics, performance benchmarks, etc?

TDD is great if you can get it working in a tight interview time schedule - they can also reveal any misunderstandings of requirements before the actual solution is implemented!

On the flip side however, many interviewers have experienced countless folks who spend the majority of the interview time on tests and setup, only to run out of time on delivering the solution to the actual presented problem. When I feel like somebody's spending too long on these things I'll try to nudge them towards wrapping up the tests and moving onto the solution. You would be surprised though by just how frequently it's met with open hostility, by candidates with only 10-15 mins left in an hour-long interview and no solution started!

Re: I love building a startup in Rust but wouldn't pick it again

#240

I find it surprising that so many people are arguing about the benefits and drawbacks of `?`, when in my experience the handling of Result and Option haven't been an issue in practice on the consuming side (`?`, `.unwrap()`, `.map()`, `.ok()`, if let, match, let chains, let else, etc. help a lot), but where all the pain comes from is having to declare the appropriate error type itself. Libraries like `anyhow` takes s…

All these workarounds for easier Result handling truly make me wonder whether Rust will eventually evolve exceptions as a feature - of-course without explicitly terming them so.

Rust already has exceptions, they just call them panic and offer exceedingly poor language support for them.

Some people simply live in denial, believing untruths that confirm their worldview.

This is the same situation as with Go and generics. The maintainers were in denial for a very long time, before finally admitting what was obvious to some of us long before [1]

[1] https://news.ycombinator.com/item?id=8626978

Post reply on HN