Why Rust is a great choice for startups

2 is fine. the more significant question is often do you want to work with that talent pool and does the pool tell you more about the costs structure of your sector against which information you may prefer to tack against the prevailing winds and even more patiently attempt to trade actual equity for deep abilities and stuff what language is chosen if your stock has value.

I don't understand how much attention individual languages receive. Plural understanding across your team and ability to transcribe the code into valid parseable docs against which APIs are easily written, is paramount in my mind. Corollary to my incredulity I have often thought that you emphasize the codebase language and dialects only to find you fuelled holy wars and dissipated your technical mission values. Which is disastrous for hiring the kind of colleagues we get up in the morning and forget about industry grief to share increasingly awful spaces with.

The biggest upside is that the stricter compiler does catch bugs. It makes changing existing code easier and it makes it easier to add invariants across the code via the type system. It makes an extensive test suite much less necessary, generally unit tests for pure parts of the code and some form of simple dev/staging environment will suffice. This can defer the need for expensive and slow integration tests running on every change.

Performance is also nice but it doesn't matter much. My service is running with 10m cores and 50MiB of memory, 10x those wouldn't be a major concern. I think that in 99% of cases performance only really matters when you are trying to optimize running costs and that is generally only the case when the operational costs matter relative to the cost of an employee. The performance of your application is very rarely related to the performance of your application code, usually it lies more in the database and network calls that you perform while serving requests. I think for many startups the cost of actually running your code tends to be tiny compared to staff and other infrastructure. The docker image is 160 MiB (with debug symbols) which is probably smaller than most Java/Python projects but not tiny anyways.

There are definitely cases where Rust is more verbose than Python (over Java I actually find Rust more productive) but even if you can write very high-level code with Rust part of the problem is that it doesn't necessarily encourage you to do so. With things like explicit `.clone()` calls and reference counting you are very aware of every time you make a performance tradeoff. It takes the right attitude and personality to say "that's fine" for most of these cases and leave the optimization to when it matters. (When you do want to optimize it is very clear where all of these expensive operations are which is nice.) But something like Python where these slow operations are completely hidden is definitely nice for focusing on the business logic.

Overall I think it is legitimately a close call. I definitely spent more time worrying about unimportant details with Rust but I likely would have shipped more bugs and had a harder time making wider changes. I would also be much less confident with the stability of the current code which is very important to me as this is running as basically a side-project without a 24/7 oncall. Also the more cross-cutting features I add the happier I am with the type checking.

I think Python (with a type checker) or TypeScript would have been slightly more productive but I think the investment of Rust was worth it. The fact that I can see the path forward with no rewrites or the need to break off expensive components into microservices in higher performing languages is a really nice outlook.

For hiring, what you should look for, first and foremost, is competence. Curiosity is not a substitute.

This is the most interesting part for me. Not the specific numbers, but the general notion of "performance actually matters". There's impact on ROI, UX, complexity and sometimes it lets you do things that you wouldn't otherwise consider.

There was a post fairly recently on here, where they showed a deployment architecture of a small business or startup. It was a simple thing, with a couple of app servers, databases and load balancers. Something like that. The app servers were written in Python/Django I think. The essence was that "this is a simple architecture on relatively cheap VPS instances with minimal complexity and it handles a ton of traffic", I think the bill was a couple hundred or a month maybe 1/2k max. I liked it.

But even then I thought that there has to be some overhead that can be cut there. If your app server plus database performs well _enough_ you can run them on just one instance, you can cut several load balancers. All you need is a backup machine if you care about downtime, especially during deployments. That would roughly cost you maybe 5x less. Then you might actually be able to cut down the performance of the machine, another factor of 2. Now your bills are 10x less, you have fewer things to worry about, possibly less complex tools needed.

So let's say a single developer can save them 1k (EUR/$) monthly, that would be 5-10h work hours gross, or just say a day of billable work, every month that they get out of it. And this is not considering the gains from reducing the complexity and setting themselves up for finer grained improvements and other benefits that were not possible before.

I'm not considering the downsides and the estimates are shaky at best. But there might be something to this, even for fairly small teams and companies.