4 ms·

I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great? I did not post your parent commen

I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great? I did not post your parent comment.

wrs 2y ago
To name a few things: Excellent and very stable stdlib (if you’re making a networked thing), fast GC optimized for latency, async I/O without any fuss, easy CSP-like concurrency, fast compile time, statically linked binaries, large user community.
zer00eyz 2y ago
GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ----------------------- Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism. As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....
- eximius 2y ago
  > As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support. In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.
  - jimbokun 2y ago
    DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
    - eximius 2y ago
      I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
      - jimbokun 2y ago
        The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
        eximius 2y ago
        code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice. But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc
  - zer00eyz 2y ago
    Wow, that's a pretty good take. There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car. If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point are your experienced devs being productive or being babysitters? I think I would rather babysit a bunch of jr devs working in Go where correcting their issues is educational, rather than dealing with babysitting JR devs and high speed stupidity in something like rails...
zem 2y ago
seamless cross compilation as a first-class citizen, for one

I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great? I did not post your parent comment.

wrs 2y ago

To name a few things: Excellent and very stable stdlib (if you’re making a networked thing), fast GC optimized for latency, async I/O without any fuss, easy CSP-like concurrency, fast compile time, statically linked binaries, large user community.

zer00eyz 2y ago

GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ----------------------- Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism. As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....

eximius 2y ago
> As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support. In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.
- jimbokun 2y ago
  DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
  - eximius 2y ago
    I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
    - jimbokun 2y ago
      The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
      - eximius 2y ago
        code generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice. But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc
- zer00eyz 2y ago
  Wow, that's a pretty good take. There is a line here though. I think a lot of people have seen what happens when you set a bunch of JR devs loose in a node/ruby code base with all that tooling. It goes about as well as giving a lead footed suburbanite an F1 car. If you work in an agency (new every week) or in a place where you have a high number of jr devs then a framework makes a fair bit of sense. But at that point are your experienced devs being productive or being babysitters? I think I would rather babysit a bunch of jr devs working in Go where correcting their issues is educational, rather than dealing with babysitting JR devs and high speed stupidity in something like rails...

zem 2y ago

seamless cross compilation as a first-class citizen, for one