4 ms·

.NET came with massive additional resource consumption, with its very own comprehensive system API and with an entirely different resource management paradigm.

.NET came with massive additional resource consumption, with its very own comprehensive system API and with an entirely different resource management paradigm. Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Also, C++/CLI is not the language in which most people want to write .NET software, nor is it C++. It introduces an entirely new pointer syntax just to deal with resources that don't work with RAII. Its very existence proves that there is a huge gap to bridge. You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. That's why we have all those isolated library ecosystems for Java, JavaScript, .NET, etc. Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. But they decided to ape Java and balkanize their OS APIs. Now they are busy undoing the catastrophic damage they did to Win32. It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more.

pjmlp 10y ago
> Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Yet that was exactly what I was doing in 2001. Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C, which was the backbone of all distributed software developed by employer at the time. All the remaining layers were written in VB.NET and C#, using those components. > You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications. > Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects. Since Windows XP, the majority of the new APIs are COM based not Win32. Also UWP is just the COM+ Runtime brought back to life, but using .NET metadata instead of COM type libraries. > . It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more. I can provide similar examples for Oracle, IBM, Apple and Google if you wish.
- fauigerzigerk 10y ago
  >Yet that was exactly what I was doing in 2001. Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C [...] Exposing a low level C library to a .NET application isn't adding .NET to an average C++ application just because you prefer to write some new feature in C#. But that's exactly what Apple wants you to be able to do with Swift. >Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications. Like no one would ever do anything that isn't smooth or efficient. >They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects. Right. I think you know exactly how communicating strategic intent works. COM was relegated to legacy tech in 2000. They "embraced" it only to stay backwards compatible. They only rediscovered COM as a strategic piece of the puzzle rather recently after realizing what a huge mistake they had made back then. >I can provide similar examples for Oracle, IBM, Apple and Google if you wish. I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups?
  - pjmlp 10y ago
    > I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups? Yes, when many in HN and similar online forums pretend it is like that. Not directly addressed to you, just that it is a common theme.

pjmlp 10y ago

> Adding it to an average C++ program back in 2000 would have been utter madness and I don't think it was ever what Microsoft intended as the standard use case for .NET. Yet that was exactly what I was doing in 2001. Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C, which was the backbone of all distributed software developed by employer at the time. All the remaining layers were written in VB.NET and C#, using those components. > You simply cannot smoothly and efficiently use a library written in a language that comes with a tracing GC from another language/runtime. Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications. > Microsoft already had exactly the right technology to build on back in 2000. COM was a simple idea that would have stood the test of time as the basis for multiple language runtimes that can share a library ecosystem efficiently. They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects. Since Windows XP, the majority of the new APIs are COM based not Win32. Also UWP is just the COM+ Runtime brought back to life, but using .NET metadata instead of COM type libraries. > . It's a huge mess, nothing ever sticks, nothing is ever coherent enough to be blievable, trust in their APIs has been eroded so much it hardly exists at all any more. I can provide similar examples for Oracle, IBM, Apple and Google if you wish.

fauigerzigerk 10y ago
>Yet that was exactly what I was doing in 2001. Using C++/CLI predecessor, Managed C++, to create .NET components that exposed a RPC library written in C [...] Exposing a low level C library to a .NET application isn't adding .NET to an average C++ application just because you prefer to write some new feature in C#. But that's exactly what Apple wants you to be able to do with Swift. >Yes you can, otherwise I and many other Windows devs wouldn't be using C++/CLI and C++/CX on our applications. Like no one would ever do anything that isn't smooth or efficient. >They never thrown it away, .NET embraced COM, allowing its consumption and exposing .NET classes as COM objects. Right. I think you know exactly how communicating strategic intent works. COM was relegated to legacy tech in 2000. They "embraced" it only to stay backwards compatible. They only rediscovered COM as a strategic piece of the puzzle rather recently after realizing what a huge mistake they had made back then. >I can provide similar examples for Oracle, IBM, Apple and Google if you wish. I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups?
- pjmlp 10y ago
  > I know you could, as could I. But to what end? Do we really need proof that Microsoft isn't the only company that is capable of major strategic fuck-ups? Yes, when many in HN and similar online forums pretend it is like that. Not directly addressed to you, just that it is a common theme.