8 ms·

The principles and origin of Go are dear to me, I feel philosophically aligned. Focus on: Dev tooling, simplicity, large scale collaboration, networked services

The principles and origin of Go are dear to me, I feel philosophically aligned. Focus on: Dev tooling, simplicity, large scale collaboration, networked services and readability

pansa2 7y ago
It’s interesting that you and I have chosen the same language for completely different reasons. I’m interested in static binaries, “batteries included”, better-than-interpreted performance, and parallelism.
apta 7y ago
> large scale collaboration What does golang have to facilitate large scale collaboration that isn't done better in languages such as Java or C#?
- tsimionescu 7y ago
  Even more, what does Go have better in terms of dev tooling than Java or C#?
  - deleted 7y ago
    [deleted]
  - vips7L 7y ago
    It doesn't.
    - helvetica2020 7y ago
      Comparing Go to the JVM for dev tooling not to mention the operational ecosystem is a bit silly. JVM is miles ahead.
  - kasey_junk 7y ago
    Go fmt Code formatters are available in Java/C# but not ones that have a default set in stone.
    - deleted 7y ago
      [deleted]
    - mohaine 7y ago
      Ditto for logging framework, unit test framework, base http framework...
      - tsimionescu 7y ago
        Those are not dev tools, they are libraries. Also, even though there is no default built in unit test framework in Java and C#, it would be hard to claim JUnit and NUnit aren't essentially that. Ditto for log4j in Java. By the way, I'm not sure you can claim to have a logging framework in your language when it can't even differentiate between debug messages, info and error messages. I'm not sure there is any significant project that can rely on Go log that couldn't as easily use stderr/stdout.
    - tsimionescu 7y ago
      Ok. But you get to stop discussing some style choices, and instead you lose a decent debugger, a decent (open source) IDE, any graphical profiler, good package management that is separate from your source control tool, and probably a few others I'm missing. And if you care about style trivialities ,you'll still need an external linter, since go fmt doesn't enforce anything about variable names , line length, function length, comment placement, line breaking and many other things some people like to obsess over.
      - andreygrehov 7y ago
        The beauty of Go is that it's so simple that you don't need a debugger. Do you need a word dictionary to read this comment? No, because this comment is simple. Same with Go. But if you need a debugger, there is Delve [1], though I only used it once to debug a dynamic programming algorithm. [1] https://github.com/go-delve/delve https://github.com/go-delve/delve
  - Kaze404 7y ago
    Considering Go's tooling ecosystem is split in half (supports modules / doesn't support modules), nothing really.
    - tsimionescu 7y ago
      To be fair, all languages that have not had modules built in suffer from this to some extent or another. The main good part about Java is that they have compatibility between code using modules and code that doesn't.
  - closeparen 7y ago
    - Native build system - Auto-formatting - Good first-party testing and benchmarking - Ppprof runs circles around VisualVM All these things are available for Java (MVN/Gradle, JUnit, IDEA, YourKit, etc) but having one right way to do them built in is pretty great. On a meta level, combination of the AST package and deterministic code formatting means it's relatively easy to write programs that manipulate source code.
    - vips7L 7y ago
      Just a nit, Java Microbenchmark Harness is apart of OpenJDK so it is "first-party".
      - closeparen 7y ago
        Oh good point. We're on Java 8 and migrating to 11...
        vips7L 7y ago
        I've been enjoying the standard library improvements in 11. The http and websocket clients are pretty easy to use.
    - tsimionescu 7y ago
      > All these things are available for Java (MVN/Gradle, JUnit, IDEA, YourKit, etc) but having one right way to do them built in is pretty great. It's great if you're just starting out, but it's irrelevant in the long run. It can even be harmful when it's coupled with the language, as you get things like having the packaging tool become deprecated, like with go dep, since a 3rd party tool can't compete with a first party tool for adoption, especially in a relatively young language like Go. For pprof vs VisualVM - I haven't yet done a lot of CPU profiling with them, but for memory I have had the exact opposite experience. VisualVM and Eclipse MAT are much easier to understand and have much more functionality for analyzing the memory of a Java process than pprof offers. Not sure what (pseudo-)deterministic code formatting has to do with the ease of manipulating program code, but having a built-in AST package is indeed a good idea. Too bad it hasn't been used to write any useful refactoring tools for Go (outside of JetBrains Goland? Haven't tried that yet). I have heard that Google uses go fix recipes to make modifications across their code base, but haven't seen any examples, and I doubt it can realistically be done in a code base that is not ridiculously well tested, and that it didn't require any manual intervention in a few corner cases in Google as well (assuming they did more than a rename).
- tmountain 7y ago
  Not a Golang expert or zealot, but a few things come to mind that make it suited for large scale projects and collaboration: 1) Extremely fast build times (even for large codebases). 2) The package system plugs directly into Git/Github. The second reduces friction for distributed/large teams to share packages with a lower administrative burden. I can't compare to modern Java/C# because I haven't used either for quite some time.
  - apta 7y ago
    > 1) Extremely fast build times (even for large codebases). Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well). > 2) The package system plugs directly into Git/Github. This doesn't suite everyone, as not all projects are open source. > with a lower administrative burden. Any serious company is not going to (1) allow arbitrary code to be pulled from github/etc. and (2) needs to maintain a local repository of it anyway in case github/maven/etc. goes down.
    - sagichmal 7y ago
      > Not much faster than C# or Java in practice Go compile times are pretty inarguably faster than these in practice, yes.
      - apta 7y ago
        Seems like you haven't worked with actual large scale golang code bases then.
        hu3 7y ago
        I have. Both C# and Go 500k+ LOC codebases. Compilation time between them is a magnitude apart it's not even arguable.
- mxschumacher 7y ago
  The simplicity of the language means no gigantic class hierarchies. Theres are fewer ways to do something. Since engineers spend most of their time reading and debugging, readability and low abstractions facilitate collaboration: it should be relatively straightforward to jump into any Go codebase. People often laud the relative ease of picking up the language. They're productive quickly, that's not by accident.
  - zerr 7y ago
    It doesn't restrict gigantic hierarchies per se, just the compiler won't help you there.
    - throwaway894345 7y ago
      There isn’t inheritance, so there are no hierarchies in the problematic sense.
      - apta 7y ago
        You get problems like this, which you don't get in traditional OO languages: https://github.com/golang/go/issues/16474 https://github.com/golang/go/issues/16474
        throwaway894345 7y ago
        What are you talking about? You could do exactly this in Java or C# or Python or Ruby or JS or etc. Not sure what ”traditional” languages you’re talking about, but this is just reflection and downcasting. It’s a bad idea, but it’s unrelated to OOP.
        apta 7y ago
        You can't cast a type to an arbitrary interface and hope that it implements the method(s) you want to call in Java or C#.
- svat 7y ago
  See https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article "Language Design in the Service of Software Engineering" for some of the design goals of Go and how they led to its current design. (For example, gofmt/gofix make automated refactorings across a large codebase (different teams) easier or more pleasant.)
- chucky_z 7y ago
  As someone who has written more C# and Java than Go... I can read Go much easier than most other languages. I can step into a huge codebase and usually quickly reason what/where I need to make my changes without too much effort. This can be the case with C# and Java, but it seems to almost always be the case with Go.
  - erik_seaberg 7y ago
    This means there's no payoff for specializing because the project has no domain-specific idioms that help at all with clarity and concision—no matter what you learn and how fluent you get, all code will look like the bulky mediocre stuff a novice would have written.
twistedpairs 7y ago
I mean it is beyond madness to even think that Go's dev tooling compares favourably to Java tools & ecosystem on the friggin' JVM. Dev tooling surrounding the JVM blitzes pretty much everything both in terms of dev(maybe code reloading could be improved for Java ala Clojure) & operations. Lightyears ahead of Go.
papito 7y ago
Go didn't even have dependency management until only recently. Readability... 2/3 of Go code is error handling, by design.
- vijaybritto 7y ago
  Yes and it has worked well for large projects like kubernetes
  - papito 7y ago
    That's because dependency management at Google is different from how the Rest of the World does it.
  - apta 7y ago
    It worked despite of it, not because of it. People can write large programs in assembly, can they not?
    - Koshkin 7y ago
      Indeed, I've had the same impression from large codebases in C++ - it surely looked like things worked in spite of all the effort to make it as complex and as inefficient as possible. (This, actually, may be a praise for C++ - you can write it as though it was Java and still get a fast program.)
  - aganame 7y ago
    Has it, though? I've heard it said that k8s codebase is not very go-like.
    - papito 7y ago
      Yep.
  - yawaramin 7y ago
    Apparently not? https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

The principles and origin of Go are dear to me, I feel philosophically aligned. Focus on: Dev tooling, simplicity, large scale collaboration, networked services and readability

pansa2 7y ago

It’s interesting that you and I have chosen the same language for completely different reasons. I’m interested in static binaries, “batteries included”, better-than-interpreted performance, and parallelism.

apta 7y ago

> large scale collaboration What does golang have to facilitate large scale collaboration that isn't done better in languages such as Java or C#?

tsimionescu 7y ago
Even more, what does Go have better in terms of dev tooling than Java or C#?
- deleted 7y ago
  [deleted]
- vips7L 7y ago
  It doesn't.
  - helvetica2020 7y ago
    Comparing Go to the JVM for dev tooling not to mention the operational ecosystem is a bit silly. JVM is miles ahead.
- kasey_junk 7y ago
  Go fmt Code formatters are available in Java/C# but not ones that have a default set in stone.
  - deleted 7y ago
    [deleted]
  - mohaine 7y ago
    Ditto for logging framework, unit test framework, base http framework...
    - tsimionescu 7y ago
      Those are not dev tools, they are libraries. Also, even though there is no default built in unit test framework in Java and C#, it would be hard to claim JUnit and NUnit aren't essentially that. Ditto for log4j in Java. By the way, I'm not sure you can claim to have a logging framework in your language when it can't even differentiate between debug messages, info and error messages. I'm not sure there is any significant project that can rely on Go log that couldn't as easily use stderr/stdout.
  - tsimionescu 7y ago
    Ok. But you get to stop discussing some style choices, and instead you lose a decent debugger, a decent (open source) IDE, any graphical profiler, good package management that is separate from your source control tool, and probably a few others I'm missing. And if you care about style trivialities ,you'll still need an external linter, since go fmt doesn't enforce anything about variable names , line length, function length, comment placement, line breaking and many other things some people like to obsess over.
    - andreygrehov 7y ago
      The beauty of Go is that it's so simple that you don't need a debugger. Do you need a word dictionary to read this comment? No, because this comment is simple. Same with Go. But if you need a debugger, there is Delve [1], though I only used it once to debug a dynamic programming algorithm. [1] https://github.com/go-delve/delve https://github.com/go-delve/delve
- Kaze404 7y ago
  Considering Go's tooling ecosystem is split in half (supports modules / doesn't support modules), nothing really.
  - tsimionescu 7y ago
    To be fair, all languages that have not had modules built in suffer from this to some extent or another. The main good part about Java is that they have compatibility between code using modules and code that doesn't.
- closeparen 7y ago
  - Native build system - Auto-formatting - Good first-party testing and benchmarking - Ppprof runs circles around VisualVM All these things are available for Java (MVN/Gradle, JUnit, IDEA, YourKit, etc) but having one right way to do them built in is pretty great. On a meta level, combination of the AST package and deterministic code formatting means it's relatively easy to write programs that manipulate source code.
  - vips7L 7y ago
    Just a nit, Java Microbenchmark Harness is apart of OpenJDK so it is "first-party".
    - closeparen 7y ago
      Oh good point. We're on Java 8 and migrating to 11...
      - vips7L 7y ago
        I've been enjoying the standard library improvements in 11. The http and websocket clients are pretty easy to use.
  - tsimionescu 7y ago
    > All these things are available for Java (MVN/Gradle, JUnit, IDEA, YourKit, etc) but having one right way to do them built in is pretty great. It's great if you're just starting out, but it's irrelevant in the long run. It can even be harmful when it's coupled with the language, as you get things like having the packaging tool become deprecated, like with go dep, since a 3rd party tool can't compete with a first party tool for adoption, especially in a relatively young language like Go. For pprof vs VisualVM - I haven't yet done a lot of CPU profiling with them, but for memory I have had the exact opposite experience. VisualVM and Eclipse MAT are much easier to understand and have much more functionality for analyzing the memory of a Java process than pprof offers. Not sure what (pseudo-)deterministic code formatting has to do with the ease of manipulating program code, but having a built-in AST package is indeed a good idea. Too bad it hasn't been used to write any useful refactoring tools for Go (outside of JetBrains Goland? Haven't tried that yet). I have heard that Google uses go fix recipes to make modifications across their code base, but haven't seen any examples, and I doubt it can realistically be done in a code base that is not ridiculously well tested, and that it didn't require any manual intervention in a few corner cases in Google as well (assuming they did more than a rename).
tmountain 7y ago
Not a Golang expert or zealot, but a few things come to mind that make it suited for large scale projects and collaboration: 1) Extremely fast build times (even for large codebases). 2) The package system plugs directly into Git/Github. The second reduces friction for distributed/large teams to share packages with a lower administrative burden. I can't compare to modern Java/C# because I haven't used either for quite some time.
- apta 7y ago
  > 1) Extremely fast build times (even for large codebases). Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well). > 2) The package system plugs directly into Git/Github. This doesn't suite everyone, as not all projects are open source. > with a lower administrative burden. Any serious company is not going to (1) allow arbitrary code to be pulled from github/etc. and (2) needs to maintain a local repository of it anyway in case github/maven/etc. goes down.
  - sagichmal 7y ago
    > Not much faster than C# or Java in practice Go compile times are pretty inarguably faster than these in practice, yes.
    - apta 7y ago
      Seems like you haven't worked with actual large scale golang code bases then.
      - hu3 7y ago
        I have. Both C# and Go 500k+ LOC codebases. Compilation time between them is a magnitude apart it's not even arguable.
mxschumacher 7y ago
The simplicity of the language means no gigantic class hierarchies. Theres are fewer ways to do something. Since engineers spend most of their time reading and debugging, readability and low abstractions facilitate collaboration: it should be relatively straightforward to jump into any Go codebase. People often laud the relative ease of picking up the language. They're productive quickly, that's not by accident.
- zerr 7y ago
  It doesn't restrict gigantic hierarchies per se, just the compiler won't help you there.
  - throwaway894345 7y ago
    There isn’t inheritance, so there are no hierarchies in the problematic sense.
    - apta 7y ago
      You get problems like this, which you don't get in traditional OO languages: https://github.com/golang/go/issues/16474 https://github.com/golang/go/issues/16474
      - throwaway894345 7y ago
        What are you talking about? You could do exactly this in Java or C# or Python or Ruby or JS or etc. Not sure what ”traditional” languages you’re talking about, but this is just reflection and downcasting. It’s a bad idea, but it’s unrelated to OOP.
        apta 7y ago
        You can't cast a type to an arbitrary interface and hope that it implements the method(s) you want to call in Java or C#.
svat 7y ago
See https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article "Language Design in the Service of Software Engineering" for some of the design goals of Go and how they led to its current design. (For example, gofmt/gofix make automated refactorings across a large codebase (different teams) easier or more pleasant.)
chucky_z 7y ago
As someone who has written more C# and Java than Go... I can read Go much easier than most other languages. I can step into a huge codebase and usually quickly reason what/where I need to make my changes without too much effort. This can be the case with C# and Java, but it seems to almost always be the case with Go.
- erik_seaberg 7y ago
  This means there's no payoff for specializing because the project has no domain-specific idioms that help at all with clarity and concision—no matter what you learn and how fluent you get, all code will look like the bulky mediocre stuff a novice would have written.

twistedpairs 7y ago

I mean it is beyond madness to even think that Go's dev tooling compares favourably to Java tools & ecosystem on the friggin' JVM. Dev tooling surrounding the JVM blitzes pretty much everything both in terms of dev(maybe code reloading could be improved for Java ala Clojure) & operations. Lightyears ahead of Go.

papito 7y ago

Go didn't even have dependency management until only recently. Readability... 2/3 of Go code is error handling, by design.

vijaybritto 7y ago
Yes and it has worked well for large projects like kubernetes
- papito 7y ago
  That's because dependency management at Google is different from how the Rest of the World does it.
- apta 7y ago
  It worked despite of it, not because of it. People can write large programs in assembly, can they not?
  - Koshkin 7y ago
    Indeed, I've had the same impression from large codebases in C++ - it surely looked like things worked in spite of all the effort to make it as complex and as inefficient as possible. (This, actually, may be a praise for C++ - you can write it as though it was Java and still get a fast program.)
- aganame 7y ago
  Has it, though? I've heard it said that k8s codebase is not very go-like.
  - papito 7y ago
    Yep.
- yawaramin 7y ago
  Apparently not? https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu...