4 ms·

I too like this feature of go quite a lot. But I think it's supercharged by the major reason I'd pick go for a mid-size team; the language is exceedingly easy t

I too like this feature of go quite a lot. But I think it's supercharged by the major reason I'd pick go for a mid-size team; the language is exceedingly easy to parse, code in and understand even if you're not a genius. I think the testing support and very moderate type support hit a valuable place in development ecosystems -- as you say, you get near instant linting feedback about a lot, and it's also pretty easy to read and write in. Basically, the mental model required for coding in go is low load. That's a great feature.

maccard 2y ago
> 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.

maccard 2y ago

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