Live data from Hacker News

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

propelauth.com

101–110 of 496 posts

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

#101

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…

There's some subtlety here: 1. Exceptions have very high performance costs (equivalent to a longjmp which is very slow), so if you expect to have exceptional cases, it's probably a lot more efficient to not use exceptions. 2. Exceptions break the linear flow of the code when you read it, so now you have to read a lot more code to figure out what the exception paths are and where and how they are handled.

> Exceptions have very high performance costs

On the sad path. On the happy path they are faster than explicit error checking.

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

#102

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…

I prefer having extra work done writing code (adding "?") than having to do extra work reading code. Exceptions are functionally invisible control flow; it isn't clear to the reader that a function may blow up if the exceptions are unhandled.

Exceptions always work the same way. You learn how to read code with exceptions pretty quickly.

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

#103

Earlier quoted context omitted.

Go belongs in the exact same bucket as Java and C#.

C# sure, but unless you are doing something pretty close to the core purpose of some giant java framework java is slow and verbose

Java, Go and C# (and node) have very similar performance, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For all of them, the key to writing high performance code is avoiding allocations and boxing. Go and C# both do this slightly better than Java, but in most domains where these languages are used, this is not a big difference (and this is where you might use C/C++/Rust instead). I've found Go to be more verbose than Java, but I haven't used Go much since generics were released.

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

#104
post #44

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…

Error handling in Rust is actually a lot worse than you think. In fact it may be the single worst aspect of the language. Fundamentally it is difficult to impossible to fix bugs without knowing what code caused it. Java-style exceptions give you a backtrace for free, which is a huge head start. With Rust you have to do a lot of manual plumbing with something like error_stack to get similar functionality, out-of-the-b…

Ugh that’s one of the worst parts of go too. Stackless errors are so useless and hard to debug.

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

#105

I worked with a shop that wanted to use Rust for their shiny new MVP. And they did... and yes we were not really good at training nor could prioritize/attract rust-experienced devs. The Lead rust dev left due to personal reasons and then we were left with a codebase nobody really had the knowledge/insights to support while rapidly iterating. We smiled and rewrote it in node.js. I think devs get burned when the MVP tu…

I can't fathom why a company would write code in a language that most of its developers aren't at least somewhat experienced in.

If you're writing a program in Rust, hire Rust devs or invest heavily in educating the devs you do have first.

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

#107

If you are writing high performance code use Rust. (Slow development times, high performance) If you are writing a typical business application use Python. (Fast development times, low performance) Or if you want to be clever do a hybrid of both. Create Rust modules for your Python code. This is just about selecting the right tool for the right job.

I picked Crystal so I didn't have to choose.

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

#108
Since safety was the first reason given for using rust, I'll just point out:

There are other safe languages.

I think it's a really useful thing to have from day one, but it doesn't particularly point you to rust.

Also, performance is really about learning what your bottle-necks are, profiling them and optimizing them. You probably have no idea what those are when you start, so it's not really the right time to try to solve it. (There's a decent chance, e.g., that your inner loops won't even be in code you write, like the database.) Probably the best thing you can do for long-term performance up-front is to try to stay flexible, and try to keep your architecture simple.

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

#110

Earlier quoted context omitted.

Assume all functions can throw and there is no extra work reading. A function that has no possibility of error is so uninteresting in the context of error handling. Furthermore, handling errors has little to do with where the error is actually caused. In general, you can only do two things with errors: log and kill the operation or retry the operation. Neither of these has anything to do with the leaf function 20 ite…

"Assume all things can throw" is what I've seen people do in Java code that adds a million try catch wrappers around everything just in case something may go wrong at some point. The end result is either completely unreadable or impossible to figure out. "How do I return fallback data for FooBarService.wiggle()" often ends up in digging through (incomplete, outdated) documentation or with code that breaks unexpectedl…

> There are very few ways good ways to handle those problems correctly, which is why this "everything may kill your program" approach is often criticised.

In Erlang, "everything may kill your program" is typical method of operation, and there should always be some kind of path to reset your state from known good values.

Post reply on HN