Using Rust at a startup: A cautionary tale

In many larger projects, there is a need for efficiency and/or low-level work in _some_ corners, _and_ there is also a need for productivity, rapid development in _other_ parts. And everywhere do we want maintainable and readable code that is easy to understand.

Selecting more than one language sometimes works, in my experience you can have various microservices that talk to each other, then it doesn't matter what language each is implemented in.

However, it isn't optimal to have to master more than one language (most good people do, but we also want to cater to weaker team members; in football, not everyone is a Ronaldo, Pele or Messi either). I don't see why C++ or Rust shouldn't have opt-in garbage collection offered for parts of the codebase where this makes sense (where productivity is worth more than runtime speed), which is probably most part of most projects if we are honest.

As some of you know Rust actually _had_ GC in an earlier version, and some readers may complain saying "but C++ can do GC if you want" (of course you can add a Boehm-style GC in your project). But what I'm referring to is that there should be a "batteries included" GC-enabled part of systems programming languages by default (as a technical and cultural preferred setting), unless you mark up a library/crate/class as performance-relevant. This could be done with a mechanism similar to marking up "unsafe", e.g. "uncritical" (= runtime matters less in this section compared to productivity). Then strings and other objects could be garbage-collected and programmers could focus on solving the actual problem instead of managing memory. Critical sections could be marked as such, and there'd be the much-coveted "zero overhead" abstractions for these. The advantage is you would not need to stay up to date in two languages, and you could avoid FFI-type integration, which tends to be brittle (JNI? shudder!).

An entirely separate point is the availability of programmers that master a language. I totally agree with the poster that you should use a mainstream language to avoid being hit by a talent shortage.

Are we already there in the hype curve?

The classic silver-bullet story, same old, same old.

I haven't written Elixir in years, but Elixir with Phoenix was a quite similar experience to writing a CRUD app in RoR.

Frees cognitive resources because you can usually forget that menory management is a thing. When on GC.

Startups spend innovation tokens very poorly.

Progamming languages, hosting platforms and non-standard databases aren't ideal places to spend such tokens.

For most apps what you want is JVM or .NET, PostgreSQL or MySQL or SQL Server, k8s or vanilla VMs/containers.

You almost never want different programming languages to these mature stacks, you might think you do, but you don't. Node.js/Python/Ruby etc all promise a fast start but in reality any perceptible velocity benefit is dead within months, usually before anything of value is shipped. Most of it has to with ecosystems (library quality etc, framework maturity) but those also being the 2 most advanced managed runtimes helps a ton.

For databases just standard RDBMS is almost always the way to go, unless you startup is intrinsically a data startup and you know ahead of time you require very special properties you just want one of these.

Keep hosting simple. Don't use any fangdangled "serverless" nonsense. It's not worth it, shipping a week or 2 later because you took the time to setup EKS/GKE/AKS will pay off in spades. k8s reputation for complexity isn't warranted and it's essentially standard now and will remain that way.

So now you have freed up your innovation tokens you can spend them on solutions to your actual business problems instead of on stuff that will only continue to eat your token budget and often yield negative real returns.