4 ms·

> there's literally almost no reason to use Go in that case. I work in C# and C++ day to day now, and in $PREV_JOB I used Go and C++. my go builds on a simila

> there's literally almost no reason to use Go in that case. I work in C# and C++ day to day now, and in $PREV_JOB I used Go and C++. my go builds on a similar size project were quicker than the linter in my C# project is right now. Go's killer feature IMO is that it's _almost_ scripting level iteration speed.

vessenes 2y ago
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.
parliament32 2y ago
Do real organizations actually use C#? Every time we've evaluated it we concluded it's a worse, MS-flavor Java rewrite so we didn't take it too seriously. Does it have any actual advantages over Java?
- pjc50 2y ago
  It is IMO better than Java these days, although they're pretty close. Whenever I have to go back to Java I find odd things missing, like unsigned long. AOT is pretty good when it works.
- CharlieDigital 2y ago
  Lots of real orgs use C#. StackOverflow survey (self reported) for 2024 shows it at #5 leaving out HTML/CSS, and SQL[0] DevJobsScanner shows it at #4 via scraping job postings[1] It definitely has heavy adoption; well above Rust and Go despite what we see here on HN. > Does it have any actual advantages over Java? The language evolves faster and is more akin to Kotlin than to Java, IMO. The DX is fantastic and there are a few gems like LINQ, Entity Framework, and Roslyn source generators. Modern C# can be very dense yet still highly legible. C# switch expressions with pattern matching (not switch-case), for example[2], are fantastic. [0] https://survey.stackoverflow.co/2024/technology https://survey.stackoverflow.co/2024/technology [1] https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... [2] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-...
  - alemanek 2y ago
    It has been 8 years since I last wrote any C# code and I still miss LINQ to Objects. It felt so natural building up queries against collections and very readable.
    - CharlieDigital 2y ago
      They've made the language much more terse, IMO, taking a lot of cues from TypeScript/JS as well as other languages. Constructs like primary constructors, record types, pattern matching, and destructuring continue to improve ergonomics, IMO. For a quick comparison, check out https://typescript-is-like-csharp.chrlschn.dev/ https://typescript-is-like-csharp.chrlschn.dev/

vessenes 2y ago

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.

parliament32 2y ago

Do real organizations actually use C#? Every time we've evaluated it we concluded it's a worse, MS-flavor Java rewrite so we didn't take it too seriously. Does it have any actual advantages over Java?

pjc50 2y ago
It is IMO better than Java these days, although they're pretty close. Whenever I have to go back to Java I find odd things missing, like unsigned long. AOT is pretty good when it works.
CharlieDigital 2y ago
Lots of real orgs use C#. StackOverflow survey (self reported) for 2024 shows it at #5 leaving out HTML/CSS, and SQL[0] DevJobsScanner shows it at #4 via scraping job postings[1] It definitely has heavy adoption; well above Rust and Go despite what we see here on HN. > Does it have any actual advantages over Java? The language evolves faster and is more akin to Kotlin than to Java, IMO. The DX is fantastic and there are a few gems like LINQ, Entity Framework, and Roslyn source generators. Modern C# can be very dense yet still highly legible. C# switch expressions with pattern matching (not switch-case), for example[2], are fantastic. [0] https://survey.stackoverflow.co/2024/technology https://survey.stackoverflow.co/2024/technology [1] https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... [2] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-...
- alemanek 2y ago
  It has been 8 years since I last wrote any C# code and I still miss LINQ to Objects. It felt so natural building up queries against collections and very readable.
  - CharlieDigital 2y ago
    They've made the language much more terse, IMO, taking a lot of cues from TypeScript/JS as well as other languages. Constructs like primary constructors, record types, pattern matching, and destructuring continue to improve ergonomics, IMO. For a quick comparison, check out https://typescript-is-like-csharp.chrlschn.dev/ https://typescript-is-like-csharp.chrlschn.dev/