Still no HKTs and typeclasses, call-site expansion can only be simulated with partials and text-level code generation, etc, etc.
~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.
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-...
A dotnet tool is this: "A .NET tool is a special NuGet package that contains a console application. You can install a tool..."
https://learn.microsoft.com/en-us/dotnet/core/tools/global-t...
it's actually very similar to the node.js / NPM equivalent, which came first:
https://docs.npmjs.com/downloading-and-installing-packages-g...
"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.
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.
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.
Repeating the link again here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-run-...
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:
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...