Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

propelauth.com

Post reply on HN
Print view View original

411–420 of 496 posts

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

#411

Post by za3faran »

Animats wrote: post #351
hot_gril wrote: post #337

Earlier quoted context omitted.

> If you're building web backends, Rust is not a good choice This heuristic wouldn't work for my department because we build web backends in C++. I keep telling the most senior devs here that nobody does this and for good reasons (velocity etc), and their response is "who cares what the rest of the world does, they're just bad at C++."

Google developed Go specifically so they didn't have to use C++ in high-volume web backends, which is what they did previously.

A few people at Google did, as far as I'm aware it didn't start as some officially sanctioned project at the company. golang has its own sets of challenges due to the limitations of the language and its error prone bare bones threading model.

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

#412

Post by caleblloyd »

saurik wrote: post #388
dilippkumar wrote: post #387

Earlier quoted context omitted.

> but mostly for networking and then second to that storage, with the cost for actual computation usually being a pretty small percentage of my overall spend. What portion of the bandwidth is end-user facing and what portion of it is connecting all the servers? Another way of asking this is if I need fewer servers because code runs faster, how much less bandwidth do I need?

AWS doesn't charge for internal server-to-server transfers, so the answer is precisely 0.

That's only true for transfer in the same availability zone.

https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer_...

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

#413

Post by za3faran »

galangalalgol wrote: post #128
johnny22 wrote: post #124

Earlier quoted context omitted.

i just read "java is slow" as "java is slow to startup" and that helps. Java is slow(er) to to startup, but once it's going, it's pretty good.

I meant slow to develop in.

With features like records, pattern matching, enums, and many more, I find it much better than the likes of Python or golang.

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

#414

Post by FridgeSeal »

lenkite wrote: post #211
Conscat wrote: post #115

Earlier quoted context omitted.

Exceptions make it difficult to find failure-points in the code. The ? annotates that at its call site, which improves discoverability by a lot and reduces readability by only a little.

> Exceptions make it difficult to find failure-points in the code My experience doing Java, Go and Rust has been completely the opposite. Exception stack traces in Java are amazingly wonderful things - they exactly pin-point the failure points in the code. The amount of hunting I need to do to find out where something failed in the call stack in Go/Rust is tedious. You need a module/crate for error tracing or you up…

> Java are amazingly wonderful things - they exactly pin-point the failure points in the code.

Yes.

Once the exception has happened. At runtime. Which is not when I want to be trying to fix things. I’d much rather handle as much as possible statically, knowing that what I push into has every non-panic code path cleanly handled.

I’ve never had the equivalent experience with exceptions, it’s always “well I’ve wrapped everything I possibly can in as much try-catch and handling as I possibly can, and oh look, some random piece of code has still thrown some random exception we’ve never seen before”.

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

#415

Post by andrewstuart »

steveklabnik wrote: post #65

Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how yo…

With all due respect, you’re Steve Klabnik.

That makes “Rust at a startup” a different equation.

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

#416

Post by jmull »

ReflectedImage wrote: post #178
jmull wrote: post #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…

Rust does a bit more on the safety front than typical programming languages.

There’s Javascript/Typescript.

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

#417

Post by za3faran »

tptacek wrote: post #132
ntonozzi wrote: post #82

Earlier quoted context omitted.

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

Ergonomically, yes. Logistically, no.

I wouldn't even say ergonomically. Java and C# are so far ahead it's not even funny.

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

#418

Post by steveklabnik »

andrewstuart wrote: post #415
steveklabnik wrote: post #65

Oxide is a startup and we use Rust for everything except the front end of websites (where we use TypeScript.) In some cases that’s due to hard requirements (embedded) but we use it for web backend cases as well. Iteration time hasn’t been an issue, but compile times can be annoying. Though obviously compile time is related to iteration time. Of course, all of these things are anecdotal. Collecting anecdotes is how yo…

With all due respect, you’re Steve Klabnik. That makes “Rust at a startup” a different equation.

I am one of roughly 50. I'm pretty sure the rest of them are not Steve Klabnik.

I also just work there, the all-Rust bit started well before I joined!

That said, you are right that it's a point worth considering.

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

#419

Post by za3faran »

Larrikin wrote: post #30
PaulHoule wrote: post #2

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…

Despite what CS and SE classes try to drill into you, null results or failure cases are nearly always better handled right when they happen instead of passing them up with layers of exception handling. Log it, pass null up, and just immediately handle it. Fail early and none of the rest of the function matters. Even types of exceptions are rarely useful results outside of reading the logs or sometimes in libraries ou…

How do you handle a DB connection time out in your stack? You can log it and retry, eventually the entire call must be terminated though, and the quickest way is through exception propagation.

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

#420

Post by za3faran »

FridgeSeal wrote: post #414
lenkite wrote: post #211

Earlier quoted context omitted.

> Exceptions make it difficult to find failure-points in the code My experience doing Java, Go and Rust has been completely the opposite. Exception stack traces in Java are amazingly wonderful things - they exactly pin-point the failure points in the code. The amount of hunting I need to do to find out where something failed in the call stack in Go/Rust is tedious. You need a module/crate for error tracing or you up…

> Java are amazingly wonderful things - they exactly pin-point the failure points in the code. Yes. Once the exception has happened. At runtime. Which is not when I want to be trying to fix things. I’d much rather handle as much as possible statically, knowing that what I push into has every non-panic code path cleanly handled. I’ve never had the equivalent experience with exceptions, it’s always “well I’ve wrapped e…

You still need a top level exception handler in your main loop.
Post reply on HN