|
I am going to disagree pretty heavily with this. You don't give any explanations, evidence, or mention your experience, so let me lead with mine before I explain where I think you are wrong. 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.