> 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.
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 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?