2 ms·

> as you say, you get near instant linting feedback about a lot Sorry, it wasn't clear. I could run `go build && ./myapp` and have my application running quick

> as you say, you get near instant linting feedback about a lot Sorry, it wasn't clear. I could run `go build && ./myapp` and have my application running quicker than `dotnet format` finishes. Linting in .net is slower than compiling in go. Agree on everything else. It has it's share of footguns, for sure, but so does every language.

neonsunset 2y ago
FWIW dotnet format is not a linter, it's just a formatter and yes it is slow (I guess because it's ever so slightly neglected, I'd expect most developers use IDE-provided or Roslyn-provided (for VSC) auto-format instead). Overall, the tooling could be faster but because it is JIT-based and performs heavy unbound reflection, it's not very amenable to the NAOT compilation in its current form if you are used to frequently running 'dotnet build' and 'dotnet run' where startup latency imposed by JIT is most noticeable. Also keep in mind that both invoke the full build-system. It's closer to what Cargo does than what Go tooling does. Are you using .NET 9 SDK? Another feature I suggest looking at is hot-reload with 'dotnet watch'. It can shorten iteration cycles for doing the back-end work substantially.
- maccard 2y ago
  Honestly I don’t care why it’s slow. It’s up to dotnet to sell itself. It’s not my problem if dotnet invokes the full toolchain to run an incremental tool - my point is that go’s entire compilation is still quicker and that’s a huge boon.
  - neonsunset 2y ago
    The tooling itself is not _slow_ (are you intentionally misreading this?). It is slow_er. Why are you using dotnet format? Try CSharpier instead. It does not matter on CI, it matters locally where you should be using something else. And of course if you are looking for an excuse to use Go (which is a worse language), fixing this or any other "issue" will not help - there will always be another reason.

neonsunset 2y ago

FWIW dotnet format is not a linter, it's just a formatter and yes it is slow (I guess because it's ever so slightly neglected, I'd expect most developers use IDE-provided or Roslyn-provided (for VSC) auto-format instead). Overall, the tooling could be faster but because it is JIT-based and performs heavy unbound reflection, it's not very amenable to the NAOT compilation in its current form if you are used to frequently running 'dotnet build' and 'dotnet run' where startup latency imposed by JIT is most noticeable. Also keep in mind that both invoke the full build-system. It's closer to what Cargo does than what Go tooling does. Are you using .NET 9 SDK? Another feature I suggest looking at is hot-reload with 'dotnet watch'. It can shorten iteration cycles for doing the back-end work substantially.

maccard 2y ago
Honestly I don’t care why it’s slow. It’s up to dotnet to sell itself. It’s not my problem if dotnet invokes the full toolchain to run an incremental tool - my point is that go’s entire compilation is still quicker and that’s a huge boon.
- neonsunset 2y ago
  The tooling itself is not _slow_ (are you intentionally misreading this?). It is slow_er. Why are you using dotnet format? Try CSharpier instead. It does not matter on CI, it matters locally where you should be using something else. And of course if you are looking for an excuse to use Go (which is a worse language), fixing this or any other "issue" will not help - there will always be another reason.