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

301–310 of 496 posts

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

#301

Post by nawgz »

mcronce wrote: post #185
dirheist wrote: post #152

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 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 somewhere between less significant and nonexistent.

Can you expand on what you mean here? I know you're not implying Rust is faster to move thru a CICD pipeline, so can you tell me what you do mean? I seem to be unable to make a different reading

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

#302

Post by tijsvd »

tegiddrone wrote: post #25

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…

Never combine new tech with new functionality. If you want to learn new tech, use it to rewrite an old project that was due anyway. If you want to build new functionality, use tech that you know.

This has nothing to do with Rust. I've seen the exact same thing happening with golang in a C++ only environment. Long project, took forever, failed slowly, took a week to rewrite in C++.

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

#303

Post by mike_hearn »

pclmulqdq wrote: post #290
mike_hearn wrote: post #277

Earlier quoted context omitted.

The cost is higher because of all the branches that are scattered everywhere to check return codes. With exceptions there's a check at the place the error is thrown, but that's inevitable. There aren't checks scattered throughout the rest of the code, which would otherwise reduce icache utilization.

Arguing about icache utilization is a little silly here - the code will be laid out for you as though the branches are not taken (or you should force it to do so). In that case, the only "waste" of icache is the CMP and JMP, an additional 4-8 bytes per return, and literally 0 cycles. When you do take an error, each RET takes you 1 cycle, plus the 10-15 cycle mispredict for the CMP+JMP because there's a stack engine i…

The checks you're talking about are duplicated more or less per statement in some types of code. Every single call site ends up with an `if err != nil` or moral equivalent. It can add up, also consider the extra register pressure. The return values aren't valuable anymore, they're just error signalling.

The compiler doesn't necessarily know what your error types are, it can try to use heuristics to move those blocks around but it's not like an exception where the types are a part of the language and the compiler can know that. We're talking about startup code here, nobody will be annotating their error branches with manual predictor probabilities, so we're limited to what the compiler can do.

Yes the act of throwing an exception is more work but it's exceptional, so doesn't matter. The slowest part is calculating the stack trace anyway and that's of huge value, which you don't get with error codes anyway.

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

#304

Post by tcfhgj »

dom96 wrote: post #13

I have the same impression of Rust: great for software that is well scoped/defined and needs to be stable and efficient, not so much for quick iterations (which for startups is important) and software that doesn't need top performance. I think in general that the Rust hype has outgrown what it's good for. If you're writing a web app in Rust then you may want to ask yourself if you're making the right choice.

> If you're writing a web app in Rust then you may want to ask yourself if you're making the right choice.

ok, I did ask myself this, still going with Rust there ;-)

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

#305

Post by innocentoldguy »

japhib wrote: post #267

For pattern matching and expressiveness in a backend language that lets you iterate quickly, I'd highly recommend Elixir.

I would reach for Elixir, Phoenix, and LiveView for any new web development. We were using Java before and were running into major productivity issues. After extensive testing with Elixir, Node, Clojure, Go, and a handful of other languages, Elixir won out, we rewrote our entire stack, and our productivity skyrocketed. I can’t say enough good about it.

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

#306

Post by fweimer »

dilippkumar wrote: post #282
Ylmaz wrote: post #143

I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly const…

In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second. Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation. I'm pretty sure that maintaining a C++ codebase is less…

Except … for spewing out fortune responses, most of your cost by far will be in bandwidth charges. Those won't change with the implementation language. If anything, the C++ version will just be able to burn your dollars faster.

(Yes, I know, it's just a silly example, but compute costs are only one aspect, and the bandwidth pricing in the on-brand public cloud actually tilts overall costs towards being bandwidth-dominated for many applications.)

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

#307

Post by mike_hearn »

tptacek wrote: post #262
mike_hearn wrote: post #244

Earlier quoted context omitted.

For server binaries they're typically being dropped into Docker containers not scp-d to servers directly, and the moment you go there you can just use jib and get a JVM container easily so there's no difference in logistics. For CLI tools whilst a single binary can be convenient, native-image lets you get those for JVM programs too these days. But it's not always the case that it's enough. In practice you will often…

I want to be careful not to recapitulate every conversation I've ever had with a JVM person about this. I'm not claiming it's impossible to deploy JVM applications; obviously, tons of people do. I'm just saying people use Go and Rust because they work well in situations where you want to distribute and directly run a simple binary without additional tooling. That's not every situation; obviously, if you can use Docke…

Sure. Given the choice of one file or 50, one file is clearly better all other things being equal.

My feelings on this changed over time. About 10-15 years ago I thought single executable output was a critical feature for a language, because everywhere I went I saw people saying how important it was for them, how much simpler it made deployment. I figured, OK, people know what they want so that's what they should get.

Then Docker came along. Docker images aren't single files, they're the polar opposite. They aren't even things you directly manipulate using the filesystem at all. Yet people loved it and it took over the world. Clearly what all those people demanding single-file executables were actually wanting in 95% of cases was simpler deployment, and they were phrasing it as single executable because that was concrete and understandable whereas simpler deployment is a very vague concept so who knows what you'd get if you asked for it.

For people who are selecting Go or Rust or Graal native images primarily because of single-file output, I'd actually really appreciate a chance to ask a few questions or interview them quickly to learn more about the deployment context. Conveyor is all about deployment and it's good to understand more about how people are doing things and what could be better.

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

#308

Post by ipaddr »

legerdemain wrote: post #257
ye-olde-sysrq wrote: post #200

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…

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…

Your comments tells me you are in the group who doesn't know better. Data is passed in json which is a format other languages can read and send back. If that's your reason for using it you do have other choices.

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

#309

Post by tomp »

xcdzvyn wrote: post #285
tomp wrote: post #240

Earlier quoted context omitted.

Rust already has exceptions, they just call them panic and offer exceedingly poor language support for them. Some people simply live in denial, believing untruths that confirm their worldview. This is the same situation as with Go and generics. The maintainers were in denial for a very long time, before finally admitting what was obvious to some of us long before [1] [1] https://news.ycombinator.com/item?id=8626978

The implementation, outcome, use-case, and characteristics of panics are all very different from exceptions. The only marked similarity between the two is that they both interrupt program execution (and in different ways). But I feel as if you already knew that.

Panics support stack traces, unwind the stack, releases the memory, and can either be recovered in some situations, or prints an error message. Sounds like Python exceptions.

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

#310

Post by EVa5I7bHFq9mnYK »

dhbradshaw wrote: post #89

We have a fairly complex app with a front end in Typescript and a back end in Rust backed by Postgres on AWS. My favorite part of the job is coding in Rust and we do a lot of cool things in that backend code. Unfortunately, most often the Rust code is the fastest and easiest part of a change, which means that I spend most of my time solving problems either on the front end with Typescript or on CI and infra type thin…

Backend code is simpler because is has two limited well defined surfaces (API for the frontend on one side and database on the other side). Frontend is harder because it has to interface with those impolite hairy meat creatures ...
Post reply on HN