10 ms·

I expect nobody outside of Google has ever truly taken the time to study it. When was the last time you saw a programmer actually research the effectiveness of

I expect nobody outside of Google has ever truly taken the time to study it. When was the last time you saw a programmer actually research the effectiveness of their tools and not just land on "I like this. It feels right." I never have! But I'm not sure it matters. Go was created to test the theory, not because a theory was proven. It didn't have to be successful. It may be that the studies didn't happen even within Google, although that is our greatest chance. We do know Google actually cares about data, unlike programmers. That said, since Go was released it seems every other language has tried to copy it with their own twist, so while that may not come from a place of evidence, it would appear that the feeling of increased productivity[1] was felt. [1] Or something adjacent. Focusing on engineering isn't necessarily about productivity. You can't discount productivity, but it is not the top engineering concern, especially in a place like Google.

wyager 2y ago
> since Go was released it seems every other language has tried to copy it What are you referring to here? I would consider myself quite well-apprised of recent developments in PL theory (and practice) and I am struggling to come up with examples matching this description. Go's main selling point, at least as of 10 years ago, was its green threading system, and even at the time it was substantially inferior to the green threading systems available in BEAM (Erlang, Elixir) or GHC Haskell
- Mawr 2y ago
  - Java's latest addition of green threads is 100% lifted from Go. - Rust and Zig's built-in language tooling, including dependency management and an opinionated autoformatter. - Java's ZGC was an obvious response to Go's GC. There's also the realization that the fewer GC knobs there are to tune the better. - Possibly Java's quest to add value types as well, not 100% sure on the timeline. - Broad industry trend towards providing easy cross compilation into static binaries.
  - instig007 2y ago
    > Java's latest addition of green threads is 100% lifted from Go. or gevent, or many other greenlet implementations across languages, 100%
  - wyager 2y ago
    > Java's latest addition of green threads is 100% lifted from Go. Why do you say it was lifted from Go and not from one of the places Go lifted it from, like the two I mentioned? > Rust and Zig's built-in language tooling Maybe my memory is failing here, but I don't recall rust ecosystem tooling ever lagging behind Go's. The opposite, if anything. > Java's ZGC/value types Can't comment on this one, could be right, although are any of these things clearly sourced from Go? Not disagreeing, I just don't know the history here. I'm willing to believe that Java is copying from Go, because it's one of the most lumbering languages in popular use today. > Broad industry trend towards providing easy cross compilation into static binaries. I'm pretty sure Go does't get credit for this one either. This has been happening independently across many ecosystems as a natural response to increasing containerization and falling storage costs.
- mikeschinkel 2y ago
  Deno 2.0 explicitly copied Go in many features, especially with dependencies being referenced via URL, and many of the CLI's commands are inspired by Go such as install, fmt, and test.

wyager 2y ago

> since Go was released it seems every other language has tried to copy it What are you referring to here? I would consider myself quite well-apprised of recent developments in PL theory (and practice) and I am struggling to come up with examples matching this description. Go's main selling point, at least as of 10 years ago, was its green threading system, and even at the time it was substantially inferior to the green threading systems available in BEAM (Erlang, Elixir) or GHC Haskell

Mawr 2y ago
- Java's latest addition of green threads is 100% lifted from Go. - Rust and Zig's built-in language tooling, including dependency management and an opinionated autoformatter. - Java's ZGC was an obvious response to Go's GC. There's also the realization that the fewer GC knobs there are to tune the better. - Possibly Java's quest to add value types as well, not 100% sure on the timeline. - Broad industry trend towards providing easy cross compilation into static binaries.
- instig007 2y ago
  > Java's latest addition of green threads is 100% lifted from Go. or gevent, or many other greenlet implementations across languages, 100%
- wyager 2y ago
  > Java's latest addition of green threads is 100% lifted from Go. Why do you say it was lifted from Go and not from one of the places Go lifted it from, like the two I mentioned? > Rust and Zig's built-in language tooling Maybe my memory is failing here, but I don't recall rust ecosystem tooling ever lagging behind Go's. The opposite, if anything. > Java's ZGC/value types Can't comment on this one, could be right, although are any of these things clearly sourced from Go? Not disagreeing, I just don't know the history here. I'm willing to believe that Java is copying from Go, because it's one of the most lumbering languages in popular use today. > Broad industry trend towards providing easy cross compilation into static binaries. I'm pretty sure Go does't get credit for this one either. This has been happening independently across many ecosystems as a natural response to increasing containerization and falling storage costs.
mikeschinkel 2y ago
Deno 2.0 explicitly copied Go in many features, especially with dependencies being referenced via URL, and many of the CLI's commands are inspired by Go such as install, fmt, and test.