Run a C# file directly using dotnet run app.cs

It can easily add hundreds of milliseconds in various situations you can't easily control.

I had some Windows command-line apps written in C# that always took at least 0.5s to run. It was an annoying distraction. After Microsoft's improvements the same code was running in 0.2s. Still perceptible, but a great improvement. This was on a cheap laptop bought in 2009.

I'm aware that .Net is using a different runtime now, but I'm amazed that it so slow on a high-end modern laptop.

Task manager doesn't show it, but process explorer shows kernel processes and the story is quite clear.

> But that’s the thing. It’s a JIT, running a VM. Swift emits native code. Big difference.

It's not only a JIT, you can preJIT with R2R if you need, or precompile with NativeAOT, or i think you can fully interpret with Mono.

Edit: it looks like the issue with the dotnet cli itself, which until now was not on a 'hot path'. `dotnet help` also take half a second to show up. When running a dll directly, I think it doesn't load the cli app and just run the code necessary to start the dll.

Because that's what dotnet run does

I don't think you're presenting a valid scenario. I mean, the dotnet run file.cs workflow is suited for one-off runs, but even if you're somehow assuming that these hypothetical cold start times are impossible to optimize (big, unrealistic if) then it seems you're missing the fact that this feature also allows you to build the app and generate a stand-alone binary.

So exactly what's the problem?

But then each script has an individual list of dependencies so there should be no need for further scoping like in npm (as in, the compilation of the script is always scoped behind the scenes). In this regard, both should be similar to https://docs.astral.sh/uv/guides/scripts/#declaring-script-d... which I absolutely love.

Theres a fair argument that complex scripts require a complex scripting language, but you have to have a good reason to pick powershell.

Typically, on non-windows, there is not one.

Its the same “tier” as bash; the thing you use because its there and then reach past for hard things. The same reason as bash.

Theres no realistic situation I would (and Ive written a lot of powershell) go, “gee, this bash script/makefile is too big and complex, lets rewrite it in powershell!”

Bash has a huge number of footguns, and a rather unusual syntax. It's not a language where you can safely let a junior developer tweak something in a script and expect it to go well. Using a linter like ShellCheck is essentially a hard requirement.

If you're working in a team where 99.9% of the code you're maintaining is C#, having a handful of load-bearing Bash scripts lying around is probably a Really Bad Idea. Just convert it to C# as well and save everyone a lot of trouble.

If you are a dotnet dev shop, it is quite likely that dotnet is also a tool that is already there the places you need automation.

Plus, its also the tool that is already there in your team’s skillset.

Dotnet with all dependencies you will get in how much time? In like 6 minutes including all the preparations? So the difference between "already there" and dotnet - is 6 minutes. It's hard to imagine a case where this difference matters.

Ecosystem means nothing if you have comparable or even better alternatives in a framework of choice.

Also, it's not like the likes of Python don't have their warts. Anyone with a cursory experience with Python is aware of all the multiplatform gotchas it has with basic things like file handing.

The reason being the lack of UNIX skills on the new team, and apparently it was easier to pay for the development effort.

Afterwards there were some questions about the performance decrease.

I had to patiently explain the difference between having a set of scripts orchestrating a workflow of native code applications written in C, and having the JVM do the same work, never long enough for the JIT C2 to kick in.

The problem with UNIX culture shops not picking up .NET has everything to do with the Microsoft stigma, and everything the management keeps doing against .NET team efforts, like VSCode vs VS tooling features, C# DevKit license, what frameworks get to be on GNU/Linux, and the current ongoing issues with FOSS on .NET and the role of .NET Foundation.

Minimal APIs and now scripting, which already existed as third party solutions (search for csx), won't sort out those issues.

They can even start by going into Azure and check why there are so many projects now chosing other languages instead of .NET, when working on the open.

This would already be the first place to promote .NET adoption.

What's the difference between installing .NET or, say, python of node?

From your complain, it doesn't seem you're pointing anything wrong with .csproj files. You struggled with a usecases that's far from normal and might not even be right for you. Without details, it's hard to tell if you're missing something or you're blaming the tool instead of focusing on getting things to work.

    <Project Sdk="Microsoft.NET.Sdk">
    
      <PropertyGroup>
        <TargetFramework>net8.0</TargetFramework>
      </PropertyGroup>
    
    </Project>

In the "SDK-Style", files are included by default by wildcards, you no longer need to include every file in the csproj. Adding NuGet references by hand is now just as easy as under an <ItemGroup> add a <PackageReference Include"Package.Name" Version="1.0.0" />. (For a while NuGet references were in their own file, but there would also be a dance of "assembly binding redirects" NuGet used to also need to sometimes include in a csproj. All of that is gone today and much simplified to a single easy to write by hand tag.) Other previously "advanced" things you'd only trust the UI to do are more easily done by hand now, too.

> Also, just talk to a C# developer, I bet over half of them have never even edited a .csproj and only use visual studio as a GUI to configure their projects.

Depends on the era, but in the worst days of the csproj verbosity where every file had to be mentioned (included as an Item) in the csproj I didn't know a single C# developer that hadn't needed to do some XML surgery in a csproj file at some point, though most of that was to fix merge conflicts because back then it was a common source of merge conflicts. Fixing merge conflicts in a csproj used to be a rite of passage for any reasonably sized team. (I do not miss those days and am very happy with the "SDK-Style csproj" today.)

   make it work

Is it, though? The guidelines seem to be pretty straight forward: unless you want to target a new language feature, you can just target netstandard or whatever target framework your code requires at the moment. This barely registers as a concern.

https://learn.microsoft.com/en-us/dotnet/standard/net-standa...

> It's okay to read, but basically impossible to write by hand.

Are you sure about that? I mean, what's the best example you can come up with?

This complain is even more baffling considering a) the amount of XML editor helpers out there, b) the fact that most mainstream build systems out there are already XML-based.

It's gotten real simple in the last few years, and is basically the exact same flowchart as Node.JS:

    Do you need LTS support? --> Yes --> target the most recent even number (.NET 8.0 today)
      ^--> No --> target the most recent version (.NET 9.0 today)

Everything else can be forgotten. It's no longer needed. It's no longer a thing. It's a dead version for people that need deep legacy support in dark brownfields and nothing more than that.

I don't think there are any good project definition files. At least csproj is standardised XML, so your IDE can tell if you're allowed to do something or not before you try to hit build.

As for targeting frameworks and versions, I think that's only a problem on Windows (where you have the built in one and the one(s) you download to run applications) and even then you can just target the latest version of whatever framework you need and compile to a standard executable if you don't want to deal with framework stuff. The frameworks themselves don't have an equivalent in most languages, but that's a feature, not a bug. It's not even C# exclusive, I've had to download specific JREs to run Java code because the standard JRE was missing a few DLLs for instance.

What do you think happens when you try to use Python 3.9 to run a script that depends on features added in 3.10? This is inherent to anything that requires an interpreter or runtime. Most scripting tools just default "your stuff breaks if you get it wrong" whereas .Net requires you to explicitly define the dependency.

You're in luck - C# doesn't force everything to be a class and has many functional programming features. Hell, even C++ has had functions as data for, like, 10 years now.

You don't need to. A few years ago, C# introduced top-level statements. They were introduced in 2020, I think.

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

  System.Console.WriteLine("Hello world!");

  int Fib(int n) => (n <= 1) ? n : Fib(n - 1) + Fib(n - 2);

I find C# to be remarkably better than javascript, for example, of having a 'right' way to do something.

Even when there are multiple ways the community tends to coalesce around one way.