Looking forward to playing with 'dotnet run app.cs' instead of PowerShell.
It'll probably not be really useful until multiple files support arrives in .NET 11: https://github.com/dotnet/sdk/issues/48174
.NET 10 Preview 6 brings JIT improvements, one-shot tool execution
211–220 of 231 posts
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#212Earlier quoted context omitted.
That would be a first, not having significant problems. As someone that was deeply invested into WinRT since Windows 8, and went back into distributed systems and Web after all the disappointment regarding how managemetn handled it. Everyone on the Windows development ecosystem has had enough from the multiple reboots and tool changes, UWP never being as good as WPF, WinUI iterations even worse, the team now went rad…
Sorry, to be clear I meant no significant problems with the tech . Sure, it was opinionated tech, but that would’ve been ok if they had stuck with it like C# itself and fleshed it out more, which only would’ve happened had they implemented the entire OS in it. The fact that they couldn’t is in my mind the exact reason the tech failed.
I agree with your point of view, this was the second coming of Longhorn, WinRT was after all pushed by the same folks that killed the Longhorn effort, those on Windows team that sided with Steven Sinofsky, using COM in Vista as future foundation for .NET ideas in Longhorn.
The Hilo tutorial for Windows 7 remarks regarding C++ are quite telling of their point of view, on which programming language one should be using,
https://devblogs.microsoft.com/cppblog/announcing-hilo/
"The rich user experience of Windows 7 is best accessed through a powerful, flexible language, and that means C++: by using C++ you can access the raw power of the APIs for Windows 7."
From https://learn.microsoft.com/en-us/previous-versions/msdn10/f...
Joe Duffy has some remarks on how even with Midori running Asia Bing infrastructure, and proving workloads in front of the Windows team, the reception to it was rather cold.
https://youtu.be/CuD7SCqHB7k?t=921&si=r8a0nScB4fcrxxIu
Eventually he left MSR and created Pulumin on top of Go.
Meanwhile Apple/NeXT and Google, decided to push languages like Objective-C, Swift, Java, Kotlin, over classical C and C++, proving the point that change is possible if management is willing to support the team, even if that is a very long run.
See Apple's Metal Swift bindings, versus Microsoft's Agility SDK for DirectX.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#213Earlier quoted context omitted.
One of many examples of C# following in F#'s footprints years later. F# deserves a higher profile in the .NET ecosystem.
F# has been a third class citizen for a long time... Last I heard the entire f# team was ~10 people. Pretty sure "find references" still doesn't work across c# and f# (if you call a c# method from f# or vise versa). That also means symbol renames don't work correctly.
The F# team is smaller than 10 people, always has been.
~10 people is the size of the C# and VB language design and compiler team. The IDE side of things for C# and VB is about another 20+ people depending on how you count, although they also build and own infrastructure that (a) the F# team sits atop, and (b) is used by other languages in Visual Studio and is used in VS Code.
The #1 thing that people always end up surprised by is just how small and effective these teams are.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#214Earlier quoted context omitted.
> I only really wish C# would’ve been directly integrated as an alternative scripting language in PowerShell. You can embed C# in PowerShell scripts, and you have been able to do so for a long time. This webpage has a couple of examples of how this can work: https://blog.nuvotex.de/run-c-inside-powershell/
That's not "embedding C#". That's runtime loading of .NET assemblies, which every .NET language--including PowerShell--can do.
It is embedding C#, if it was embedding assemblies it would be embedding compiled code. It's no different from inlining assembly in C.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#215Earlier quoted context omitted.
Now I'm curious if C#/.Net 10 is smart enough to ignore the shebang line. Personally, I've tended to use Deno/TS for my more advanced shell scripting... the main runtime is a single executable that works fine in user context, and dependencies can be loaded/cached at first run. Of course, with C# as a shell script, you'd likely be limited to just in the box libraries or have to setup a project for sake of running a sc…
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... "dotnet run app.cs" natively supports shebang lines and nugets. The only requirement is to make sure the .net sdk is installed on your computer.
I'm guessing, however that using nuget packages means having at least a .csproj file near your .cs file with the packages defined. And downloading the packages, compiling to a space under the .csproj path, similar to a node_modules directory (bin and obj for .Net).
What I like about Deno, is the packages are downloaded/cached to a shared location not next to your script, and you don't need additional files configured. At least for shell scripts.
I'm glad shebang works, that will actually help with some process checking I'm wanting to do from CLI without launching my entire services around it.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#216Earlier quoted context omitted.
I used to like VS Code, but something about it changed and it does not feel as snappy as it once did for me. Now I prefer Zed.
Electron apps are seldom snappy, we use it, because some plugins aren't available anywhere else.
I mostly agree, that said, after VS Code starts, it runs pretty well. I almost didn't try it after Brackets and Atom as they were really slow. I haven't tried zed, so can't speak to it. VS Code was really just the first editor that I used with an integrated terminal and the directory tree. Just those two features made it a great fit for my workflow. I'm able to use the CLI to run/debug without leaving the editor, and/or run git commands from the terminal as well.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#217Earlier quoted context omitted.
Electron apps are seldom snappy, we use it, because some plugins aren't available anywhere else.
I mostly agree, that said, after VS Code starts, it runs pretty well. I almost didn't try it after Brackets and Atom as they were really slow. I haven't tried zed, so can't speak to it. VS Code was really just the first editor that I used with an integrated terminal and the directory tree. Just those two features made it a great fit for my workflow. I'm able to use the CLI to run/debug without leaving the editor, and…
Because it runs a bunch of background processes in C++, Rust, and does text rendering via WebGL.
Programmer editors with such capabilities are decades old.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#218Earlier quoted context omitted.
https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-... "dotnet run app.cs" natively supports shebang lines and nugets. The only requirement is to make sure the .net sdk is installed on your computer.
I'm guessing, however that using nuget packages means having at least a .csproj file near your .cs file with the packages defined. And downloading the packages, compiling to a space under the .csproj path, similar to a node_modules directory (bin and obj for .Net). What I like about Deno, is the packages are downloaded/cached to a shared location not next to your script, and you don't need additional files configured…
The second link in the post you replied to explains how to use NuGet packages without using a .csproj file. You are not limited to in-the-box libraries. Not having a .csproj is the whole point of this feature; everything in this blog post is talking about things you can now do without a .csproj file.
Repeating the link again here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#219Earlier quoted context omitted.
> First insanity is figuring out what in the fuck you need to support. Since I no longer support .NET Framework, it's just .NET now. .NET was two platforms for a while and they did a lot of weird stuff to make that work (.NET standard) but it's been one platform for many versions now so that specific difficulty can mostly be ignored.
Easy to say, but it poiets to ecosystem fracture. But I've been getting requests to support really weird and outlandish versions. Stuff like Mono and .Net 4.56
Microsoft managed a smoother transition than Python 2.x to 3.x. This kind of thing is very difficult. I don't see any reason to support Mono or .NET 4.56 anymore.
Re: .NET 10 Preview 6 brings JIT improvements, one-shot tool execution
#220.NET was the most sane programming ecosystem that I worked in. Great CLI, great package manager, very good stdlib, strong IDEs/Debuggers, etc. but sadly interesting jobs like OSes, databases and compilers are way less common than in C++ world :(
I liked .NET but the performance was really bad for anything that had even reasonably latency requirements. But this was 15 years ago, so maybe it has improved. I don't remember exactly what I wanted to do but it was something like pumping some event every few milliseconds and it was basically impossible. The jitter was already larger than the interval.
Dotnet's GC has a real latency problem. Miguel de Icaza gave a nice talk on why noticeable pauses are inevitable in a stop-the-world tracing GC, proposing Swift's reference-counting GC as the viable alternative [1]. Still, there are recent developments (Satori GC) with the promise to make the worst case far more palatable (e.g. 250ms -> 5ms) [2].
[1] https://www.youtube.com/watch?v=tzt36EGKEZo
[2] https://github.com/dotnet/runtime/discussions/115627#discuss...