These platforms are not being considered here nor have much relevance anymore. You cannot seriously claim this unless you don't use the tooling side by side at all.
The difference is so stark it's no longer amusing. Performing setup for complex Java projects has me go through similar steps as if they were written in C++. Performing setup for C# projects of comparable complexity usually requires just cloning and hitting 'dotnet run', much like it usually happens with Rust or Go (some may claim I undeservedly bash it but credit is where credit is due).
I love your identity with .NET ecosystem, to the point of nothing else being in the way.
See latest JetBrains Developer Surrey about platforms.
.NET is a great ecosystem, but lets be real where it stands outside Microsoft shops, across everything that has a CPU on them, and the various ecosystem where sadly it doesn't even get a tier 1 support.
Programming languages are tools, a toolbox has space for plenty of them.
Are you comparing "complex Java projects" against just ordinary "C# projects"? Because ordinary Java projects will also be "./gradlew run" or the Maven equivalent, that's nothing special.
And in many other situations "./gradlew run" just doesn't work. Hell, Gradle does not even let you quickly scaffold it without pre-existing knowledge and community advice! (if you want to avoid pitfalls and have the best "streamlined" experience) Something that is not an issue in Rust or Go. Maven is even worse.
Meanwhile I can 'git clone https://github.com/ryujinx-mirror/ryujinx && cd ryujinx/src/Ryujinx && dotnet run -c Release' and it works on the first attempt (though takes a moment to pull nuget packages, it's a big project).
The Java ecosystem has incredible projects from the technical point of view (GC implementations, OpenJDK's JIT compiler), but the tooling and application packaging and distribution seem like the painful parts.
It usually works in my experience, since the toolchains feature was added, as that takes the Java version mostly out of the equation.
There is "gradle init" to scaffold a project, or of course IDEs offer a GUI over that.
Additionally, your "dotnet run" does require the dotnet tool to be installed and of the right version. The Gradle/Maven equivalents now no longer do, because they bundle scripts into your repository that will download and run the build tool itself of the right version. They just need some moderately modern Java installed. Everything the project needs including possibly a newer Java will then be downloaded.
I'm not sure what the point of naming individual projects is. I can point at dozens of projects off the top of my head where you can just clone and run them without incident.
There are painful parts of both Gradle and Maven. Absolutely. They are very far from perfect build systems. But this is partly because they do a lot more than tools like cargo does.
> "dotnet run" does require the dotnet tool to be installed and of the right version
It only needs an SDK installed on the system. If you have the necessary framework dependency, it will just work. If it's missing - the command output will specify this, which is solved by doing `sudo apt install dotnet-sdk-{version}` or just `dotnet-runtime-{version}` (because newer SDKs can build most older targets). You can also usually roll-forward the applications without retargeting them or installing older runtime (which is trivial still). It's a reliable and streamlined process.
Probably one of the best approaches to managing the SDK and framework dependencies that does not rely on any form of help from external tooling or IDEs.
Gradle and Maven need JDK installed in either case. I had Gradle that shipped with the code crash on me because it was sufficiently old to have issues on newer OpenJDK versions. Solved it by installing properly, but you can see how it can be an error-prone process.
------------------------------------
Ultimately, if you're an expert and it's a long-term project - none of this matters, solving odd breaks and tooling issues is part of the job. It's nice when things work, it's not unexpected when they don't. Some languages have more of this and some less, but at the end of the day due to business constraints and company environment none of this is a showstopper per se - you just deal with it.
Do I think the CLI tooling, dependency management, packaging and distribution is painful in Java or Kotlin? Yes, it's what also precludes either from being productive scripting languages unless you have nailed the setup that works around all of these. Does it matter for writing complex applications? Not really, project and environment setup for such is mostly one-time thing. It's coincidentally where Java ecosystem shows its strength. My rant here is posted because I believe we can discuss pros and cons without stating that specific issues don't exist when they do or vice versa.
Among everything I tried Cargo, .NET CLI and Go had the smoothest experience of things mostly working and when they weren't - not requiring to dig through heaps of documentation, possibly dumped into a language model to catch the exact specific piece that would help to solve the puzzle. I heard good things about Python's uv. If actively maintained, Node.js projects also work reliably, not so much when they aren't though. Some C++ projects are kind enough to offer build scripting that works out of box on Unix systems - props to the maintainers, which is also the case with Java projects. But whenever either of the last two didn't work, it often took me the most effort and swearing to get either working, unlike other languages.
I’d be curious to hear more about how you’re using F#? I’ve previously used Python for scripting, but just started developing for a company pretty deeply entrenched in .NET. Currently they’re migrating a lot from VB to C#, but I’ve missed having a handy scripting language like Python for small tools or test applications. Do you think F# could fill that roll?
Powershell is probably best fit for that role. You have to learn a new scripting language but since it runs on .Net you can actually bring in .Net Classes if you need a little more power.
It should be able to! F# has "gradual typing" and full type inference which means you often do not need to specify the types at all, and it also happens to be whitespace-sensitive language much like Python is. Both of these aspects should make it feel quite familiar while also giving you full advantages of static typing.
One thing to note is I find `dotnet fsi {some script name}.fsx` taking more time to start than ideal - up to 800ms is just too much, normal .NET applications usually start in a fraction of this.
I recently posted a submission here for "FSharpPacker" written by my friend that lets you compile F# scripts to standalone applications (either runtime-dependent, self-contained or fully native binaries, much like Go), it also has some comments on getting the best mileage out of it: https://news.ycombinator.com/item?id=42304835
Probably the best feature that also comes with scripting (both C# and F#) is "inline" nuget references e.g. #r "nuget: FSharp.Control.TaskSeq" which will automatically pull the dependency from nuget without ever dealing with manually installing it or tinkering with build system in any other way.
https://github.com/dotnet-script/dotnet-script (C# is also a quite productive language for scripting and small programs because of top-level statements, record types, pattern matching and many other functional features though perhaps not as strongly represented as in F#, it's just very unfortunately abused in enterprise world, with teams often going out of their way to make the code far more bloated than necessary, against the language design intentions)
F# is a leap if it's your first functional / ML style language (but worthwhile). Modern C# is good for small tools and scripting, there is the dotnet-script tool for running single .csx files
