I think the argument presented for Rust over Go is extremely weak, and I say this as someone who is not interested in Go and likes Rust.
If the main value proposition of Rust is bug fixes, error handling and nice-to-have (?) platform support it sounds like you're really scraping the bottom of the barrel. Unless there is an extremely obvious and large benefit to using Rust over Go I would not do it.
I have not written any Go, but Rust seems to have a far steeper learning curve and there would also likely be high organizational costs associated with transitioning from Go to Rust (E.g. coordinating the transition, ramp up time, hiring, etc).
When Go is working fine and you only have 40 engineers this sounds like a massive distraction from building the product. I wonder if the author considered the possible negative impact of this as well as the positive.
The benefits of using Rust come as a consequence of a team that learns and chooses Rust on its own. It is likely a more committed team, which would produced better code in any language.
Migrating a team of PHP, Javascript and Go programmers to Rust for no technical reason seems just hopeless.
I think its Paul Graham that made the argument to have a "weird" language as your startup language for this reason. Sure there are a billion C#, Java or Javascript developers out there. But if you make your start up in obscure lang you'll get a lot of high minded hard working engineers that will go there and build something awesome because its interesting.
I found many of PG's essays insightful and inspiring, but I think this particular idea is rather questionable. I want to hire people that are interested in solving the problem. Are these really the same people obsessing about programming languages?
Does obsessing about programming languages really correlate with being an obsessive problem solver in general? I'm not so sure about that. My observation is that people can be deeply interested in one thing while being completely indifferent towards other things. Obsessing about everything is a mental illness.
Maybe it depends on the problem space. If the technology part of the problem is simple and the main issue is how to increase productivity then PG's argument makes sense. But if you have a difficult problem to solve that isn't developer productivity, then I think it doesn't make sense to hire people motivated by the choice of programming language.
> I think its Paul Graham that made the argument to have a "weird" language as your startup language for this reason.
I think you do that by using the “weird” language starting from team size of one, not by convincing 40 people to re-write 500k lines of already working code base.
The flip side is that your business now depends on those few high skilled engineers. Much harder to replace. I would probably go for a main stream programming language / platform: Java / JavaScript / Go / Ruby / Python
I suspect this largely depends on where you're coming from. If you are comfortable with C++ and Haskell, Rust probably doesn't feel that hard to learn. But coming from JavaScript or PHP, I can indeed imagine a steep learning curve.
I think Rust has a lot more complexity relative to other languages (Borrow checker and lifetimes especially).
I didn't find it particularly hard to pick up the basics, but compared to say Python or Ruby there is a lot more upfront complexity to do things.
If you're coming from C/C++ it's probably easier to pick up, but in terms of relative difficulty across all languages I definitely think it's up there.
If the main value proposition of Rust is bug fixes, error handling and nice-to-have (?) platform support it sounds like you're really scraping the bottom of the barrel. Unless there is an extremely obvious and large benefit to using Rust over Go I would not do it.
I have not written any Go, but Rust seems to have a far steeper learning curve and there would also likely be high organizational costs associated with transitioning from Go to Rust (E.g. coordinating the transition, ramp up time, hiring, etc).
When Go is working fine and you only have 40 engineers this sounds like a massive distraction from building the product. I wonder if the author considered the possible negative impact of this as well as the positive.