Go is the language that made me realize I’m not much of a production quality software engineer. Normally I would be quite happy riffing with ideas in Ruby or Python, and just running my code and iterating trying to figure out what to do. When I tried this in Go, every time I wanted to change the shape of my code to try doing things slightly differently I had to do a lot of work to get the code to compile again. I fee…
This isn't true at all. 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) po…
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.