I only really wish C# would’ve been directly integrated as an alternative scripting language in PowerShell. You may balk at the idea for causing a ton of cruft for people who don’t need it; ”a whole new scripting language!” But the thing is — PowerShell already builds upon .NET so supporting a new language is a rather small effort (relatively speaking) if it happens to be a .NET language. And C# just feels so much better for me to code in when the scripts grow in size. I’m not sure I’ll ever become friends with the implicit returns. C# has become particularly suitable for scripting with the recent developments in the language: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

"dotnet tool exec" is so you can run third party command line tools like csharpier that previously required "dotnet tool install" before you could use them. For example, in https://csharpier.com/docs/Installation you can now simply do "dotnet tool exec csharpier". This is like "npx" in the JavaScript world.

LinqPad maybe has this feature but it's selling point is as a scratch pad to experiment with working with data and general futzing around.

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/

Still no HKTs and typeclasses, call-site expansion can only be simulated with partials and text-level code generation, etc, etc.

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 script, like I've had to do with Node or Python stuff.

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.

It is so that folks can build and run "tools" that are executed, utilizing the nuget ecosystem.

Relevant links in the dotnet docs (was just a quick google away):

* https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...

* https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...

It's actually a top-level doc section in the primary dotnet docs (https://learn.microsoft.com/en-us/dotnet/).

To boil it down: you create a console app, add a couple of attributes to the solution file (https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...). Packaging and publishing to nuget (if you want to share with others) is via `dotnet pack` and `dotnet nuget push` with some flags.

I do have to say it's actually very well documented.

I found the announcement page here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...

And here are the docs for “dotnet run” https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-r...

You’re right that it’s missing this new functionality. The blog post has some details to get started, but I’m guessing that a docs link or section is missing for that.

Dotnet covers quite a bit so the docs are accordingly larger than other projects that have a smaller scope. I will say though that while hit or miss, on average I’ve enjoyed their docs more than the average project.

1. Install the dotnet sdk preview

2. Make a .CS file with top level statements.

3. dotnet run <file>

https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...

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 :(

But besides that, there’s a healthy gamedev community that embraced C# early and have been using it ever since. There’s C++ MFC guys that got duped into WPF and have been supporting it ever since. Winforms devs that are still trying to make a dark mode. I’ve even seen community grass roots “I need this in Silverlight” projects take hold and become one of the largest SDKs in the world. It’s cool. It’s fun. And with AOT, it’s everywhere. C# is like that cool uncle of your Father (Java) that likes to party all night but still holds a job. Maybe someday TS.Net will exist and we’ll all be singing “Back in my day”

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

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.

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.

[1] https://github.com/microsoft/CsWin32

[2] https://lowleveldesign.org/2023/11/23/generating-c-bindings-...

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.

In the Office land, Excel’s Power Query is .NET Framework 4.

Adopting the modern .NET is probably harder due to its lifecycle.

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

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.

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 last time I wrote pure C++ applications at work, was in 2005.

Libraries still regularly.

Same experience: last time I developed software written entirely in C++ was in 2008. Nowadays, only using C++ for DLLs consumed by C#, for 2 reasons: manually vectorized SIMD for CPU bound numerical stuff, and consuming C or C++ libraries like GPU APIs, MS Media Foundation, or Eigen.

Also not sure how it works with linters like roslynator or stylecop ?

This is something I miss very much when coming back from TS, other languages also have better formatters. C# is very tied to editors/IDEs which is a nightmare in teams where some people use vs/vs code/rider

If you're using csharpier you don't need to use Roslynator formatters. No issue with the analyzers package. The csharpier docs have info on what StyleCop rules need to be adjusted so they can work together. Personally I don't use StyleCop anymore as it seems to be fairly dead, and I don't really feel the need for things like enforcing file layout or naming.

Edit: Also I will add that unless the landscape has changed recently, I believe csharpier is the only C# tool that has deterministic formatting good enough to enforce code formatting checks in CI.

[0] https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-f...

I only tried it briefly but found it was waaay to lenient with the amount of variance in style it left unchanged (eg line breaks for function parameters) - can it get configured to produce consistent formatting like prettier ?

Also it can hook into roslyn analyzers, so if you want a more opinionated analyzer then stylecop analyzers ( https://github.com/DotNetAnalyzers/StyleCopAnalyzers) would be an option, although I haven't used it myself for a long time.

Besides, I really like its formatting style.

Often in the .NET ecosystem, it seems there is exactly one library or framework for thing $X or $Y. Whereas in the JVM ecosystem, you have 30+ logging libraries, 87 different MVC frameworks, etc. (yes, I'm being a bit facetious, but you get the point).

I imagine .NET developers often think this is a good thing, in regard to their ecosystem. No guessing what to use, just go with the "blessed" path and don't think about it. And, to that end, there is some obvious merit to this.

However, I feel the .NET ecosystem loses out on cross-pollination of ideas. There's zero possibility Microsoft's employees just happen to make the best frameworks and libraries... there should be many web frameworks - each competing for mindshare and trying to out-innovate each other, each with their own pro's and con's, etc.

So, while .NET might be technically open source, it still feels rather like a closed source ecosystem, controlled by a single corporate entity.

They purposefully made it painful to venture out of the MS ecosystem.

Libraries getting swallowed up is not so bad as it sounds. For instance for web frameworks there was a phase of experimentation with projects like Nancy that inspired changes for asp.net core. There is still alternatives like fast endpoints.

Also you have things happening like integrated system.text.json replacing newtonsoft.json that over time took on some cruft.

Microsoft still has some lessons to learn about fostering an active open source ecosystem -- of course, unless they are intentionally suppressing it in .NET.

Then serilog came out and pretty much everyone switched to that in a very short period.

I mostly just dislike a lot of the excessive use of "Enterprise Patterns" for projects that don't come close to actually needing them.

https://github.com/SubtitleEdit/subtitleedit

https://github.com/jellyfin/jellyfin

https://github.com/AvaloniaUI/Avalonia

https://github.com/bitwarden/server

https://github.com/unoplatform/uno

https://github.com/files-community/Files

https://github.com/NickeManarin/ScreenToGif

https://github.com/DevToys-app/DevToys

https://github.com/d2phap/ImageGlass

https://github.com/ShareX/ShareX

https://github.com/duplicati/duplicati

https://github.com/OpenRA/OpenRA

https://en.wikipedia.org/wiki/Ryujinx

https://sourceforge.net/projects/keepass/

https://github.com/orchardcms

https://github.com/piranhacms/piranha.core

https://github.com/umbraco/Umbraco-CMS

https://github.com/goatcorp/Dalamud

A lot of the *arr tools like Sonarr

Bitwarden and Keepass

We are out there :)

[1] https://github.com/louthy/language-ext

Having written libraries in .Net I fully disagree with that notion.

First insanity is figuring out what in the fuck you need to support. .Net framework or .Net standard or .Net Core or Mono (or .Net Duplo or .Net dot nes :P).

Second is the Source generators. I swear using t4 templates is the saner option. I've had cached artifacts appearing out of the fucking nowhere like unkillable zombies despite closing the Rider, clearing its cache, and killing build server.

Third is the availability of packages. In Rust and Java there are like several libs for anything (even if C bindings).

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.

Still no migration path from WinForms to something modern.

I love .NET but if you're taking on an older desktop app that is still using VB.NET and WinForms it feels like Microsoft have decided to let you circle the drain with no supported way forward into MAUI or whatever stupid XAML UI they decided is the solution these days.

On a server, .NET is fantastic and it's entirely possible to build and debug your system on Linux with no loss of productivity, but the desktop stuff is bad and getting worse.

But then they aren't even willing to invest the time to dogfood their own products and fully replace the windows UI. Really doesn't inspire confidence.

I suspect they also made a bad bet by going so hard on blazor without putting more support behind WASM itself. Now that's stalled out with WASM's own failure to reach critical mass.

I agree that it seems they’ve made some bad bets and now are bogged down supporting half a dozen different frameworks with different limitations and tradeoffs.

They keep trying to reinvent the wheel, but it doesn’t seem like they’ve ever really meaningfully improved on WPF.

At least there is Avalonia for an open source, cross platform WPF alternative. It seems like the sanest way of making desktop applications with C# currently.

It’s so aggravating because ASP.NET with server side Blazor components really has it all: type safety, server-side components ala Astro, fantastic ORM model, great runtime perf. But this little issue makes dev quite tedious at present: did I mistype a Tailwind class name, or did dotnet watch miss the change?

What would you say would be the benefit of Blazor vs HTMX and Razor Pages for subviews ?

My experience with Microsoft UI toolkits after winforms, is that they are all janky over-engineered stuff (Silverlight/WPF/Xamarin/Maui) terrible tooling and support compared to alternatives. And Blazor using websockets makes me believe it is the same. The compile to WASM idea is a typical example of this.

So what would be the selling point of Blazor ? It feels like you are just bundling stuff into Blazor magic when you could KISS with something simple like HTMX ?

Blazor WASM makes some sense if Silverlight ever made sense for a project: it's a way to ship C# directly to the browser for maximal code sharing with other C# projects in a C# ecosystem. It's basically "what if Angular/React was just Razor Pages running on the browser?"

It's absolutely the opposite of KISS, it's lifting and shifting the entire .NET runtime in WASM to the client. Outside of corporate networks and packaged apps like Electron or Tauri, I'm not sure it makes any sense. But if you like writing Razor Pages and wished they ran closer to the client metal, and you can afford the bandwidth of an entire .NET application soup-to-nuts as your SPA framework, there is a sense to it.

If all you think you need is Razor Pages with HTMX that's probably all you need.

That is exactly my read of it, especially given Microsoft track record on delivering with stuff like this.

Not sure about the Silverlight comparison - in the days of Flash, browsers did not even have a way to stream video reliably, nowadays it just cramming a square peg in to a round hole - heavyweight runtime built on multithreading crammed to a single threaded event loop. I have not tried it - but after using .net in much more powerful/native envs like Android - I know for a fact that the iteration/build/debugging story sucks compared to native JS/TS. Also as bad JS is, TS makes it saner, tooling has matured and DOM APIs are built for JS.

Sometimes the "event loop" part is forgotten because JS' single threaded thing is very "cooperatively threaded". This is a large part of why async/await works so well in JS and is growing so quickly in adoptions. .NET's multithreading is built in a way to excel in "cooperatively threaded" environments (its task pools are cooperative by default, for instance, and also arguably heavy use of async/await was C#'s idea first).

It would be great to see more WASM multithreading powers, but writing C# for today's WASM environment doesn't feel that different from "regular" multi-threaded C#.

> I know for a fact that the iteration/build/debugging story sucks compared to native JS/TS

WASM debugging is nearly great, including growing Sourcemap support. The ability for Visual Studio to be the Debugger interface to Chromium-based browsers is more powerful that ever. Certainly in its debugging story Blazor WASM is much advanced from Silverlight which was only really debuggable in IE and then was still often flaky.

> DOM APIs are built for JS

There's still talk of making more direct DOM APIs for WASM. Might be interesting to see eventually.

This is why it is so easy to relate Blazor WASM to React. Blazor is essentially using Razor templates to define a Virtual DOM which it then sends render updates across the WASM/JS boundary to a very tiny virtual DOM renderer.

It's not what I'd use for smarter direct DOM work, but in comparison to React it gets the job done and works surprisingly well, even with the language barrier and data marshalling across sandbox layers.

I've used Blazor WASM on Enterprise projects. I'd probably use it again on Enterprise projects. It can be real nice to have backend and frontend all entirely in C#. (In different projects. So that you can scale them independently if nothing else.)

I wouldn't necessarily say there's any benefit of Blazor over HTMX, it just depends on what you're most comfortable with and what works for you in your project. But you could architect your front-end in a similar way where you have small blazor components in your pages with interactivity.

I think Blazor is in a nice state now, where I can iterate very quickly on projects with just static server side rendering and add interactivity whenever it's needed. It gives me a very fast website, rendered on the server, and the option to add some interactivity whenever I need.

https://www.youtube.com/watch?v=uS6m37jhdqM&t=1800s

Agreed. I bailed on Blazor over the tooling experience. Editing components in VS2022 was so janky for me. Syntax highlighting and intellisense never worked correctly.

There’s been some changes and improvements, but I really have to ask what the editor tooling team within that team are doing.

I know there are some very difficult problems involved in parsing and formatting and highlighting bastardised mixtures of HTML, C#, and JavaScript all in the same file but if anything I think that perhaps suggests it was a bad idea to begin with.

Consider the tooling for desktop and mobile apps with XAML (WPF, Avalonia) or even WinForms - they all have code behind support.

Meaning there is no need (or ability) to mix all three in the same file.

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.

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?

Why, for instance, does the CLR GC not have something like TLABs? The result is that it seems like .NET devs have to worry a lot more about the expense of small, short-lived allocations, while in Java these things are much cheaper.

Overall, I think it's easier to program idiomatically in Java and get decent performance out-of-the-box, while C# may provide more opportunities for optimization without having to rely on something equivalent to sun.misc.Unsafe and offheap allocations.

I've always heard this, but does it actually manifest in noticeably worse performance than the JVM? Go has a much simpler GC, but it's not terribly slower than Java (I do know they are optimized for different things).

It seems like C# is within bounds of Java while also having great performance escape hatches.

https://devblogs.microsoft.com/dotnet/dotnet-10-preview-6/

https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotn...

The problem is MS is unwilling to stick with anything dev wise. The whole ecos system is a littered realm of half forgotten techs that may or may not be supported anymore. Wrapped with very confusing messaging to the devs what to use.

For split web projects, definitely work on the web ui in VS Code.

https://learn.microsoft.com/en-us/cpp/porting/binary-compat-...

This saved so much time, space and support - where previously we had to recompile stuff, and if you had Maya/MotionBuilder/etc plugin it had to use the right compiler.

Also now even with newer IDE you can instruct the project to use older (or even better - a specific) version of the toolchain.

> "Stay tuned for more details later this summer about what's coming next for Visual Studio..."

https://learn.microsoft.com/en-us/visualstudio/releases/2022...

How are things these days with .NET 10! Jesus, 10!

Dudes who use it daily, what is your favorite feature you think?

Favorite recent runtime feature is all the cool low level stuff opened up by Span<T> (and Memory<T>). It has a similarity to Rust borrowing, but well integrated into the CLR's existing type system. It has opened all sorts of performance code possibilities that is still memory-safe/type-safe with fewer needs for falling back to "unsafe" operations. This is not just exciting because it is an interesting playground if you like low-level programming, but also because it has been a performance flood lifting all boats in the .NET ecosystem. A lot of code over the last few years has gotten easy performance boosts by just recompiling (because the compilers were taught to prefer Span/Memory overloads when they get added; no change to C# or F# code, just the compiler picking a new performance path).

WinForms app development hasn't changed one bit in 25 years.

If you code in C# then they've added some nice new language features every year to make your code a little tidier.

And the whole framework is totally open source now, which is a bonus.

There's nothing I'm really asking for. It does pretty much everything I need these days.

My fav feature is honestly how little boilerplate I need compared to Spring Boot and the syntax sugar is honestly really nice.

I also really like that its development is fairly open (it's on github). From a more technical point of view, I think C# is a slightly better Java. A pretty nice language overall. It's not gui-or-nothing with dotnet core so it's not too difficult to create workflows for ci/cd pipelines, although the .net framework solutions we still have aren't too much harder to script: msbuild is pretty capable.

The last 5 version have been released a year apart, in Novembers.

The question, of course, becomes: when does that matter? For a lot of people who are in to .NET, they see that as a benefit. Look at Go through this lens, and it's similar; the go CLI is the compiler, linker, package manager etc. I suppose the biggest difference is that it doesn't prescribe solutions and projects and file formats to go with them, which enables you to put this in any existing CI, make or other system.

.NET 9 (and VS2022) added support for the SLNX replacement format to replace the old weird solution format:

https://devblogs.microsoft.com/visualstudio/new-simpler-solu...

You don't have to use a Solution at all with the CLI, you can do everything in a single Project and one full tree glob. (Technically you haven't need a Solution with Visual Studio for a long while either, if you don't mind it sometimes auto-creating them at compile time, and even then you can just .gitignore .sln and not care. But even that random auto-.sln file thing has disappeared in recent years and Visual Studio has learned more auto-workspace tricks from VS Code.)

I have started projects that just did that, started with a simple glob-only project and no prescribed file layout.

Yeah, dotnet doesn't let you micro-manage the linker specifically, but few languages since C++ do and arguably the C/C++ linker sometimes seems as much a bug of C/C++ as a feature in modern times.

Well, spiritually this is the 13th(?) major version of .NET (possibly more if we count Silverlight's runtime). You missed the part when there was .NET Core 1-3 alongside the old .NET Framework 4.8., and then they skipped Core 4 and stopped supporting Framework so they could finally fix their naming scheme.

They did when switching away from .NET Framework, but this was because they had to reimplement many features from scratch to work on other platforms, and certain parts got left behind.

I've worked in .NET shops with very niche WPF/WinForms applications where customers were years behind with our software/major .NET Framework releases.

I don't think it's a technical challenge, more a cultural one.

They may still get left behind on an older version of your software because they want to be, but their relationship to Windows is no longer the big excuse/reason to skip updating to your latest that it used to be.

Similar feat with .NET core usually results in a 70-80MB executable.

Also if you use trim unused code and compress the executable in my experience it's usually a lot smaller than this.

Now I have to update software and all its dependencies without a real benefit.

It’s equivalent of buying a new PC because MS tries to force Windows 11.

Lets waste lots of time and resources for nothing.

There's a lot of quality of life features of the later versions of C# that we're missing out on. My code was a LOT more streamlined in my .NET 9 app.

That's not how that works. Nothing about the .NET license entitles Microsoft to what you make with the tooling.