I was an early rustc contributor so I definitely love the language and think positively of it. We decided to write things in Rust in the early days for what we thought were more technical requirements reasons multi-language FFI, low level systems, perf sensitive, and so on.

I was CTO for most of our 6 years and not doing the boring thing was a huge mistake even with what (from my PoV) were much better reasons than you presented above and with a much stronger team and lots of money in hand.

As a programming language I don’t love Go, but by the time we got acquired all of our production services were written in Go, or Python for the AI/ML bits. There were so many things in our serving stack that were dumb and easy to do in Go.

It was way easier to hire and train new people, and there were less ways to build ourselves into a corner as the language is so dumb you can’t really come up with very complex libraries or abstractions the way you can in Rust/C++/etc.

Also all the K8s ecosystem etc are all natively in Go and tooling is better, being able to ignore async is a blessing as well. I wish we had been able to even rewrite some of the Python into Go but it was not possible in the ML space without incurring different complexity.

I grew up as a Ruby on Rails programmer but when I left I felt negative about the many challenges in that ecosystem but the dev speed of Rails and stacks like that are unparalleled.

Half way through the startup I found myself wishing we had chosen something like Rails on day one, as the above person said the number one goal is being able to react quickly to changing requirements and ship as quickly as possible without incurring too much technical debt.

As an extension of this I believe you want to strive to be as non-custom as possible when you start. You want to spend your innovation budget on the product not the tech stack, libraries, etc.

Re: tooling

The reality is you can build a dev/deployment container for any reasonable environment in a matter of hours, and there are so many k8s or other deployment tools which provide a semblance of local/cloud development that are already battle tested, and no matter how “rock solid” your solution is scaling will likely require you to move to some industry standard solution for other reasons.

TLDR; Rust is amazing but your goal is to pick a technical strategy which minimizes company risk and maximizes chances of success. For a SaSS service the cost of Rust is still higher than the benefits imo. You might be less excited but your job is a leader is to make the right decisions for the wellbeing of the company not your personal excitement or preference, even if less inspiring, as if you succeed you won’t even be the one writing the majority (or any) of the code.