Go is not the tool of choice for experienced professional programmers for exactly this reason.

The ability to quickly refactor code is very important and Go fails at it horribly for a number of reasons. 1) sheer verbosity. 2) multiple return makes altering function signatures tedious. 3) no generics mean code is written in hard to refactor styles out of the box 4) poor reflection support 5) poor tooling compared to professional grade languages (Java/C#/etc)

I could go on but long story short it's not you, it's the tool.

These issues can be overcome by remaining vigilant but for the most part they are part of the accepted "cost" of Go.

Which is to mean you pay them in return for a language that is very easy to learn (albeit hard to master because of the above problems), has a great runtime and has reasonable out of the box performance and memory footprint and stellar compile times.

These tradeoffs can actually be right for some teams, i.e larger ones with less experienced engineers that can afford to spend more cycles doing busy work refactorings.

However it's often a poor fit for small teams trying to work on software that is evolving quickly and can benefit from features of more powerful languages.

that's really funny, because I always thought of Go as the language that programmers who were aging out flocked to because it has

1) google-cred

2) familiar algol syntax

3) close enough to C++ to make a run for it

4) (systems-wise) safe enough to make it worth it

5) hip enough that you don't seem like an aging out programmer anymore

(I myself am an aging out programmer, that ironically just got started, so take that as you will)

But my observation is from 5 years ago and things may have changed.

[citation needed]

i.e Go is relatively well suited for a simplistic web service. But even if I don't expect to need to extend it I would still prefer to write it in something that is more extension friendly than Go.

Therein lies the problem. Go actually isn't better than other tools at most things so if you don't actually have a tool of choice than Go is rarely the best choice assuming you are comfortable with a large range of tools.

Building a database? C++/Rust (arguably JVM) are better choices. Building a correctness critical piece of software? Rust/Haskell are likely better choices if this is your main constraint. Building a big data pipeline? JVM language of choice is probably the clear winner because of sheer ecosystem momentum. Building a large web application? JVM/C# are miles ahead of the competition here. Building a bunch of microservices? This is probably one case where Go actually does reasonably well, if you work hard architecturally to constraint to complexity of each service it can do OK here. Unfortunately, just OK. JVM/C# probably still beat it out here because of better tooling. Building a kernel? C/C++/Rust/D/Zig. GC is a non-starter. Building a browser? See above.

Once again, I could go on. Go can be used for lots of these but all of the tools above are better for each of these domains. So if you are an experienced professional with a wide array of languages at your disposal what are you going to pick Go for?

Think about successful tools use Go - they would have been a nightmare in some aspect in most other languages. Can you imagine Kubernetes in Java? Docker in Python? It shines where it shines for a reason.

Yes, I can, that is how it was originally prototyped and due to pressure of Go advocates on the team it got rewritten in Go.

However given that Go type system isn't as advanced as Java, the result wasn't the best one.

"The clusterfuck hidden in the Kubernetes code base"

https://archive.fosdem.org/2019/schedule/event/kubernetesclu...

"Fixing the Kubernetes clusterfuck"

https://fosdem.org/2020/schedule/event/kubernetes/

1) there are worse languages in that category. some are even more widely used.

2) that doesn't make sense. return arguments are part of the argument list signature. either changing any argument makes this tedious, or none does. you indicated that only return ones do for some reason.

3) can't argue there. in the rare occasion that type asserting interfaces is required because of lack of generics, things really do suck.

4) can you elaborate on that?

5) only thing i found lacking was absence of advanced refactoring tools. for everything else, the available tooling seems to be on part with what i've used with java (anecdotal)

- configurable sandboxing

- hot reloading

- AspectJ (cross-cutting code injection at link time or during classloading)

- JMX (extensible RPC API for metrics and administration)

- YourKit (interactive remote profiler wired in during classloading)

And one of the absolute dog's-breakfast worst to refactor regardless of editing environment. No statically typed language should be this hard to do basic changes in, and yet it exists.

Being writable in a "simple text editor" isn't a plus when the "simple text editors" in 2020 are IDEs with the name filed off.

The demanding static analysis and clear compiler errors actually make it easier and more robust to write unaided for me. Especially when it comes to refactoring -- it's essentially a process of resolving the compiler errors and you can be pretty confident you've arrived at a correct result.

Source: I write Rust everyday in a plain text editor without syntax highlighting.

As long as you never refactor anything.

> Rust is among the hardest due to its complexity and demanding static analysis

I have never wanted or needed to offload Rust's "demanding static analysis" to my text editor. Rust's linearity/lifetime type system is really quite simple - it's not like you have to keep track of long-distance lifetime relationships in your head.

Even a reasonably powerful type system with e.g. HKTs, arithmetic, etc. like Haskell's rarely benefits from external tooling, and any interactivity can often be just as easily done via a polling build tool like ghcid rather than integrating it into a text editor.

The one place where it strikes me as sane to have a "smart" text editor is if you're using a proof assistant-style language like Coq/Idris/Isabelle/Liquid Haskell/etc. where there's actually a non-trivial amount of interactivity required while writing the code.

I cut my teeth in the 90s with C, and have professionally used PHP, Python, Java, C#, Javascript (both server and client side), and have been using Go as my main choice for the past 4 years. I've worked on teams as small as 1 up to teams in the hundreds, both as an individual contributor and tech lead. I say all that because I would consider myself an "experienced programmer". I am mostly writing APIs for web and mobile apps to communicate with, although I have written code in a wide variety of contexts. I say all of that because I can't imagine going back to Java or Python. I even migrated a bunch of my services from Typescript to Go because I found Go to be far more productive and easier to work with. Refactoring as always been easy. At my current job as a Chief Software Architect, I have over 25,000 lines of code in production running Go. I say all of that to provide background and context on my humble opinions.

1) Verbosity is among the leanest I have seen for a type-safe language. Compared to Java or C#, it is much more like Python. Perhaps the most verbose sections are a repetition of "if err != nil" blocks, but those are there for a reason and I explicitly prefer that over long "try catch" blocks.

2) Not sure what you are arguing here. If you are talking about functions returning multiple values, many languages do that. If you really don't want to, return a struct or a map. Or choose to not return multiple values. That is a choice of the programmer, if I understand you correctly. You could also use any of the major editors (I prefer VS Code) to refactor; the tooling is awesome (see #5)

3) Maybe it is due to the nature of what I do, but I have never once thought "man, I wish I had generics for this." I am sure there are some who genuinely need it, but I haven't run across that in my own experiences. I find that structs and interfaces have been everything I needed there, but again, my use case is on the server.

4) I haven't needed to use reflection either, so I have no comment here.

5) Hard disagree. GoLand (by Jetbrains) and VSCode are INCREDIBLY powerful. I will never go back to Eclipse or Visual Studio if I can avoid it. Go ships with tons of tools (formatters, linters, vetters, etc) and integrate with a ton of others (delve, etc). So your statement simply isn't true.

Your last statement is probably what drove my response. I was able to spin up a full API server incredibly quickly alone, and then with one other person, in a fresh startup with minimal issues. Rules and requirements were changing daily, so the code and business logic had to change. I can't imagine having to do that kind of work in Java (don't get me started on the deployment story here...). I would argue Go is a great fit for small teams. It is a small language with opinions, so programmers can focus on their use case.

Go isn't perfect, but it's my tool of choice. That's my two cents though.

1) This is hit and miss for me. I have to read Go code frequently: not every day or even week, and sometimes under incident pressure. It's less verbose than Java/C#/JavaScript, more verbose than Python/Ruby/Scala. But it's sufficiently verbose to require, for me, cognitive discipline to not skim (ie, "I've been skimming, need to go back up" awareness). So when I'm reading go I put my Java/C#/JavaScript hat on not my Python/Ruby/Scala hat. Not a big problem, but it was so, so close to being in the latter camp. For me then, its regularity claims are something of a wash such that I'd like to see some supporting empirical data or summation of anecdote that it does in fact optimise well here and make good engineering tradeoffs.

2) The problem (I think) is being being to skip by the returned values. It's better than return codes in C, but you're not absolutely required to handle them. I suspect trying to patch structured returns onto an algol-like is a dead end, and if we want structured returns, we want to use a language that really induces us to 'process it forward' eg via map/flatmap/case handling, rather than adding ceremony around if. I think Go made sensible and realistic choices here.

3) Lack of generics are a pain, but a pain for writers. Go does not optimise for that concern, except afaict for its core language creators who have escape valves. The conspiracy theorist in me says Go was wait and see on generics (and exceptions, and objects) as a function of when it was incepted, and may now reasonably conclude that generics are here to stay so the language will need to solve for them, but objects and exceptions were good holds. ie, I don't completely buy it required a decade to figure it out, but could buy it took a decade to observe generics are not going away.

4) In Go, this seems to be satisfied by codegen and templated YAML. I wonder if this is generational, in that the need for reflection might be lessened because of how work on cloud/virtualised systems happens (networked services handling data in and out, with regular deployments).

5) Agree. GoLand I find a great tool for reading and delving into programs, and VSCode is a fantastic 'every day carry' for code.

Edit: C# is actually quite expressive too, I have a hard time believing Go is less verbose than C#.

That said right now I get little opportunity to use it because it doesn't fit into the current ecosystems I am working in. Shame because it really is a joy to program in, tooling is excellent async programming in C# -just works- which isn't the case in Rust, Java (or Kotlin) or anything comparable.

So while I don't get to use it often I hold C# in high regard.

1) I don't think Go is in the Java (pre 8) realm of verbosity, but I concede it's not as compact as say Python. 2) Technically you can write single return Go but idiomatic Go leans towards immutability so it's not recommended. 3) I've run into the lack of generics a few times, but personally haven't been too hampered by it. This is an entirely valid complaint, hopefully support will be added soon! 4) Some would argue this is a feature. ;) 5) This was more true a few years ago. Now with Go Modules for package management and VSCode + Go extension with full debugger freely available, tooling is much improved.

It's so silly for example that math.Min/Max only works on float64, it won't work with float32 without casting, or integers (although for ints is highly discouraged, because casting to float could cause you to get a different number, it is encouraged to just do if statement yourself)

It is a horrible language, only popular because it came from Google. It's biggest benefit was that it supposed to be easy to pick up, but it also demonstrates that the simplicity doesn't help at all with a significant code base, you still have to spend the same amount of time to learn it as in any other language.

My experience with software engineering went from "the language (type system, grammar, syntax, etc) is super important!" to "the language is one of the least important considerations in choosing a language". The more important features are tooling and ecosystem.

I don't want to have to learn a new configuration language or imperative DSL just to add project dependencies or setup tests. I don't want to have to learn yet another documentation framework for generating documentation from code comments. I don't want to have to spend lots of time setting up CI/CD pipelines to build my source code and documentation packages and publish them to their respective repositories. I don't want to have to worry about whether my users or fellow developers have the right versions of dependencies or the runtime installed on their system. I don't want to have to make unmaintainable Dockerfiles because it's the only way to have performant builds in the happy path. I want to minimize time wasted during code review on comments about style or programming paradigms. Similarly I don't want to waste time waiting for code to compile.

If the language is type safe in 95% of cases, that's good enough--people still make lots of money writing lots of 100% untyped JS and Python and Clojure and so on--the extra 5% would be nice to have but I'm not going to trade tooling, ecosystem, and developer velocity for it.

Basically, as I become more experienced, I begin to understand the difference between programming and software engineering (my heart is in programming, but software engineering pays the bills). Go is a great language for software engineering, but most of its criticism seems to be directed at programming concerns.

Is it though? While tests in go are not terrible, to be a truly effective software engineer (vs just a programmer or dev) you want a very good test and documentation story, and there are languages out there with far, far, better tests and documentation primitives than Go.

Further, I contend that Go has excellent documentation primitives, notably that it doesn't have any sort of markup or documentation package management. I've never seen a better language in this regard.

Similarly, with documentation, I really like that the godoc toolchain has resisted all the markup and annotation syntaxes that you see in Java. And I like that Go's convention of using a public URL as the module import path helps enable sites like godoc.org.

I find the language itself slightly more than mediocre. But I really like the toolchain and the restraint of the maintainers.

Docs for elixir are pretty, too: here's a library that I wrote. The doc system is extensible enough that I could patch in docstrings from another language and also hyperlink (the </> buttons link to github) the GitHub code across languages (the `zig structs` section in the sidebar is autogenerated by parsing zig code) https://hexdocs.pm/zigler/Zigler.html

My joke is that you want to write documentation that's pretty and html-responsive enough that you can read it on the can between coding sprints.

I agree Go makes things more difficult to mock, but it's also the language I've used where it's easiest to avoid mocks and test the real thing. We have tests for REST and RPC services that... just make a service. There's relatively little boilerplate to make a gRPC or HTTP service with some basic expectations/fake data attached and just run your real client against that real fake server. ("Relatively" meaning, less than the equivalent mocks in Java, for a substantially more realistic test outcome.) And once you have this fake server, it's probably useful in multiple projects, while mock setup tends to be suite- or even case-specific.

The more I work in JS the more I realized that I'm dumb. I'm not worthy to hold the power that JS has, much more other more complicated languages.

I tried Go. I like it. It makes me feel safe and smart enough to write production grade app.

Small docs, small language, no need fancy IDE, just any regular text editor like Vim works. Easy to read, easy to reason about. Everything is easy.

Now I finally can focus on other non-programming passion instead of chasing endless language features in other programming languages.

I like Go. The language for mediocre SWE like me. I code, I go home, I enjoy life.

I think this is really the best feature of Go. It's a pragmatic language. The only complain I have is the incomplete/half backed reflect package.

We were....not fans. We were already in the habit of writing extremely clean and healthy code[1], and having a language hand-holding and hectoring us into doing things in its narrow, specific way was just too much of a hit to productivity. Now that I work in a C++ codebase full of very smart domain experts but light on engineering expertise, I can appreciate Go's value in certain circumstances, but if you're lucky enough to work with a talented and experienced engineering team, Go is a pain in the ass for anything but beginners.

[1] A habit I'm paradoxically trying to unlearn a little at my newer company, due to being on a different point on the short-term velocity/long-term health spectrum

I mean, I don't typically prototype or iterate on ideas in Typescript, either; I do that in Javascript, and reserve strong typing for when I know what I need to build, and it's just a matter of doing so in a way that's reliable, maintainable, and secure.

The point is that flexibility and strictness both have value, and it's more worth knowing which is more useful at a given point in a project's lifespan than trying to be dogmatic about one or the other.

As a user of Go and Ruby I can tell you that: Ruby is an awesome language, and there's nothing else that beats it at getting things done quickly and painlessly (unless you have a mathematical mindset, in which case nothing gets shorter and more elegant (at least the day you write it) than functional programming). It has many other defects, like safety in larger codebases, speed, some weird quirks, etc., but it's an awesome language, don't expect many other languages to be less painful than Ruby (on small programs at least).

Don't listen to those that say professional programmers won't use Go. The only reason a professional programmer will say hard no to Go is for extremely optimized or mission critical code that can't tolerate garbage collection (even though the GC in Go is very low latency) or need a more sophisticated type system, or numerical applications for which Go isn't really well suited.

If you compare Ruby and Python to Go, the transition might be hard if you haven't studied computer science formally. That said, it's a matter of making the switch, understanding that all those objects (boxes to put data in) that you had in Ruby, now are statically typed; this means that a box is of exactly one type and can't change midway (and even subtle changes need explicit casting/conversion). You also need to learn the difference between composition and inheritance, which might be tricky depending on how you learned to program... but beyond that, Go is a very small and easy-to-write-code-in language. You might like the syntax more or less, but it's easy to write good code in Go. It has many other gotchas and hoops you will need to jump through (var initialization, error handling, new vs make, weird append/len, learn to printf, learn pointers, etc), but it's a good step after Ruby / Python, if you need things bigger than what Ruby / Python allow you to comfortably manage.

A hello world might require defining a package, importing another package, and a more verbose print statement than python / ruby, but those are all great (and minimal) appliances when developing at a larger scale.

Sure, you can’t move quite as fast in go as you can in ruby, but you also get the benefit of not having to deal with errors like “undefined method foo for nil:NilClass” in production, which is nice.

Things like lack of generics and type system makes you repeat things quite a lot (e. g. It was pretty impossible to write a true ORM or a DI system in go). I found the interface system quite awkward in that types implicitly implement an interface if they have the same method signature was weird to me. I think method overloading wasn't supported either, if I remember correctly.

I think people who loved Go initially probably came from C. It feels a lot like C with better standard library, memory safety and fast compile times. I like Go for the same reasons actually. But until there's at least some way to write generic code, it's an awkward language to anyone coming from more expressive languages. I program in C# mostly which is an extremely expressive language with classes, interfaces, generics, expression trees, linq, delegates (akin to function pointers). Go is far behind other languages for application development, my two cents. But for systems programmers used to C which is a very small language, Go must be like a transition to paradise :)

The build time of C++ can be really long. I noticed it too.

I'd say, invest your time wisely. Things are changing rapidly and old languages are usually solving problems that are not quite as important anymore as they used to be.

Im thinking of may be Rust or Go right now for more pragmatic reasons. Thank you for sharing your opinion.

A lot of the compiler errors really could be errors in pre-commit hooks (like, the one about unused variables), but the language designers made a trade-off to be Even More Opinionated (than, say, Rails) because they thought it was best from a pedagogical perspective.

Sometimes with the right approach (mapping PostgreSQL calls 1:1) and right tooling (uvloop, Cython) you can write code in Python and still squeeze better performance than in Go[1], but you need to know what you're doing.

If you want to explore types, these resources[2][3] were useful for me.

[1] https://github.com/MagicStack/asyncpg

[2] https://mypy.readthedocs.io/en/stable/

[3] https://docs.python.org/3/library/typing.htm

That's fine, in most cases, writing python code, you find out that you fucked up when you run the script. Compiler errors catch whole classes of errors that you ordinarily wouldn't find unless you ran the code.

I should add that it’s heartening Pike actually acknowledges this in the interview, regarding limited typing and how it helps playfulness in languages like Python and Ruby.

Ha. Try Rust if you like a challenge: at least you will get outstanding compiler diagnostics while refactoring, and far better performance as an end result.

It's difficult, but fair. I can not praise enough the software developers that realize proper errors are vastly superior to extensive docs.

When I started with Go I thought it was awesome. As my projects grew I found them to become less maintainable than my previous Java projects, and still less maintainable than my newer Rust projects.