"I'm not quite sure how this is different from classes."
Well, depending on your definition of classes, I suppose. "A struct bundled together with methods for operating on it + some sort of polymorphism" on its own doesn't say anything about dependency management. But get 10 programmers together and ask for a definition of "class" and you can easily get 15 answers.
"Visual Studio build out reports on call and data flow so you can easily see what calls what and what dependencies you have."
Does it really have a report of exactly what APIs you use out of a module? I'd love to see an example of that if it's not too difficult, not because I disbelieve you, but because I'd love to see it. I know I've seen plenty of flow diagrams for what "libraries" or "modules" you use (whatever word is appropriate to your language), but knowing that you use "the AWS S3 module" is much less informative than knowing "you only use GetObject", to be specific about an example.
"C# has this feature and calls it "Microsoft Fakes" but they got a lot of vocal pushback from the TDD community who see great value in adding dependency injection and an interface to every library call you make."
I am not intimately familiar with this feature, so please do correct me if I am wrong. But I observe that according to this page: https://docs.microsoft.com/en-us/visualstudio/test/isolating... that for stubs you have to manually create an interface, and for shims you're in a situation where the code is being rewritten dynamically. I would propose making it so that all library usage is automatically an interface type created by your usage. And as it would be implemented in the language spec, rather than being done by instruction-rewrite very late in the process, it would also be something that could be built on by other things.
To be clear A: I'm well aware that I, just like everybody else, do not have any totally unique and new ideas literally never considered by anyone ever, so I am well aware that there are things like this in various bits and pieces elsewhere and B: I'm not exactly "criticizing" the .NET stack, especially with my vaporware-beyond-vaporware ideas. I'm just observing that there is an engineering difference between the things that run as instruction-level rewrites very late in the process and things integrated at the beginning. That's one of the ways Microsoft and Oracle/Java punch above the "weight" of what I'd otherwise expect from the languages in question merely on their features, and a legitimate advantage of being on their stacks, but even for something the size of Microsoft, that's where you have to stop advancing. You can't really build on that sort of tech because you can't stack that many such features together before the complexity exceeds what even those entities can deal with.
(There's also some other features in my highly vaporous vaporware language that this integrates with in some other ways, which is why I'm concerned about needing to be able to build on these features more officially than last-minute assembly rewrites.)
Well, depending on your definition of classes, I suppose. "A struct bundled together with methods for operating on it + some sort of polymorphism" on its own doesn't say anything about dependency management. But get 10 programmers together and ask for a definition of "class" and you can easily get 15 answers.
"Visual Studio build out reports on call and data flow so you can easily see what calls what and what dependencies you have."
Does it really have a report of exactly what APIs you use out of a module? I'd love to see an example of that if it's not too difficult, not because I disbelieve you, but because I'd love to see it. I know I've seen plenty of flow diagrams for what "libraries" or "modules" you use (whatever word is appropriate to your language), but knowing that you use "the AWS S3 module" is much less informative than knowing "you only use GetObject", to be specific about an example.
"C# has this feature and calls it "Microsoft Fakes" but they got a lot of vocal pushback from the TDD community who see great value in adding dependency injection and an interface to every library call you make."
I am not intimately familiar with this feature, so please do correct me if I am wrong. But I observe that according to this page: https://docs.microsoft.com/en-us/visualstudio/test/isolating... that for stubs you have to manually create an interface, and for shims you're in a situation where the code is being rewritten dynamically. I would propose making it so that all library usage is automatically an interface type created by your usage. And as it would be implemented in the language spec, rather than being done by instruction-rewrite very late in the process, it would also be something that could be built on by other things.
To be clear A: I'm well aware that I, just like everybody else, do not have any totally unique and new ideas literally never considered by anyone ever, so I am well aware that there are things like this in various bits and pieces elsewhere and B: I'm not exactly "criticizing" the .NET stack, especially with my vaporware-beyond-vaporware ideas. I'm just observing that there is an engineering difference between the things that run as instruction-level rewrites very late in the process and things integrated at the beginning. That's one of the ways Microsoft and Oracle/Java punch above the "weight" of what I'd otherwise expect from the languages in question merely on their features, and a legitimate advantage of being on their stacks, but even for something the size of Microsoft, that's where you have to stop advancing. You can't really build on that sort of tech because you can't stack that many such features together before the complexity exceeds what even those entities can deal with.
(There's also some other features in my highly vaporous vaporware language that this integrates with in some other ways, which is why I'm concerned about needing to be able to build on these features more officially than last-minute assembly rewrites.)