Live data from Hacker News

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

propelauth.com

321–330 of 496 posts

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

#321

Earlier quoted context omitted.

Having examples of these is useful to see what we could get rustc to do. The general case might be impossible to deal with in a generic way, but we can target specific patterns libraries use and emit custom errors for them. The problem with these is we have to be reactive: if we don't see a problematic patter ourselves (or it isn't reported to us), we can't do anything about them.

Unfortunately last I tried these code snippets was months ago, was rushing like mad because it was a startup and I couldn't afford to just stop and write everything down and... yeah, priceless info was lost. Just recently I am making a comeback to rewriting a tokio 0.1 library to the latest version so I'll likely have a few examples that I can post... where? In GitHub issues?

GitHub works great for it, for diagnostic tickets in particular you can file them at https://github.com/rust-lang/rust/issues/new?assignees=&labe...

Even if it is an "it hurts when I do this" without more context it can be useful to bring the problem to our attention (but the more context you provide the higher the change we'll fix the problem).

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

#322

I find it mystifying that one of the reasons you can supposedly pass over Rust, and avoid performance concerns, is to "take the free money." Literally. That is, the free money, in credits, that allows you to not worry about performance for a while. The obvious problem being... "What happens when the free money runs out?" It's not addressed, but the implied answer seems to be "Well, by then it'll be six months later,…

At that point startup has revenue so can pay or is dead so it doesn't matter.

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

#323
post #248
post #182

I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and…

The author touches on why it matters in the article - either you have to restrict hiring to folks who are already rust experts (much smaller hiring pool, also usually meaning higher comp expectations) - or you have to consider the cost of training new/existing staff on Rust. Rust has a notoriously difficult learning curve, especially to folks who don't have a background in C/C++. As the author mentions, you may be lo…

I was putting that argument aside because that's an argument you can make for any language and it changes depending on who you know, what circles you're in, etc. It's and externality not specific to Rust. You can say the same for Erlang, or Swift, or C#, or ...insert language that isn't JavaScript.

What I'm saying is that, disregarding the externalities, I've found Rust to be quite a boon and not inherently a bad fit for an early stage. YMMV.

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

#324
post #182

I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and…

Well Python code will on average will be more correct than Rust code. I'm not sure why you feel Rust code would be more correct than Python code but it certainly isn't true.

Curious: have you written Rust in a serious capacity before?

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

#325

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…

I'm also at a startup using rust. It's true that the feedback loop can sometimes feel bit slower. One thing that helps here is being test driven so that you're not waiting for compiles just so you can click through to confirm a small change in behavior. But in general I think my velocity is not much slower than it was at a previous company using a node backend. The hardest part of software isn't typing in the code and making sure it runs. It's thinking about what it should do and how it should do it in the first place. And really, Rust's type system is a force multiplier. We can prototype really fast, throw out things and rework them with confidence because with well thought out typing and tests to confirm logical behavior we have strong safety guarantees. It lets you experiment and investigate alternative implementations fearlessly.

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

#326

Earlier quoted context omitted.

I've really tried to give js/ts in backend a go. Both by nodejs and deno. And by kickstarting my own projects as well as diving into experienced nodejs developers' code. I really don't see how anyone choses nodejs/deno to anything. Java imo gives you much less trouble, is more stable, has a working (!!!) Unit testing setup and exceptional runtime. Next on my list is to give rust a go, since I'm intrigued by its featu…

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

That’s an interesting comment. I chose Node not because I love it, but it’s the easiest to hire for as a startup.

I hate configuring typescript and having to deal with bundlers, package.json, esbuild, etc.

But Deno and Bun are just around the corner. What we need is to get rid of this a la carte mentality around tooling and just give everyone Typescript, batteries included, and make it fast.

Then Node really isn’t that bad anymore.

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

#327

Earlier quoted context omitted.

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.

It depends exactly how simple that CRUD API is. If there's any business logic, I'd rather get all the cheap correctness guarantees that Rust provides. I don't find myself making many truly dumb CRUD APIs. Time to iterate is also only much faster in certain situations, e.g. local development; if you have to e.g. build a container image, push to a registry, and redeploy to a k8s cluster somewhere, those savings become…

“Time to iterate” is measuring how quickly you can get an idea, build it in code, deploy it to your customer, and get feedback.

If Rust is helping you make prototypes and iterate quickly, I’d love to hear how you’re using the language.

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

#328

Earlier quoted context omitted.

"I really don't see how anyone choses nodejs/deno to anything." This is going to sound mean but I don't really know how to phrase it more nicely. People building backends in js/ts are doing so because either they, or a critical mass of the people they expect to code in it, don't know any better backend languages. I don't mean for this to be judge-y. People have different skillsets. A nodejs backend can be the right c…

While it doesn't have the batteries, typescript's gradual typing is much nicer than python's, so for some use cases it's a better language. All languages come with tradeoffs in terms of performance, development/maintenance cost and ease of hiring. Most businesses only care superficially about performance, which leaves developer productivity and ease of hiring. Node/typescript isn't terrible in terms of developer prod…

> typescript's gradual typing is much nicer than python's,

It is not Node V. Python, but Node V Java

Python is a terrible choice as a backend, too.

It has a place as a scripting language, but so often it is used to build complete systems. They suck.

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

#329

Earlier quoted context omitted.

This comment is presumptuous, dismissive, and also wrong. People who write application-like front ends in React (etc.) want back ends that can interoperate with those front ends. They accomplish things like built-time code generation, static server-side rendering, and other kinds of code transformation that are difficult and flaky without a back end that can understand JS. I have looked for non-tinkertoy solutions in…

> want back ends that can interoperate with those front ends. You can ingest and emit JSON in any language. You can even compile backend-friendly code to run in JS on the frontend, via emscripten (and increasingly, Wasm), which will output very lean and JIT-friendly code. The usual "isomorphic" case for backend.js is no less 'presumptuous' or 'dismissive' than the comment you're pointing to and criticizing here.

>>increasingly, wasm

If you are referring to something similar to Blazor (client side), yeah no imo it's pretty awful for anything other than internal enterprise apps. I couldn't imagine running a public facing product on that.

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

#330
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.

Really? I guess if your typical programming languages are C and C++.

Otherwise Rust just has semantics that allow more control over memory, as is often needed in lower level programs, while preventing pointer aliasing. The majority of languages in existence are memory safe--some even more so than Rust. They're just not as flexible.

Post reply on HN