I very much doubt about TS.Net, given the rewrite in Go decision.
.NET nowadays has a serious adoption problem, and they should spend more time talking with their own colleagues at Azure, about their use of Java, Go, Rust.
.NET nowadays has a serious adoption problem, and they should spend more time talking with their own colleagues at Azure, about their use of Java, Go, Rust.
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.
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.
- basically dont use ant UI framework they say is the future and they are not using themselves - be vary of the future of some of it stuff like C#
As long as the current leadership in the C# & .NET teams remain, it's a very safe language and framework to use. They also deserve huge kudos to API & performance improvements the past decade since moving on from .NET Framework 4.x, which still runs fine.
They also have a lot of internal & external users using it.
Is there any multiplatform ui framework that's actually "native" for all the different linux ui toolkits?
Microsoft was asleep at the wheel the last decade of Ballmer, leaning too heavily on their Xbox Studios and Enterprise Cloud to care about desktops. They gladly let Mac take office share as “no enterprise software developer would ever choose a Mac”. Those famous Mac vs PC ads.
The GUI development story has plagued us for a long time. No one wants to take on the challenge of a unified user interface spec. Why? Because it will always be wrong - ever changing - and a giant suck of corporate resources.
It’s better to let each team think of their own way of doing things. Then, they can choose the best of them and release them as frameworks (WPF) only to be abandoned by the next regime change.
MAUI, UWA, Metro, WPF, all an attempt to save what effort they have made. Ultimately, everyone loves their Electron apps, so HTML has become to new UI paradigm. They move too slowly. Convinced “they know better than you” and will spend the next 5 years hyping up the next XML abomination.
I rather use XAML, if given the choice.
The 3x "Developers !" meme isn't for nothing, Microsoft just like Apple (and NeXT), always a full stack development experience story.
Everything that one needs is there on the full Visual Studio Professional, and then there was the ecosystem of small indie developers and MS Partners building on top of that.
That is quite different from UNIX FOSS culture, and has also been a friction point to those that went Apple without understanding that also have that on their DNA, regardless of OS X foundations.