3 ms·

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to be bolted on separately, and at large scale they will cost your company $$$ vs. a more performance-friendly language (the latter doesn’t matter so much if you are a tiny startup with no users yet). At that point with all the financial resources, they can consider to rewrite/migrate. Thus, at the start, chose boring technology. Even at a big company, retraining or hiring people proficient in Rust will probably cost more than continuing to use C++ codebase and people.

hgomersall 3y ago
Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.
- kyawzazaw 3y ago
  > Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns. > but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Isn't this premise aligned with the philosophy written in the article? 1. You needed to learn something new (so no longer boring, and prime for innovation token) 2. You needed to use something different for a systems language context (innovation token time)

hgomersall 3y ago

Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Rust held far more appeal and in hindsight has helped us provided fantastic stability in our software whilst developing very rapidly.

kyawzazaw 3y ago
> Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns. > but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case. Isn't this premise aligned with the philosophy written in the article? 1. You needed to learn something new (so no longer boring, and prime for innovation token) 2. You needed to use something different for a systems language context (innovation token time)