Hi, article author, here. Down in one of your other replies, you state:
> The context for that question is important: OP had a set of requirements and Rust seemed to meet them.
The context as I presented it is perhaps unfairly narrow, and I've glossed over some of the non-technical requirements that constrain my choices. Time-to-market and funding levels are hyper critical - these are hard limits that have less riding on me-as-IC being the sole determinant of a positive outcome, and more on being able to hire the first team members should I meet my funding goals in 2023. Here in the EU, hiring rust devs is ultra-competitive, expensive, and open positions tend to sit unfilled for longer periods of time. There is a mercenary like attitude among experienced crypto developers that makes it difficult to recruit for projects. A developer who is good with rust and knows crypto well doesn't need you for a job - they're probably already looking for funding or considering a co-founder position with a biz person that's already snared a wealthy benefactor for advisory and seed funding. This makes building a founding team (vs a team of co-founders) very difficult in the space.
On the flip side, I can teach a good JVM / golang / python / NodeJS developer how to iterate in nim a lot faster than bringing them up to speed as a proficient rust developer.
My top considerations were among "productive" compiled languages: go, crystal, swift, even investigating mruby. These languages have considerably less cognitive surface-area in banging out pedestrian and proprietary IP code in a 7:1 ratio (not scientific, obvs). First, you need to quickly produce MVP and v1.0 products. Secondly, the follow-on to that is being able to support fast iteration to launch and prune features. This latter aspect is much more important than the zero-to-MVP phase, since the clock isn't really running until you're actively marketing a project and it's gaining (or losing) users. Rust is just not a good choice for the entire code base. It is, however, a great-to-good choice for low-level dependencies. Given it's flexibility, I think Nim can be both. We'll see.
There are two documents that haunt my thoughts over the course of decades being in tech startups. One of them is Paul Graham's "Beating the Averages". The other is Akin's Laws of Spacecraft Design.
One of Paul's reasons for using Lisp at Viaweb was, paraphrasing here for brevity, that choosing the defaults of your competitors is going to yield an average result, which will put you out of business. In my industry vertical, I do think that Golang is more that default than is rust. The evidence seems to point toward Go based teams being better at burning through VC (tongue firmly in cheek ;-) ), and that Rust is superior at embedding working technology whose code-paths touch every customer, every day.
My sincere hope is that Nim hits the sweet spot in the middle while eeking out some of the competitive advantages that Graham talks about. As the idiom goes, you takes your money, and you makes your bets.
> The context for that question is important: OP had a set of requirements and Rust seemed to meet them.
The context as I presented it is perhaps unfairly narrow, and I've glossed over some of the non-technical requirements that constrain my choices. Time-to-market and funding levels are hyper critical - these are hard limits that have less riding on me-as-IC being the sole determinant of a positive outcome, and more on being able to hire the first team members should I meet my funding goals in 2023. Here in the EU, hiring rust devs is ultra-competitive, expensive, and open positions tend to sit unfilled for longer periods of time. There is a mercenary like attitude among experienced crypto developers that makes it difficult to recruit for projects. A developer who is good with rust and knows crypto well doesn't need you for a job - they're probably already looking for funding or considering a co-founder position with a biz person that's already snared a wealthy benefactor for advisory and seed funding. This makes building a founding team (vs a team of co-founders) very difficult in the space.
On the flip side, I can teach a good JVM / golang / python / NodeJS developer how to iterate in nim a lot faster than bringing them up to speed as a proficient rust developer.
My top considerations were among "productive" compiled languages: go, crystal, swift, even investigating mruby. These languages have considerably less cognitive surface-area in banging out pedestrian and proprietary IP code in a 7:1 ratio (not scientific, obvs). First, you need to quickly produce MVP and v1.0 products. Secondly, the follow-on to that is being able to support fast iteration to launch and prune features. This latter aspect is much more important than the zero-to-MVP phase, since the clock isn't really running until you're actively marketing a project and it's gaining (or losing) users. Rust is just not a good choice for the entire code base. It is, however, a great-to-good choice for low-level dependencies. Given it's flexibility, I think Nim can be both. We'll see.
There are two documents that haunt my thoughts over the course of decades being in tech startups. One of them is Paul Graham's "Beating the Averages". The other is Akin's Laws of Spacecraft Design.
One of Paul's reasons for using Lisp at Viaweb was, paraphrasing here for brevity, that choosing the defaults of your competitors is going to yield an average result, which will put you out of business. In my industry vertical, I do think that Golang is more that default than is rust. The evidence seems to point toward Go based teams being better at burning through VC (tongue firmly in cheek ;-) ), and that Rust is superior at embedding working technology whose code-paths touch every customer, every day.
My sincere hope is that Nim hits the sweet spot in the middle while eeking out some of the competitive advantages that Graham talks about. As the idiom goes, you takes your money, and you makes your bets.
http://www.paulgraham.com/avg.html
As for Akin, the full list has some doozies but the one that really sticks out to me in the context of startups is this:
40. (McBryan's Law) You can't make it better until you make it work.
https://spacecraft.ssl.umd.edu/akins_laws.html
cheers