7 ms·

> .NET nowadays has a serious adoption problem It's seriously going to make people question the future of the platform. Look at Microsoft's actions, not their

> .NET nowadays has a serious adoption problem 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.

reactordev 1y ago
The issue was in the beginning they didn’t think interop with C/C++ was value add. People complained and they added “Managed C++” which unfortunately influenced C++03’s design a lot. It wasn’t until C++11 that Microsoft gave up. You couldn’t effectively interop with C++ without writing a managed C++ wrapper, which only worked on windows. They added support for P/Invoke to aid in Win32 calls (shell.dll, user32.dll) as a simple fix and we went nuts for it. Wrote wrappers using P/Invoke and a config map nightmare of which dll’s, or dylib’s, or so’s, you needed to get the form to show. 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.
- lowleveldesign 1y ago
  Interestingly, the Rust windows crate is generated from an MSIL assembly. And same metadata might be used to generate C# bindings thanks to cswin32 [1] project. The meta-assembly generation (Win32 metadata project) is based on clangsharp and it's fairly straightforward to generate interop code for native Windows libraries. Some time ago I described this process on my blog for the detours library [2] [1] https://github.com/microsoft/CsWin32 https://github.com/microsoft/CsWin32 [2] https://lowleveldesign.org/2023/11/23/generating-c-bindings-for-native-windows-libraries/ https://lowleveldesign.org/2023/11/23/generating-c-bindings-...
  - reactordev 1y ago
    The point is why is another language generating anything for C#?
  - contextfree 1y ago
    Yes, and this approach is an extension of the one taken with WinRT metadata which is also ".NET assembly" based.
- pjmlp 1y ago
  You are jumping over a few facts there. 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.
  - malkia 1y ago
    I only wish if C++/CLI worked on other platforms...
    - pjmlp 1y ago
      Same here, for those of us comfortable on C++ land, it is much easier way to do integration with native libraries, than getting P/Invoke right.
  - reactordev 1y ago
    My memory is fragmented in my older age.
- jaydcarlson 1y ago
  You're clobbering together a bunch of different stuff and not making a ton of sense. C and C++ are very different languages, and that's especially true when doing interop with them from other languages. 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).
  - reactordev 1y ago
    The only reason is name mangling. You can disable this or export declspec it and keep the C-like signature. Painstakingly recreate the API in C#, using P/Invoke, and hope for the best. It wasn’t until late 2015 that we got codegen to “automate” this, or roll your own. 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.
contextfree 1y ago
Windows and Office never adopted .NET for client code in the first place except for the Longhorn period in the mid-00s, which burned them and put them off it. If that didn't stop .NET in the two decades between then and now, I'm not sure why it would today. Actually, Windows is just now starting to adopt C# now that AOT is supported (I think the new native Copilot app is C#).
- Kwpolska 1y ago
  Many Windows Server admin tools (such as Server Manager or Virtual Machine Connection) and MMC snap-ins (e.g. Event Viewer, Hyper-V Manager) are written in .NET Framework 4. PowerShell is .NET Framework 4. Everyone’s favorite bloated IDE (Visual Studio) is .NET Framework 4 as well. In the Office land, Excel’s Power Query is .NET Framework 4. Adopting the modern .NET is probably harder due to its lifecycle.
  - reactordev 1y ago
    OMG could you imagine writing MMC snap-ins using some sort of plugin declspec import bs in C++? .Net and reflection with Assembly.Load saves so much time and effort to build modular “ship it now, deliver features later, extend it if we fall behind” apps. Not that those are good things, it just means you can defer until your MS PM gets the budget to fill those backfill positions that have been open for 12 months because the hiring bar is astrophysics
    - pjmlp 1y ago
      I can, because due to Windows team love for COM and C++, many extension points require doing exactly that. 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.
  - pjmlp 1y ago
adabyron 1y ago
Anders Hejlsberg, a main architect on C# & TS, stated somewhere that they re-wrote the TS Compiler in Go because the syntax was the closest to how it was originally written and allowed re-writing to be easiest. He has a great write up of it somewhere on GitHub. 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.
- pjmlp 1y ago
  Yeah, and then at BUILD 2025 session, he ended up explaining how they had to rewrite all the data structures, due to the less capable type system from Go versus Typescript. 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.
  - reactordev 1y ago
    Exactly. They chose Golang because they wanted to, not because of any technical limitation. Could have been C#, or Rust…
    - zeroc8 1y ago
      They used Go because it was the best fit for the task. Anders explained the reasons very well.

reactordev 1y ago

The issue was in the beginning they didn’t think interop with C/C++ was value add. People complained and they added “Managed C++” which unfortunately influenced C++03’s design a lot. It wasn’t until C++11 that Microsoft gave up. You couldn’t effectively interop with C++ without writing a managed C++ wrapper, which only worked on windows. They added support for P/Invoke to aid in Win32 calls (shell.dll, user32.dll) as a simple fix and we went nuts for it. Wrote wrappers using P/Invoke and a config map nightmare of which dll’s, or dylib’s, or so’s, you needed to get the form to show. 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.

lowleveldesign 1y ago
Interestingly, the Rust windows crate is generated from an MSIL assembly. And same metadata might be used to generate C# bindings thanks to cswin32 [1] project. The meta-assembly generation (Win32 metadata project) is based on clangsharp and it's fairly straightforward to generate interop code for native Windows libraries. Some time ago I described this process on my blog for the detours library [2] [1] https://github.com/microsoft/CsWin32 https://github.com/microsoft/CsWin32 [2] https://lowleveldesign.org/2023/11/23/generating-c-bindings-for-native-windows-libraries/ https://lowleveldesign.org/2023/11/23/generating-c-bindings-...
- reactordev 1y ago
  The point is why is another language generating anything for C#?
- contextfree 1y ago
  Yes, and this approach is an extension of the one taken with WinRT metadata which is also ".NET assembly" based.
pjmlp 1y ago
You are jumping over a few facts there. 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.
- malkia 1y ago
  I only wish if C++/CLI worked on other platforms...
  - pjmlp 1y ago
    Same here, for those of us comfortable on C++ land, it is much easier way to do integration with native libraries, than getting P/Invoke right.
- reactordev 1y ago
  My memory is fragmented in my older age.
jaydcarlson 1y ago
You're clobbering together a bunch of different stuff and not making a ton of sense. C and C++ are very different languages, and that's especially true when doing interop with them from other languages. 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).
- reactordev 1y ago
  The only reason is name mangling. You can disable this or export declspec it and keep the C-like signature. Painstakingly recreate the API in C#, using P/Invoke, and hope for the best. It wasn’t until late 2015 that we got codegen to “automate” this, or roll your own. 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.

contextfree 1y ago

Windows and Office never adopted .NET for client code in the first place except for the Longhorn period in the mid-00s, which burned them and put them off it. If that didn't stop .NET in the two decades between then and now, I'm not sure why it would today. Actually, Windows is just now starting to adopt C# now that AOT is supported (I think the new native Copilot app is C#).

Kwpolska 1y ago
Many Windows Server admin tools (such as Server Manager or Virtual Machine Connection) and MMC snap-ins (e.g. Event Viewer, Hyper-V Manager) are written in .NET Framework 4. PowerShell is .NET Framework 4. Everyone’s favorite bloated IDE (Visual Studio) is .NET Framework 4 as well. In the Office land, Excel’s Power Query is .NET Framework 4. Adopting the modern .NET is probably harder due to its lifecycle.
- reactordev 1y ago
  OMG could you imagine writing MMC snap-ins using some sort of plugin declspec import bs in C++? .Net and reflection with Assembly.Load saves so much time and effort to build modular “ship it now, deliver features later, extend it if we fall behind” apps. Not that those are good things, it just means you can defer until your MS PM gets the budget to fill those backfill positions that have been open for 12 months because the hiring bar is astrophysics
  - pjmlp 1y ago
    I can, because due to Windows team love for COM and C++, many extension points require doing exactly that. 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.
- pjmlp 1y ago

adabyron 1y ago

Anders Hejlsberg, a main architect on C# & TS, stated somewhere that they re-wrote the TS Compiler in Go because the syntax was the closest to how it was originally written and allowed re-writing to be easiest. He has a great write up of it somewhere on GitHub. 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.

pjmlp 1y ago
Yeah, and then at BUILD 2025 session, he ended up explaining how they had to rewrite all the data structures, due to the less capable type system from Go versus Typescript. 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.
- reactordev 1y ago
  Exactly. They chose Golang because they wanted to, not because of any technical limitation. Could have been C#, or Rust…
  - zeroc8 1y ago
    They used Go because it was the best fit for the task. Anders explained the reasons very well.