[ilovecaching]

Which is why I also said that we need to evolve our thinking towards replaceable systems. As systems grow, the pace of innovation slows as it becomes cumbersome to make changes, and the barrier to entry into the code base rises. With that in mind, we are well served to replace programming languages as a means of maintaining constant velocity in our development.

I don't claim that existing systems are easy to replace, but I do posit that they can be made replaceable given that certain practices are adopted, and the mindset of the developers is that they system should be easy to remove and replace.

[shaklee3]

What languages in particular are you suggesting we move towards? Rust is getting there, but it's still evolving rapidly with features. That's about it. Any HN-favorite, such as Go, is not a valid replacement.

[ilovecaching]

I'm personally behind Rust and Go, but I don't want that conflated with the point I'm trying to make about facilitating code replace-ability. We shouldn't move towards any language in particular, but instead facilitate interoperability of languages, focus on building services instead of libraries, and size services such that they can be easily replaced. A business doesn't need to use a different language per developer, but they should expect to phase out languages periodically, and accept more rewrites and make more consideration about the right tool for the job when greenfielding that jumping to some mandated language like Java.

I also wouldn't say that Go is invalid, Go is more than production ready; it's actually in production in critical infrastructure today at scale.

[shaklee3]

Go is not valid because of performance reasons, mostly. I work in embedded, and besides the client apps, c/c++ dominate in the performance space. I think it can, and has replaced c++ in other areas, but it still has a long way to go. The C interoperability was extremely limited last I used it, and that's a big way to get people to move.