Live data from Hacker News

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

propelauth.com

151–160 of 496 posts

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

#151
post #130

Earlier quoted context omitted.

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

This is sort of what HTTP codes get at though.

The server doesn't know what you want to do with a 400 but it knows that the problem is with the request for example.

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

#152
post #113
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…

NodeJS kind of muddies the waters. It ate a lot of use cases that would have previously been done in Java. That created conflict between backend teams that wanted statically typed code and a "boring" tech choice against "full stack" developers creating a backend service. I think Rust will see a lot of adoption in web services that are glorified CRUD APIs. It would have been a poor choice to do many of these workloads…

Wouldn't you just use go/python/node for a simple crud API? fastapi for python is pretty performative if you use gunicorn as your runtime and time to iterate is must faster than it is in rust.

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

#153
post #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.

That's in the C / C++ / Rust bucket due to the typing system.

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

#154

How much more performance do you need to get from Rust over Python (even Cython, PyPy, Numba, etc) to justify the extra development cost? A 2x gain is certainly not worth it. A 10x gain? Maybe. But that is hard to achieve when much of your "compute" is spent on the DB side of things. How many startups actually scale out of needing a few non-db instances?

Rust easily gets 10x improvement in performance over Python in a lot of applications. This is absolutely my experience. A better statement is that it doesn’t get 10x improvement over Go, or other ergonomic compiled languages.

Also in the context of cloud spend: way way way less RAM, which can translate directly to dollars.

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

#155

Earlier quoted context omitted.

> and hiring skilled Rust devs is just crazy hard (though maybe now that Blockchain/Solidity things have cooled there may be more supply). Sidenote, we hire Rust at a small shop (~30 devs?). Ironically i've found it _easier_ to hire for Rust. You're totally not wrong, BUT, the quality of the candidates that apply is quite high in our experience. I suspect it's because we get a lot of passionate people. We don't have…

> With that said we don't aim for super senior devs. We're happy to hire a junior, etc. I care much more about the quality of the person than raw experience. Being young and cheap is a good quality, I suppose. Experience is overrated.

Well, hiring only super experienced people in a niche talent pool feels arbitrarily difficult. Young devs can be just as good, and we all need to build experience somehow.

One rule of thumb for me is that the more young a developer we hire is, proportionally we also need to hire an equally senior. Ie we don't want a huge amount of developers lacking experience.

However if you have enough senior developers to mentor the young ones? Seems a net win for all involved, to me at least.

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

#157

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.

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.

Sometimes matters, e.g. when you deploy new code.

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

#158
Rust is weird. It has high level features that make is superior to high level languages like go and python. But the low level features like default move semantics inevitably make it harder.

IMO there is merit in making a language that is equivalent to garbage collected rust by default with ownership rules similar to python. Then the classic rust based ownership and allocation schemes are all opt-in syntax-wise in the same way Box is opt-in.

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

#159

Earlier quoted context omitted.

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.

Kind of yes, and kind of no. On the happy path, if errors are very very rare, the check is also basically free thanks to branch prediction. They start to cost something when you start to add a higher frequency of errors, which incidentally is where exceptions cost a lot more.

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

#160
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?

As long as you know what you are doing Ruby won't leave you with more technical debt than Go or Rust.

How many people know how to effectively program in languages like Ruby is another question altogether...

Post reply on HN