Live data from Hacker News

.NET 10 Preview 6 brings JIT improvements, one-shot tool execution

infoworld.com

181–190 of 231 posts

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#181

Earlier quoted context omitted.

> .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 dogfood…

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…

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).

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#182
post #16

Earlier quoted context omitted.

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.

I would not touch C# unless you are already using it. Microsoft proves over and over it cannot be trusted in what they say. Watch what they do: - 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#

C# has been around a long enough time and Microsoft's teams over that time have done a pretty good job making upgrading each version easy.

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.

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#183

Earlier quoted context omitted.

Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around. Blazor's architectural model makes it impossible to be "performant." It's not even debatable. What you gain in DevEx you lose substantially in user experience.

> Why do I have to provide it? The burden is the other way around. Well, it sounds like you have an axe to grind, but I didn’t ask to “prove” anything; I was curious to learn what was meant by the bad-performance claim. I don’t program in any of these technologies; I don’t have a horse in this race. Let’s try this again: > Blazor's architectural model makes it impossible to be "performant." Say more?

It sounds like you're just baiting.

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#184

Earlier quoted context omitted.

Why does his statement not require more substance? Why do I have to provide it? The burden is the other way around. Blazor's architectural model makes it impossible to be "performant." It's not even debatable. What you gain in DevEx you lose substantially in user experience.

I'm speaking of static server-side components, thus no JS or WASM. Wouldn't touch any other Blazor mode for a public facing app.

What do you gain from implementing in Blazor at that point?

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#185

Earlier quoted context omitted.

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…

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…

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.

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#187

Earlier quoted context omitted.

> .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 dogfood…

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 te…

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.

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#188

Earlier quoted context omitted.

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#).

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.

Powershell is .NET Core since version 6, the .NET Framework one is Powershell 5.1.

Yeah, Microsoft themselves have issue moving away from .NET Framework.

You can add SQL Server CLR, Dynamics, Sharepoint on prem, to the list.

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#189

Earlier quoted context omitted.

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.

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 becau…

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.

Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution

#190
post #14

Earlier quoted context omitted.

On my little enterprise bubble, the only place remaining for C and C++ is writing native libraries to be consumed by managed languages, or bindings. The last time I wrote pure C++ applications at work, was in 2005. Libraries still regularly.

Sometimes I feel like there ought to be a Hacker News like forum for us dinosaurs stuck in the Enterprise tarpit. Instead of talking about Elixir and AWS startup credits, we’d complain about the weather and legacy CORBA components.

Indeed, it could be interesting.

What do you mean by CORBA, isn't that the cool new shiny WebAssembly components? :)

Post reply on HN