Fast forward to today… Rust can interop with C natively. Go can as well, though you’re bringing your luggage with you with CGO. .Net hasn’t ever really had that kind of focus. For one, IL, two, Microsoft saw the platform as a cash cow, three, ecosystem lock in allowed a thriving “MVP” contractor community.
[1] https://github.com/microsoft/CsWin32
[2] https://lowleveldesign.org/2023/11/23/generating-c-bindings-...
P/Invoke was born as J/Direct on J++, it became P/Invoke after the lawsuit, and Cool project turned into C#.
Managed C++ Extensions in .NET 1.0 got replaced by C++/CLI on .NET 2.0, it was a .NET Core 3.1 milestone to support it, and has recently been updated up to C++20, minus modules.
Still heavily used among .NET community on Windows.
Meanwhile the native C++/CX and C++/WinRT, both failed their adoption efforts.
For C-based libraries, P/invoking is trivial in C# and has been around forever. And it's cross-platform, working identically on Linux and macOS. I have no idea how you can say ".Net hasn’t ever really had that kind of focus" when it's been a core part of .NET from the start, and .NET relies on P/Invoke to do everything. Go look at all the DllImport() statements in the .NET reference source. Rust FFI is nearly identical in implementation to C#. Go has a slightly different implementation with the CGO module, but whatever, it's close enough. Just step back and remember that, in general, calling into C code is trivial in every language, since it has to be: all these languages will eventually have to hit libc / user32.dll / whatever.
C++ is a totally different story. You can't work with C++ libraries with P/Invoke, that's true... But you also can't work with C++ libraries using Rust or Go, either. Nor Python, Java, Javascript, or really any other popular cross-platform language.
C++ dynamic libraries are really challenging to call into for a variety of reasons. Virtual functions, multiple inheritance, RTTI, name-mangling, struct/class layout, vtable placement, ABI differences, runtimes, etc all make calling into precompiled C++ libraries a nightmare.
In fact, the only way I know of working with pre-compiled C++ libraries is with languages that target specific operating system / compiler collections. E.g., Objective-C++/Swift from Apple, and C++/CLI from Microsoft. These are obviously not cross-platform solutions, since they depend on knowing the exact compiler configuration used to build those libraries in the first place.
For every other language, you either need to manually build C shim libs that you can call into using the C-based approach above, or if you have access to the C++ source code, creating wrappers around it and building it into a module (for example, using pybind11 in Python).
My perspective is from a first adopter, not an insider, 24 years ago, so I can’t speak to motive but as a customer, it felt exactly as I described. The documentation around P/Invoke was lax, you were shoved “Managed C++” down your throat by your rep, and any dream of going cross platform died in that meeting room until Miguel De Icaza did something about it.
Also during .NET 1.0 days, Microsoft had a Website where you could paste any well known Win32 API or related SDK, and it would spit the annotations.
What was never as good in .NET as it was in VB 6 and still is in Delphi and C++ Builder to this day, was creating and consuming COM, which is kind of annonying given how much Windows team loves it.
At least it isn't as bad as the multiple reboots in C++, which I will keep asserting that from all of those, MFC still has the best tooling to handle COM.
In the Office land, Excel’s Power Query is .NET Framework 4.
Adopting the modern .NET is probably harder due to its lifecycle.
Want to extend the context menu actions, or add new thumbnail capabilities for a recent file format?
It is exactly that.
Even with WinRT Runtime Components, they were doing in a way that some APIs were only surfaced when using the components from C++.
Quite a different approach from OS / language teams at Apple and Google, where productivity with better languages has a priority no matter what.
Yeah, Microsoft themselves have issue moving away from .NET Framework.
You can add SQL Server CLR, Dynamics, Sharepoint on prem, to the list.
Microsoft is an insanely huge company. There teams seem to be able to use whatever works best for the project/team.
The old XKCD comic of org charts in big tech shows Microsoft as a bunch of people aiming guns at each other for a reason. They'll have 5 teams making 5 competing products sometimes. That's the culture I'm aware of. I'm not aware of the dogfooding culture you are suggesting.
So the gain isn't as much as what is being sold.
Meanwhile Azure has no issues using AI based translation to port C++ projects into Rust, which they could have done in a similar way to port into C#.
Also, Go has a less capable tooling as C# for WebAssembly, due to Blazor efforts, the team has invested quite a lot into it.
It remains questionable what will they do for the in browser playgrounds and editors use cases.
It's seriously going to make people question the future of the platform. Look at Microsoft's actions, not their words.
TS Compiler: Go New TUI Editor: Rust Winget: C++ (this would have been a great candidate for .NET)
At least PowerToys is C#.
.NET is great, but why isn't it good enough for Microsoft? The company that historically has had such a strong culture of dogfooding.