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

121–130 of 496 posts

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

#121

Post by jb1991 »

eunoia wrote: post #33
jb1991 wrote: post #12

Earlier quoted context omitted.

In Swift, at least, the possibility that a function can throw must be marked as part of its signature, and the exception cannot be ignored if it is thrown so the call requires explicit syntax as well, so there is no way to miss that something could "blow up" when reading the code.

It's a little old at this point, but I find the Swift Error Handling Rationale design doc to be absolutely fascinating. It cites other language’s error handling paradigms (including Rust) if you're curious: https://apple-swift.readthedocs.io/en/latest/ErrorHandlingRa...

Fascinating, looking forward to reading this later today! Have used a handful of languages over the years, and I don’t have any academic perspective in different error handling techniques, but there’s no doubt that the way swift does it feels particularly natural, safe, but still gets out of your way. I love all the options for handling errors in a meaningful way.

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

#122

Post by gpderetta »

pclmulqdq wrote: post #18
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…

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.

1. Exceptions as commonly implemented in C++ have high overhead in the exception path. But that's just an implementation strategy. There is no reason why it wouldn't be possible to generate exactly the same code as for an optional type if desired (and in fact it was proposed for c++ cf. Herbceptions).

2. So do returns, but we have long settled that SESE is undesirable.

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

#123

Post by aisrael »

jeromenerf wrote: post #45
aisrael wrote: post #26

Earlier quoted context omitted.

Author here - yeah, that's how I feel about it, at least for startups specifically.

... then however, how do you feel about tech debt with Rust? My feeling was that go, rust and such left a lighter burden on the future than say ruby. Do you think you will need a major rewrite soon?

To me, the language agnostic answer to reducing tech debt is having a good test suite so refactoring is easier. We're pretty good on that front.

We have definitely done large refactors before, and I'm sure we'll have more in the future, but I don't think we need a major rewrite or anything like that.

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

#124

Post by johnny22 »

maleldil wrote: post #118
galangalalgol wrote: post #88

Earlier quoted context omitted.

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

It's amazing how the "Java is slow" myth survives to this day.

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.

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

#125

Post by maleldil »

dgb23 wrote: post #87
unshavedyak wrote: post #29

So.. i'm going to disagree, Rust (or any language!) is fine for prototyping. The trick is don't experiment when you're needing to rush a product out. Pick what you and your team is most comfortable in. Avoiding allocations in Rust, on purpose, and being uncomfortable with how to solve design challenges caused by hyper optimizing your code .. is not a Rust problem. Or an any language problem. Rust gave you rope and yo…

> Use Arc, Rc, Clone, etc. It won't hurt, it won't be terribly slow, and it almost assuredly won't be slower than your prototype languages. I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.

> It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.

What are you comparing it to? I believe parent meant that even if you clone everywhere, your code is still more likely to be faster than Node/Python, and potentially Go/C#/Java.

One thing to note is that C++ code tends to allocate all over the place from copy assignment and constructors, and it's still very fast. Rust only forces you to be explicit when cloning, but memcpy is still a fast operation, unless you're cloning large structs.

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

#126

Post by maleldil »

johnny22 wrote: post #124
maleldil wrote: post #118

Earlier quoted context omitted.

It's amazing how the "Java is slow" myth survives to this day.

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.

That doesn't matter if you're writing a REST api. If you're writing a CLI app, then I agree that's a problem.

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

#127

Post by estebank »

throw14082020 wrote: post #94
richardwhiuk wrote: post #72

Earlier quoted context omitted.

Not sure I agree with Go vs Rust. I think if you would choose Java or Python or C#, then Rust might not be the right choice.

Go is in a sweet spot where it is often used to compete with both groups: [Rust, C/C++] and [Node, Python, Ruby, etc]. The reason GP said it is probably because of Garbage collection. I've done a bit of Rust in my job, and there are some basic things that Rust doesn't have going for it: - steep learning curve (this means for the first 6 months, you or your colleagues are unproductive, write bad Rust which your compan…

> - bad error messages (even though that was a focus for the rust team!)

I would love to hear more! (If you have the time.)

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

#128

Post by galangalalgol »

johnny22 wrote: post #124
maleldil wrote: post #118

Earlier quoted context omitted.

It's amazing how the "Java is slow" myth survives to this day.

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.

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

#129

Post by steveklabnik »

distcs wrote: post #52
mrichman wrote: post #41

Earlier quoted context omitted.

What if your startup is in the embedded systems space, for example? I don't think you'd be doing your MVP in Python.

Why impose the "embedded systems" space requirement on the OP? The OP does not work in embedded systems space. So it is not relevant to this article. The OP is telling us what they would do, not what you should do and definitely not what embedded systems startups should do.

(Not your parent but how I read it.)

It's not imposing a space requirement. It's a reminder that these generalizations have limitations. The OP isn't in the embedded space, but they do say "a startup" not "a web startup." There are embedded startups.

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

#130

Post by adamc »

PaulHoule wrote: post #63
Jensson wrote: post #14

Earlier quoted context omitted.

In Java functions declares Exceptions in its type signature, so it does all of that automatically. Then you get a compile error if you don't handle it in the function, or you need to declare the function throws it, so it is type safe. Note that people now consider that as a mistake, people prefer having Exceptions be hidden instead of explicit and requiring handling like that.

We are in the distributed systems age. If systems are composable, operations can fail for reasons that are completely unfathomable to the client. It's not reasonable to have a SharkBitTheOpticFiberCableException and 100,000 other ones that handle every reason why an operation failed. What the client should know is how an error affects what it is doing, it wants answers to questions like * Is it likely this error will…

While I think this is a good point, a lot of the answers cannot be determined by the generator of the exception. Your SQL library cannot know what the implications of an error are -- is this a minor part of the system for which the error can be logged but mostly ignored, or is it critical? Etc.

People want error handling to vanish so that they can follow the "normal" flow, but in fact error handling is one of the critical things code does.

Post reply on HN