4 ms·

Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's

Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages. If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

dragonwriter 10y ago
> Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. Well, Swift certainly wasn't when Go was introduced, but, yes, Java and C# were competitors in that role when Go was introduced (Java, even moreso at the time, tended to fall short on expressiveness -- which some argue Go does too, though in different ways -- and C# was deeply tied to .NET, which only had a first-class implementation on Windows; both of those have improved somewhat since Go was introduced.)
johncolanduoni 10y ago
Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.
- pjmlp 10y ago
  Not .NET Native, which uses the same backend as Visual C++.
  - johncolanduoni 10y ago
    Unfortunately .NET Native is still for UWP only, so for most places you'd use Go it's pretty useless. Microsoft appears to have no plans to even bring it to ASP.NET: https://github.com/aspnet/Home/issues/285 https://github.com/aspnet/Home/issues/285
    - pjmlp 10y ago
      Probably not, but they have CoreRT instead. https://github.com/dotnet/corert https://github.com/dotnet/corert Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features. And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.
      - johncolanduoni 10y ago
        ... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all. I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.
        pjmlp 10y ago
        But that isn't a language feature, rather a toolchain one. Once upon a time, on the PC we only had static compilation, regardless of the language. .NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.
        johncolanduoni 10y ago
        Is the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago. In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.
        pjmlp 10y ago
        I am just digressing, sorry if you see it as goalpost shifting.

dragonwriter 10y ago

> Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. Well, Swift certainly wasn't when Go was introduced, but, yes, Java and C# were competitors in that role when Go was introduced (Java, even moreso at the time, tended to fall short on expressiveness -- which some argue Go does too, though in different ways -- and C# was deeply tied to .NET, which only had a first-class implementation on Windows; both of those have improved somewhat since Go was introduced.)

johncolanduoni 10y ago

Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.

pjmlp 10y ago
Not .NET Native, which uses the same backend as Visual C++.
- johncolanduoni 10y ago
  Unfortunately .NET Native is still for UWP only, so for most places you'd use Go it's pretty useless. Microsoft appears to have no plans to even bring it to ASP.NET: https://github.com/aspnet/Home/issues/285 https://github.com/aspnet/Home/issues/285
  - pjmlp 10y ago
    Probably not, but they have CoreRT instead. https://github.com/dotnet/corert https://github.com/dotnet/corert Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features. And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.
    - johncolanduoni 10y ago
      ... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all. I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.
      - pjmlp 10y ago
        But that isn't a language feature, rather a toolchain one. Once upon a time, on the PC we only had static compilation, regardless of the language. .NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.
        johncolanduoni 10y ago
        Is the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago. In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.
        pjmlp 10y ago
        I am just digressing, sorry if you see it as goalpost shifting.