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