7 ms·

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a

I've enjoyed writing Go for years. However, it's not been the language that does it for me. It's been the combination of features and ecosystem that makes it a default. It's hard to explain, but the language is one you can throw into a team of random developers and come out with benchmarks, tests, CI/CD pipelines, unified code formatting, and good parallel work models (via goroutines) almost every time. Builds are instant. Built artifacts are a single binary - not 1,200 files that must be moved. Every single package that has any traction is both easy to read and has documentation inline or via published go.dev docs. It's easy enough the frontend JS guy can write it. It's complex enough you can use goa.design or go-kit to auto generate openapi specs and complex microservice designs that support multiple transports (like gRPC). Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks. I've had less issues with production Go applications than any other language. I don't want it to win over Rust though, Rust is awesome. I want Go to replace Java.

jjice 4y ago
Wholely agree that Go tooling is fantastic, especially since most of it is bundled and directly supported by the language. Honestly my biggest gripe is nillability, but it really doesn't bite me nearly as much as it did in Java or C#. There's a reason it's sliding into the "boring and effective" (that's a good thing) camp of languages, but it's still got some cool factor.
- tptacek 4y ago
  Strong agree. Go isn't my favorite language, but it is my favorite programming tool.
makestuff 4y ago
Yeah I was at a startup where maybe 10% of engineering had used go before and 20% had used Java before (it was a PHP monolith so most people were PHP developers). The Java code that was written was pretty awful (I was hired probably due to my java experience, so I had a decent idea of good java). However, the Go services were actually really good. There is something about having a simple language that works really well for backend CRUD services.
- nogridbag 4y ago
  I think the main difference is there's just an order of magnitude more awful Java devs than Go developers due to Java being the most popular backend language for N years. If the timeline was flipped and Java was the new language on the block while Go had been around for 25 years, I bet you'd see the quality of Java code was vastly superior simply due to Java attracting passionate developers interested in learning new technology. I still see Java devs with 15-20 years "experience" coding like 1st year CS students. It really wouldn't matter what language they were coding in.
- rob-olmos 4y ago
  What sticks out most for the Java code being pretty awful? Was the PHP code just as awful too in similar aspects?
- kaba0 4y ago
  Go is not really an easier language than Java, though.
  - throwaway894345 4y ago
    Back in 2012 I was considerably better-versed in Java (it was the main language for my CS education and a bunch of my hobby stuff). Still, I ended up picking Go because it was so much easier--no need to deal with Maven or Gradle or the alternatives, no need to pick a testing framework or a test runner, no need to configure CI jobs to publish documentation or source code packages, no need to run some external web server process, no need to worry about runtime dependencies (including the JVM itself), etc. No need to navigate an ecosystem (including stdlib) riddled with inheritance and other antipatterns, etc. No need to get a master's degree in tuning the JVM. Text editor plugins just worked. `gofmt` existed and was ubiquitous. The language itself was far smaller and it had native, idiomatic value types from inception!. Everything about Go was just so much easier than Java.
gw98 4y ago
Agree on all points. I'd like to add that it just tends to not punch you in the balls. I originally picked it up trying to solve a simple web hook integration problem. I had a Python Flask app running which received a webhook, did some data transformation and did a POST to an API. After spending a whole morning pissing around trying to get uWSGI, systemd via ansible etc working I went for lunch. Came back, learned enough Go and had it working in a single binary with systemd unit before the end of the day without any 3rd party packages, server mechanisms, dependency management, futzing. It just worked. The same code has been moved into docker, then into kubernetes over the last few years with no change, no bugs and no headaches.
- alyandon 4y ago
  Similar experiences with Go vs Java and Python. One thing that has stuck with me to this day was how quickly I was able to write a proxy to distribute keys consistently across a set of Redis servers to break out of a bottleneck in an internal processing pipeline.
- traceroute66 4y ago
  > I had a Python .... IMHO, the biggest win of Go over anything Python is the single distributable. You write once. Compile (or cross-compile) once. Distribute the binary. Job done. Python you've got the hell of dependencies. Write your script once, but then users have to endure pip hell for the hundreds of libraries you've depended on. And then the potential different dependencies between different Python stuff. Go is awesome for that and the Go stdlib has 80+% of what most people need.
  - throwaway894345 4y ago
    Also, you can run that Go binary on any Linux system whereas with Python you'll be lucky if you can run on any non-Ubuntu/RHEL Linux system. Moreover, that Go binary will be like 10% of the size of a Python artifact (which amounts to significantly faster deployments and cold start times for things like Lambdas) and it will perform about 2-3 orders of magnitude faster than Python and there will be headroom to optimize (whereas with Python you're usually not going to eek much performance out beyond the naive implementation without substantially overhauling the architecture).
tech_tuna 4y ago
Go has been an acquired taste for me. I still don't love its syntax but the tooling and interesting combination of properties (GC, compiles to a binary, strongly typed) are what ultimately won me over. It's perfect for middleware, APIs and CLI tools.
KingOfCoders 4y ago
I currently write a SaaS website in Go after doing quite some Rust. I do prefer Rust as a language - it's more expresive and I greatly prefer Result<> over error, but it has two major downsides for me compared to Go. First compilation is much slower and Go feels like a non-compiled language because of the compilation speed (my last startup I've used Scala with horrendous compilation speeds, the main reason not to use it) The second is the borrow checker. It's excellent mostly (love explicit mut) but fails for me for structs with sub-structs coming from different owners. Very fast you have Arc<> noise everywhere. The Go GC just works. A simple GC as a -gc=on with auto-arc for variables without lifetime annotations for people that don't need Rust for embedded applications would be a dream come true. I do love 'import "embed"' in Go to embed web files (templates) inside a binary and then deploy/manage that one binary with systemd with zero downtime updates with systemd port activation. Slick.
- TrustPatches 4y ago
  Not sure if it’s an exact parallel, but you can also embed files into rust binaries with “include_bytes!” and “include_str!”.
  - 5e92cb50239222b 4y ago
    It's a bit more advanced than what Rust macros provided last time I checked. You can shove whole directories in there and then traverse them or serve as static resources with pretty much one line of code. Random blog post with a few examples: https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/ https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/
    - TrustPatches 4y ago
      Very cool, I guess one the the advantages of rust macros is that you could write your own to do something more advanced in theory
    - super_flanker 4y ago
      You can do the same in Rust with include_dir[1] 1: https://docs.rs/include_dir/latest/include_dir/ https://docs.rs/include_dir/latest/include_dir/
nicolashahn 4y ago
Slight counterpoint - I have written Go in the past and now am working with Kotlin and to be honest, I prefer it. I wouldn't mind Kotlin being the new Java rather than Go.
- za3faran 4y ago
  Java is the new Java :) With features like records, virtual threads, pattern matching, sealed types, string templates, and more to come, it's shaping up very nicely.
  - Xeoncross 4y ago
    The compile times and the fact it takes 10x the memory for a lot of services is certainly something I would like to see addressed. Not to mention that Java for things like serverless has painfully slow startup times. Java runs nice and quick when it's ready, but it's slow to get there and quite a memory hog.
    - kaba0 4y ago
      Compile times? Besides gradle’s startup time, java compiles just as fast as go imo. Go barely does any optimization, but javac does even less - so I don’t really see it a problem on actually similarly sized projects. Memory usage is a tradeoff — a good GC works best with a bit more overhead.
    - erik_seaberg 4y ago
      I want the compiler doing as much work as it possibly can. If they can somehow make the compiler faster, I guess that’s nice, but I don’t want to be saddled with a language that’s been compromised to move work from the computer back into 0.0001 MHz human brains.
  - eweise 4y ago
    I tried the latest version of Java. Unfortunately, it still feels very clunky. They need to add the ability specify functions directly instead of as classes. ex: BiConsumer<T,U>
origin_path 4y ago
"Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks" My experience with Go has been that errors get "handled" by propagating them up the stack manually and then logging them, without keeping proper track of how the error got there. So there is error handling but only in theory, in practice what you get is a sort of hand-written stack unwinding logic with far worse functionality and consistency than exceptions, at 100x the verbosity.
- throwawaygal7 4y ago
  In go, you either handle the error where it happens or close to it, or log it. No need to pass things up just to log. I like the simplicity, and the zero cost at runtime. If you could handle the error in another lang you could handle it in go, or youd just supress or log it anyway.
  - erik_seaberg 4y ago
    In a microservice, almost all errors are handled by doing nothing and returning the error to the caller. Retrying may be an option, but you have to be careful not to make your system into a cascading failure amplifier.
kaba0 4y ago
Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.
- smasher164 4y ago
  > A pragmatic “handle it here or bubble it up” is a much better approach This is exactly the approach used in Go code, so I'm not sure what you're referring to. If you're talking about the fact that you can technically ignore an error result like res, _ := doWork() then that's a fair point. But we still have https://staticcheck.io/docs/checks#SA4006 https://staticcheck.io/docs/checks#SA4006 for that.
  - kaba0 4y ago
    I don’t see any automatic bubble up with Go.
    - smasher164 4y ago
      I don’t think the original commenter said anything about “automatic”. That’s more of a subjective decision—whether or not you manually bubble up an error, or it just floats up because of the exception handler. Empirically, java code has had terrible error handling, because people just stick one catch statement at the root of their program. Go atleast confronts you with the error at every step.
      - kaba0 4y ago
        And that is exactly the wrong approach. You really can’t do anything with the error case at most places. If I write a web server, which parts could knowingly handle a db connection error? Either the db driver internally, or going 10 deep higher and the request handler returning an 500 error. In go you would just verbosely (and error pronely!!) have to manually bubble it up, while this is automatically happening in Java with an informative stack trace, with no option to forget about it. Java is the one that handles error cases properly (and that’s why you might see exceptions more there — because they weren’t silenced somewhere wrongly!) here.
throwaway894345 4y ago
Not only that, but all of the features Go doesn't have means that you don't have to navigate the "which subset of the language does this project use?" problem. Every project uses pretty much the same language features. Similarly, the code formatter is universal and minimally configurable, so the code formatting looks the same across the ecosystem. Virtually everyone uses the same test runner too. Also, you get documentation (including links to third party and standard library packages!) for free--no need to set up a CI pipeline for publishing documentation packages. Same with package hosting--no need to set up a CI pipeline to publish packages. There's a ton of this kind of stuff that amounts to a whole lot of productivity that gets overlooked in all of the pennywise-pound-foolish type-system navel-gazing that programmers fixate on.
- Xeoncross 4y ago
  "Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite" - https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s
- HillRat 4y ago
  One of my mantras is "what you say no to is more important than what you say yes to," and the Go team says no to a lot. It can be frustrating and Go can be incredibly inexpressive (and, frankly, boring) compared to other languages, but it's hard to find another stack in which any random developer can be as productive as quickly on any random codebase. There are other languages where my personal velocity is a lot higher, but at a team level I haven't found anything that beats Go.
avgcorrection 4y ago
> I don't want it to win over Rust though, Rust is awesome. Why even perpetuate this red herring comparison—maybe over a decade old?—by making unprompted mentions of Rust though.
Ferret7446 4y ago
Many of those things are a consequence of the language, or at least the philosophy behind the language. e.g., tooling is good because the language is easy to parse

jjice 4y ago

Wholely agree that Go tooling is fantastic, especially since most of it is bundled and directly supported by the language. Honestly my biggest gripe is nillability, but it really doesn't bite me nearly as much as it did in Java or C#. There's a reason it's sliding into the "boring and effective" (that's a good thing) camp of languages, but it's still got some cool factor.

tptacek 4y ago
Strong agree. Go isn't my favorite language, but it is my favorite programming tool.

makestuff 4y ago

Yeah I was at a startup where maybe 10% of engineering had used go before and 20% had used Java before (it was a PHP monolith so most people were PHP developers). The Java code that was written was pretty awful (I was hired probably due to my java experience, so I had a decent idea of good java). However, the Go services were actually really good. There is something about having a simple language that works really well for backend CRUD services.

nogridbag 4y ago
I think the main difference is there's just an order of magnitude more awful Java devs than Go developers due to Java being the most popular backend language for N years. If the timeline was flipped and Java was the new language on the block while Go had been around for 25 years, I bet you'd see the quality of Java code was vastly superior simply due to Java attracting passionate developers interested in learning new technology. I still see Java devs with 15-20 years "experience" coding like 1st year CS students. It really wouldn't matter what language they were coding in.
rob-olmos 4y ago
What sticks out most for the Java code being pretty awful? Was the PHP code just as awful too in similar aspects?
kaba0 4y ago
Go is not really an easier language than Java, though.
- throwaway894345 4y ago
  Back in 2012 I was considerably better-versed in Java (it was the main language for my CS education and a bunch of my hobby stuff). Still, I ended up picking Go because it was so much easier--no need to deal with Maven or Gradle or the alternatives, no need to pick a testing framework or a test runner, no need to configure CI jobs to publish documentation or source code packages, no need to run some external web server process, no need to worry about runtime dependencies (including the JVM itself), etc. No need to navigate an ecosystem (including stdlib) riddled with inheritance and other antipatterns, etc. No need to get a master's degree in tuning the JVM. Text editor plugins just worked. `gofmt` existed and was ubiquitous. The language itself was far smaller and it had native, idiomatic value types from inception!. Everything about Go was just so much easier than Java.

gw98 4y ago

Agree on all points. I'd like to add that it just tends to not punch you in the balls. I originally picked it up trying to solve a simple web hook integration problem. I had a Python Flask app running which received a webhook, did some data transformation and did a POST to an API. After spending a whole morning pissing around trying to get uWSGI, systemd via ansible etc working I went for lunch. Came back, learned enough Go and had it working in a single binary with systemd unit before the end of the day without any 3rd party packages, server mechanisms, dependency management, futzing. It just worked. The same code has been moved into docker, then into kubernetes over the last few years with no change, no bugs and no headaches.

alyandon 4y ago
Similar experiences with Go vs Java and Python. One thing that has stuck with me to this day was how quickly I was able to write a proxy to distribute keys consistently across a set of Redis servers to break out of a bottleneck in an internal processing pipeline.
traceroute66 4y ago
> I had a Python .... IMHO, the biggest win of Go over anything Python is the single distributable. You write once. Compile (or cross-compile) once. Distribute the binary. Job done. Python you've got the hell of dependencies. Write your script once, but then users have to endure pip hell for the hundreds of libraries you've depended on. And then the potential different dependencies between different Python stuff. Go is awesome for that and the Go stdlib has 80+% of what most people need.
- throwaway894345 4y ago
  Also, you can run that Go binary on any Linux system whereas with Python you'll be lucky if you can run on any non-Ubuntu/RHEL Linux system. Moreover, that Go binary will be like 10% of the size of a Python artifact (which amounts to significantly faster deployments and cold start times for things like Lambdas) and it will perform about 2-3 orders of magnitude faster than Python and there will be headroom to optimize (whereas with Python you're usually not going to eek much performance out beyond the naive implementation without substantially overhauling the architecture).

tech_tuna 4y ago

Go has been an acquired taste for me. I still don't love its syntax but the tooling and interesting combination of properties (GC, compiles to a binary, strongly typed) are what ultimately won me over. It's perfect for middleware, APIs and CLI tools.

KingOfCoders 4y ago

I currently write a SaaS website in Go after doing quite some Rust. I do prefer Rust as a language - it's more expresive and I greatly prefer Result<> over error, but it has two major downsides for me compared to Go. First compilation is much slower and Go feels like a non-compiled language because of the compilation speed (my last startup I've used Scala with horrendous compilation speeds, the main reason not to use it) The second is the borrow checker. It's excellent mostly (love explicit mut) but fails for me for structs with sub-structs coming from different owners. Very fast you have Arc<> noise everywhere. The Go GC just works. A simple GC as a -gc=on with auto-arc for variables without lifetime annotations for people that don't need Rust for embedded applications would be a dream come true. I do love 'import "embed"' in Go to embed web files (templates) inside a binary and then deploy/manage that one binary with systemd with zero downtime updates with systemd port activation. Slick.

TrustPatches 4y ago
Not sure if it’s an exact parallel, but you can also embed files into rust binaries with “include_bytes!” and “include_str!”.
- 5e92cb50239222b 4y ago
  It's a bit more advanced than what Rust macros provided last time I checked. You can shove whole directories in there and then traverse them or serve as static resources with pretty much one line of code. Random blog post with a few examples: https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/ https://blog.carlmjohnson.net/post/2021/how-to-use-go-embed/
  - TrustPatches 4y ago
    Very cool, I guess one the the advantages of rust macros is that you could write your own to do something more advanced in theory
  - super_flanker 4y ago
    You can do the same in Rust with include_dir[1] 1: https://docs.rs/include_dir/latest/include_dir/ https://docs.rs/include_dir/latest/include_dir/

nicolashahn 4y ago

Slight counterpoint - I have written Go in the past and now am working with Kotlin and to be honest, I prefer it. I wouldn't mind Kotlin being the new Java rather than Go.

za3faran 4y ago
Java is the new Java :) With features like records, virtual threads, pattern matching, sealed types, string templates, and more to come, it's shaping up very nicely.
- Xeoncross 4y ago
  The compile times and the fact it takes 10x the memory for a lot of services is certainly something I would like to see addressed. Not to mention that Java for things like serverless has painfully slow startup times. Java runs nice and quick when it's ready, but it's slow to get there and quite a memory hog.
  - kaba0 4y ago
    Compile times? Besides gradle’s startup time, java compiles just as fast as go imo. Go barely does any optimization, but javac does even less - so I don’t really see it a problem on actually similarly sized projects. Memory usage is a tradeoff — a good GC works best with a bit more overhead.
  - erik_seaberg 4y ago
    I want the compiler doing as much work as it possibly can. If they can somehow make the compiler faster, I guess that’s nice, but I don’t want to be saddled with a language that’s been compromised to move work from the computer back into 0.0001 MHz human brains.
- eweise 4y ago
  I tried the latest version of Java. Unfortunately, it still feels very clunky. They need to add the ability specify functions directly instead of as classes. ex: BiConsumer<T,U>

origin_path 4y ago

"Errors always get handled because the linter points them out and the devs don't cheat by setting up multi-function try/catch blocks" My experience with Go has been that errors get "handled" by propagating them up the stack manually and then logging them, without keeping proper track of how the error got there. So there is error handling but only in theory, in practice what you get is a sort of hand-written stack unwinding logic with far worse functionality and consistency than exceptions, at 100x the verbosity.

throwawaygal7 4y ago
In go, you either handle the error where it happens or close to it, or log it. No need to pass things up just to log. I like the simplicity, and the zero cost at runtime. If you could handle the error in another lang you could handle it in go, or youd just supress or log it anyway.
- erik_seaberg 4y ago
  In a microservice, almost all errors are handled by doing nothing and returning the error to the caller. Retrying may be an option, but you have to be careful not to make your system into a cascading failure amplifier.

kaba0 4y ago

Error handling is strictly worse than pretty much any other language out there — you are only making you believe that you are handling your error cases. A pragmatic “handle it here or bubble it up” is a much better approach, as more often than not you can’t actually handle the error at call site. Goroutines in themselves won’t give you actually correct concurrency. I really hope that Go doesn’t replace Java.

smasher164 4y ago
> A pragmatic “handle it here or bubble it up” is a much better approach This is exactly the approach used in Go code, so I'm not sure what you're referring to. If you're talking about the fact that you can technically ignore an error result like res, _ := doWork() then that's a fair point. But we still have https://staticcheck.io/docs/checks#SA4006 https://staticcheck.io/docs/checks#SA4006 for that.
- kaba0 4y ago
  I don’t see any automatic bubble up with Go.
  - smasher164 4y ago
    I don’t think the original commenter said anything about “automatic”. That’s more of a subjective decision—whether or not you manually bubble up an error, or it just floats up because of the exception handler. Empirically, java code has had terrible error handling, because people just stick one catch statement at the root of their program. Go atleast confronts you with the error at every step.
    - kaba0 4y ago
      And that is exactly the wrong approach. You really can’t do anything with the error case at most places. If I write a web server, which parts could knowingly handle a db connection error? Either the db driver internally, or going 10 deep higher and the request handler returning an 500 error. In go you would just verbosely (and error pronely!!) have to manually bubble it up, while this is automatically happening in Java with an informative stack trace, with no option to forget about it. Java is the one that handles error cases properly (and that’s why you might see exceptions more there — because they weren’t silenced somewhere wrongly!) here.

throwaway894345 4y ago

Not only that, but all of the features Go doesn't have means that you don't have to navigate the "which subset of the language does this project use?" problem. Every project uses pretty much the same language features. Similarly, the code formatter is universal and minimally configurable, so the code formatting looks the same across the ecosystem. Virtually everyone uses the same test runner too. Also, you get documentation (including links to third party and standard library packages!) for free--no need to set up a CI pipeline for publishing documentation packages. Same with package hosting--no need to set up a CI pipeline to publish packages. There's a ton of this kind of stuff that amounts to a whole lot of productivity that gets overlooked in all of the pennywise-pound-foolish type-system navel-gazing that programmers fixate on.

Xeoncross 4y ago
"Gofmt’s style is no one’s favorite, yet gofmt is everyone’s favorite" - https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s https://www.youtube.com/watch?v=PAAkCSZUG1c&t=8m43s
HillRat 4y ago
One of my mantras is "what you say no to is more important than what you say yes to," and the Go team says no to a lot. It can be frustrating and Go can be incredibly inexpressive (and, frankly, boring) compared to other languages, but it's hard to find another stack in which any random developer can be as productive as quickly on any random codebase. There are other languages where my personal velocity is a lot higher, but at a team level I haven't found anything that beats Go.

avgcorrection 4y ago

> I don't want it to win over Rust though, Rust is awesome. Why even perpetuate this red herring comparison—maybe over a decade old?—by making unprompted mentions of Rust though.

Ferret7446 4y ago

Many of those things are a consequence of the language, or at least the philosophy behind the language. e.g., tooling is good because the language is easy to parse