> Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety?

Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc.

> By the by, I like Rust, I just think it's not well-suited for most applications.

I'm going to push back on this too. In terms of "all programs that anyone has ever written", scripting languages are overwhelmingly the most suitable choice. But in terms of usage, core infrastructure favors reliability, performance, and interoperability with other languages. Consider regex libraries, language runtimes, graphics libraries, codecs, text/internationalization support, windowing systems, UI libraries, browsers, and so forth. This is our core infrastructure, where performance and reliability are paramount, and these libraries have outsized importance.

> this isn't incompatible with my claim, that Go is at least as safe as C, and thus safety alone doesn't preclude Go from safety critical applications.

This assumes that C is OK for safety critical applications. It's not. The status quo is bad. The bar should be much higher.

> Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc

Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's.

> I'm going to push back on this too ... our core infrastructure ... libraries have outsized importance.

Granted, but that's not "pushing back" on my point, because important though those libraries may be, they still don't constitute a majority of applications.

> This assumes that C is OK for safety critical applications. It's not. The status quo is bad. The bar should be much higher.

Agreed. Rust is better than Go for safety critical applications--note that I never tried to argue the opposite--only that Go is better than the status quo, terrible though it may be.

> Package management and easier error handling are the only ones that doesn't roll up into safety or performance, and I dispute that Rust's error handling is easier than Go's.

Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance (although they are incidentally used to implement some speed/safety features, because why not). Inline assembly and FFI are useful for platform interop: again, these are not safety features.

> Granted, but that's not "pushing back" on my point, because important though those libraries may be, they still don't constitute a majority of applications.

I suspect the numbers are like: 95% of applications are best in scripting languages. 4% are best in managed languages (Java, C#, Go, etc.). 1% are best in low-level languages like Rust. If you want me to concede that point, fine. But in terms of importance of projects, which correlates with the number of developers you need on the project, the numbers look very different.

> Generics, pattern matching, functional features, modules, easy FFI, are productivity features! They have nothing to do with safety and performance

I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance.

> I suspect the numbers are like: 95% of applications are best in scripting languages. 4% are best in managed languages (Java, C#, Go, etc.). 1% are best in low-level languages like Rust. If you want me to concede that point, fine.

I disagree. I think that Go beats scripting languages at their own game, in most cases. Of course this is all opinion and mine is no more valid than yours.

> But in terms of importance of projects, which correlates with the number of developers you need on the project, the numbers look very different.

Perhaps, but I'm not sure what your point is here, or how it relates to the broader topic. Are you arguing that more developers are needed on the project and thus more developers in total work on these core libraries than all other software projects?

> I dispute that these features improve productivity. With the exception of modules (whose purpose has always eluded me) all are available in Go (or could be trivially implemented) at the expense of safety and/or performance.

OK. How do you implement array.map() in Golang?

Probably like this: https://gist.github.com/ParthDesai/5e0f1d4725a644f1e632

Wow. That seems very complicated for an implementation of map().

It seems like this is a perfect example of how generics are a productivity feature.

It's complicated because the reflect library is very general. There's no need to repeat most of this. So in fact, it's a perfect example of how functions are a productivity feature.

I would argue it's both.