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

I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess over memory management, and the libraries for web backend stuff are the same things Google uses internally, so they're well-tested.

A big problem with Rust, long-term, is that the kind of programs that really need it are somewhat out of today's mainstream. It's not that useful for webcrap. It's not that useful for phone apps. The AI people use Jupyter notebooks and Python to drive code on GPUs.

Where do you really need Rust? Heavy-duty multi-threaded programming. Operating systems. Compilers. Routers and network infrastructure. Robotics, maybe. Hard real time. It ought to be used more for high-performance games, but the game infrastructure isn't there yet. Unreal Engine is C++ and Unity is C#. Rust has Bevy and Rend3, but they're not AAA title ready.

Perhaps Rust is fighting the last war - the mess inside C++.

One strength of C++ is that it is far more established than rust - and that comes with a lot of advantages:

* It has a larger number of people who know how to work with it

* It has a huge catalog of established, fully functional libraries for everything you could imagine from UI to game development to embedded systems to simulation to anything else

* It has broad support in developer toolsets in general like editors and IDEs, static analysis tools, formatters, pre-commit hooks, etc

If I'm starting a new project with C++, I can immediately know that there's a huge landscape of programming already carved up and ready to work with. I can't do that as easily in Rust. The language, the libraries, the tools are all younger. Some of it isn't as fully featured, some of it isn't nearly as stable.

That will improve with time, but it's a huge advantage to C++ right now.

One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness.

I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe all it needs is time.

I’m currently rewriting what I wrote in Rust to see how the prototypes compare and… I just feel so much at peace knowing that the type system and the borrow checker have my back and that I won’t encounter unexpected nil pointers or zero values. And I write this quickly as well.

(Yes, I do have experience with both languages, so none of these exercises were new to me. But I’ve been favoring Rust over the last couple of years.)

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 in this in C or C++ (despite the data point of Amazon 1.0 LOLz).

But if Rust exists, suddenly you have a nicer-to-use high performance language, and you have a choice to use it.

https://news.ycombinator.com/item?id=33845045

I think if you would choose Java or Python or C#, then Rust might not be the right choice.

"What kind of startup would fail because it chose Rust ?"

Then don't be.

Seeing Rust as a system programming language only is missing the bigger picture (IMO).

For context: most if not all of our team has developed calibration tooling similar to what we're doing now in the past, just at different startups and very specific to certain robotic or sensing configurations.

If anything, once we got CI sorted and started using our own internal registry I would argue that we are significantly faster in terms of iteration time. This is partly because the team is small, but also because most of our tooling is consistent and easy to keep in lockstep. Pulling libraries is done uniformly across platforms and architectures, and our CI runs (through GitLab) stay up-to-date with the latest tooling without issue. Having a stronger type system to detect errors early and a compiler that actually tries to give human-readable messages (looking at you C++ linker errors) using that type system makes everything so much easier.

Compile time seems like it would be an obvious bit that slows one down, but in practice sccache [1] does what it ought to and we barely notice it (at least, I don't and I haven't seen team members complaining about build times). Mostly I'd argue that the real thing holding us back is tooling extant to the rest of the wider Rust ecosystem. Debugging and perf tools are great in Unix land, but if you're making anything cross-platform you need to know more than just perf. That might just be my opinion though, I'll admit I'm still learning how best to apply BPF-based tooling even in Linux alone.

I also realize I'm responding to steveklabnik, so I suspect most of what I'm saying is well-known and that this comment is really more directed at TFA.

[0] https://tangramvision.com

[1] https://github.com/mozilla/sccache

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

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 than 7.7 times more expensive than Node, even if you throw in extra development time etc. This also ignores the decades worth of excellent tooling we've built up for C++ (static analyzers, fuzzers, etc).

At a startup, when building things fast matters more than costs, sure. I buy the argument for Node or Python or any other interpreted backend. But once you start to scale, things change after some threshold. Unless you're facebook[1].

[0]. https://www.techempower.com/benchmarks/#section=data-r21

[1]. https://developers.facebook.com/blog/post/2010/02/02/hiphop-...

One time, I met a guy who wrote firmware for Seagate hard drives. Any new feature he added had a budget measured in microseconds. Obviously he wrote nothing but C++.

The problem is that TypeScript is an even better language for early prototypes.

zeroxfe has the right answer:

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

The only reason one would choose Rust over TypeScript is if one would have chosen C/C++ instead.

Then if you need higher perf/throughput: Go, Java, and C# in particular are all options that I'd consider before C/C++ or Rust. C# in particular is highly congruous to TypeScript [0].

JavaScript, TypeScript, and C# have been converging, IMO (and that's a good thing). Seems really natural that if you're a startup finding PMF, start with TypeScript for iteration speed. If you need higher throughput, C# is a stone's throw away from TypeScript syntactically and it's pretty easy to hire for (compared to Rust). [1]

Pick Rust if you're building something highly performance and memory sensitive. Pick TypeScript and C#/Go/Java for almost all other cases.

[0] https://github.com/CharlieDigital/js-ts-csharp

[1] https://raw.githubusercontent.com/CharlieDigital/js-ts-cshar...

Please don't report your own experience samples as plain universal facts. It is one of the more common means by which falsehoods spread. I have no doubt that's not your intention, and you believe what you write, but you cannot have a basis for such a bald statement, and it happens to be false.

I have seen prototypes built and discarded very frequently. Indeed in an earlier incarnation it was my own professional focus.

I have no idea how common it is in your country, or globally, or in specific industrial sectors. Usable stats in tech are hard to come by (in large part because of its ubiquity). But your statement is just false, and commonly repeated.

You can’t be serious. I’ve seen prototypes get thrown away all the time, especially at startups. In fact, I’d say that’s more common than not.

It takes too long to do these basic steps and then copy them to new projects. And generators only work once, if then, which means they are most useful in languages that have stopped iterating, which is not that compelling.

I’m hoping the next version control system solves the rerere problem and we can build our projects by forking a template project, then pull commits from upstream as necessary.

Result and ? force you to think about - or at least acknowledge - the edge cases. For a throwaway script or small scale easily tested program, that might be a drawback. For MLOC+ codebases where link times alone are sufficient to start impeding testing iteration times, it can be a big help for correctness and stability, while still being relatively lightweight compared to other manual error handling.

Finally - Rust has exceptions. They're called panics. They can be configured to abort instead of unwind. This helps set the tone - they're really meant for bugs, and exceptionally exceptional circumstances. They cause all the problems of exceptions, too - unconsidered edge cases, undefined behavior unwinding past C ABIs, the works. Fortunately, it's reasonable in Rust to aim to eliminate all panics but bugs.

Fundamentally it is difficult to impossible to fix bugs without knowing what code caused it. Java-style exceptions give you a backtrace for free, which is a huge head start. With Rust you have to do a lot of manual plumbing with something like error_stack to get similar functionality, out-of-the-box Errs do NOT capture this.

Far more productive to work in an environment that does the right thing "for free" vs having to do it manually.

    fn foo () -> Result<(), E1> { .. }
    fn bar () -> Result<(), E2> {
        foo()?;
    }

`Result` implements some common combinators like `.ok()` to convert to `Option`, `map`, `map_err`, `or_else`, etc to reflect the common cases of error handling.

And finally, since Result doesn't require non-local control flow like exceptions you know that `drop` will run as the functions return back up the callstack.

And if you want to use Result like exceptions... you can. But you can't hide it from callers, and callers are still free to handle them elegantly.

What ? does in rust is to unwrap the result check if it is err and return from the function with an error result. On top of that it will auto-convert the error type (if the type has the from/into traits implemented)

So it would do:

try { //the code that may fail } catch (error) { //do we just throw the same error? //or convert the exception to a custom other exception }

If I see an API that throws me an low level exception without context I go mad. Like an file not found exception etc when executing an API that does multiple file IO operations.

Error union return values make a lot more sense, the rest is just syntax sugar details (and that's where opinions differ I guess).

Personally, I much prefer Rusts solution, being both more up front and at the same time more terse.

The metaphor is kinda stupid though, the "cavemen" in our scenario knows very well that exceptions exist.

Oh, it absolutely can not be that the Rust way is more powerful and you didn't understand it yet. No way. It's all those other people that don't understand the old concept that almost all of them know.

Even types of exceptions are rarely useful results outside of reading the logs or sometimes in libraries outside of your control.

I think there's a pretty good rule of thumb in modern systems-ish language design: If Go and Rust and Zig all do a certain thing, that thing is probably a great idea. These languages have very different priorities, but often they overlap.

This made me laugh harder than makes sense. I'm sure I've been guilty of doing said code, as well.

The only thing is that Rust rightfully uses the ? to return early system on option as well, which removed the ability to have None coalescing with "?". This was the right choice from a language point of view, but I wish there would be a None coalescing syntax in Rust.

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.

Read up on how exceptions work in C++ implementation-wise. It's not pretty.

Exceptions? Which exceptions? How do you know which exceptions you're supposed to be handling and where they come from or when they happen?

I prefer the control flow of the program and the exact types of errors I'm handling to be explicit.

I had almost this exact scenario, and yes there is pain in writing it with explicit lifetimes. But I can't agree the performance improvement is negligible; maybe in isolation, but I saw about a 100x speed increase for my application when I switched away from Strings. For me it was because I was doing many of those extra String allocations in a loop, so it killed my performance.

The performance difference between a Rust server and other languages are incredible, especially in terms of RAM usage and concurrent connections per second.

That said, if your program is going to need tons of entities stored in a database, I wouldn't even consider a language or framework without a solid ORM. Rust has some ORM-lite libraries but I'd end up picking a garbage collected language in practice just because of the difficulties that low level programming bring to such middleware.

Iterating in Rust isn't that hard as long as you don't try to cheat your way out. Instead of returning null for methods that you haven't implemented, add a todo!, etcetera. You have to do things somewhat right the first time. I think that's good, because there's nothing as permanent as a temporary proof of concept. You can clone/copy your way out of most annoying Rust restrictions at the cost of performance you'd otherwise sacrifice by picking a higher level language anyway.

If your startup doesn't know what it's building, you have bigger problems than the language you choose.

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

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++.

If you're writing a program in Rust, hire Rust devs or invest heavily in educating the devs you do have first.

I very much doubt that. It's likely true for straight up wasteful languages but very unlikely for more optimized runtimes.

If you are writing high performance code where a tracing GC isn't an option, and there are SDKs available use Rust.

Otherwise an AOT compiled language is a better option, and if not, and there are only C and C++ SDKs available, also factor in the development cost of creating wrappers in Rust, before doing the actual development activities.

If there is too much money being burned in wrapper libraries, maybe that isn't the best option as well.

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 to weed out as many candidates.

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.

With that said traditional hiring avenues have not been fruitful for us. Word of mouth, Rust community job posting, etc have been most fruitful by far. Probably due to exactly what you said.

(We were specifically looking for remote folks near EU time zones, maybe local in SF is harder?)

Depending what you do but it’s usually the case that performance won’t matter until mid late game. I saw a startup at +300M valuation still not having to worry about performance for a long time. And a cut in the AWS bill thanks to using a more performant language like Rust won’t make that much a difference compare to how much they had to pay devs. So you just want a language where you can ship features fast.

Also the hiring pool is still very small.

A better statement is that it doesn’t get 10x improvement over Go, or other ergonomic compiled languages.

We average ~80 "instances" to maintain this level of performance. I have very little doubt that, if given the opportunity to rewrite this in rust, we could smash 10x perf improvements. Could we also get more perf out of tuning our python code better? Definitely. Do I think there's 10-20x improvement waiting to be uncovered? No.

Unfortunately (fortunately?) we're at a stage that it makes more sense to throw ludicrous sums of money at it than it does to ground up rewrite.

Conversely if you are looking to hire Java folks, you'll have an enormous pool to pick from, or if you need to train somebody in eg Go - you can do that significantly quicker than you could with Rust.

Compared to what? Java, C# and Go?

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

That is how AOLServer used to be, and all the other scripting languages developed as Apache plugins, back in the 2000's .com wave, like mod_perl and PHP.

Not everything is a CRUD mobile app trying to be the next tinder for cats.

Haskell. I know it best and know at least 10 people I could hire that also know it.

I can be as safe or as unsafe as needed where it's needed and get good performance without thinking about it most of the time.

Unfortunately, the cloud isn't a very good environment for mixed-languages deployments (unless you stick to the most basic services), so you have to make a decision on the very beginning and stay with it.