5 ms·

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

by jpgvm 7y ago

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) 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.

nappy-doo 7y ago
use a better editor. VSCode, vim with vimgo, emacs with whatever those apes use.
- jpgvm 7y ago
  This helps but doesn't solve the core issues. I generally use Goland whenever editing Go code (as I am currently doing sigh) but even with such a powerful IDE the language is the main limiting factor in carrying out refactorings (which again, I'm doing right now).
  - dlsniper 7y ago
    What kind of refactorings would you like to do but GoLand doesn't help with? I'd be interested in that kind of feedback. Thank you!
- centimeter 7y ago
  I shouldn't need an industrial-strength editing engine to efficiently express my ideas. (And don't, if I'm using a nice expressive language.)
  - nappy-doo 7y ago
    ever written Java?
  - throwaway894345 7y ago
    Generally speaking, Go is one of the easiest languages to write with a simple text editor. Rust is among the hardest due to its complexity and demanding static analysis. This isn't a bad thing, and tools like rust-analyzer make writing Rust a lot easier. But rust-analyzer is amazing technology from the future; hardly an ordinary text editor plugin.
    - eropple 7y ago
      > Generally speaking, Go is one of the easiest languages to write with a simple text editor. 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.
    - centimeter 7y ago
      > Go is one of the easiest languages to write with a simple text editor. 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.
tyrankh 7y ago
> Go is not the tool of choice for experienced professional programmers wut
dvirsky 7y ago
> Go is not the tool of choice for experienced professional programmers [citation needed]
- Insanity 7y ago
  it's turning into a bit of a theme by people not used to Go to claim this I guess..
  - dvirsky 7y ago
    In general good "experienced professional programmers" don't have one "tool of choice" but their tool of choice varies by what they're doing. I would choose Go for a lot of things, but not for everything.
    - jpgvm 7y ago
      Whilst I generally agree with this it's definitely the case that experience leads you to prefer certain tools over others even when they may both be usable for a specific task. 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?
dnautics 7y ago
> Go is not the tool of choice for experienced professional programmers for exactly this reason. 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.
- cy_hauser 7y ago
  I had always thought the same thing about high use by aging out coders. Don't know how representative it is but the just released Go annual survey results seem to show that isn't the case.
  - pjmlp 7y ago
    We are busy keeping Java, .NET and C++ codebases running.
- pjmlp 7y ago
  3) Would be true when comparing with pre-C++98, back when C++ compilers shipped pre-processor based macros for writing generic code, and used something like TObject as interface{}.
hashamali 7y ago
Hm, not sure I agree with some of those criticisms: 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.
losingthefight 7y ago
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.
saturn_vk 7y ago
> 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) 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)
- erik_seaberg 7y ago
  On tooling, Go doesn't seem to have anything like Java's - 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)

by jpgvm 7y ago

nappy-doo 7y ago

use a better editor. VSCode, vim with vimgo, emacs with whatever those apes use.

jpgvm 7y ago
This helps but doesn't solve the core issues. I generally use Goland whenever editing Go code (as I am currently doing sigh) but even with such a powerful IDE the language is the main limiting factor in carrying out refactorings (which again, I'm doing right now).
- dlsniper 7y ago
  What kind of refactorings would you like to do but GoLand doesn't help with? I'd be interested in that kind of feedback. Thank you!
centimeter 7y ago
I shouldn't need an industrial-strength editing engine to efficiently express my ideas. (And don't, if I'm using a nice expressive language.)
- nappy-doo 7y ago
  ever written Java?
- throwaway894345 7y ago
  Generally speaking, Go is one of the easiest languages to write with a simple text editor. Rust is among the hardest due to its complexity and demanding static analysis. This isn't a bad thing, and tools like rust-analyzer make writing Rust a lot easier. But rust-analyzer is amazing technology from the future; hardly an ordinary text editor plugin.
  - eropple 7y ago
    > Generally speaking, Go is one of the easiest languages to write with a simple text editor. 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.
  - centimeter 7y ago
    > Go is one of the easiest languages to write with a simple text editor. 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.

tyrankh 7y ago

> Go is not the tool of choice for experienced professional programmers wut

dvirsky 7y ago

> Go is not the tool of choice for experienced professional programmers [citation needed]

Insanity 7y ago
it's turning into a bit of a theme by people not used to Go to claim this I guess..
- dvirsky 7y ago
  In general good "experienced professional programmers" don't have one "tool of choice" but their tool of choice varies by what they're doing. I would choose Go for a lot of things, but not for everything.
  - jpgvm 7y ago
    Whilst I generally agree with this it's definitely the case that experience leads you to prefer certain tools over others even when they may both be usable for a specific task. 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?

dnautics 7y ago

> Go is not the tool of choice for experienced professional programmers for exactly this reason. 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.

cy_hauser 7y ago
I had always thought the same thing about high use by aging out coders. Don't know how representative it is but the just released Go annual survey results seem to show that isn't the case.
- pjmlp 7y ago
  We are busy keeping Java, .NET and C++ codebases running.
pjmlp 7y ago
3) Would be true when comparing with pre-C++98, back when C++ compilers shipped pre-processor based macros for writing generic code, and used something like TObject as interface{}.

hashamali 7y ago

Hm, not sure I agree with some of those criticisms: 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.

losingthefight 7y ago

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.

saturn_vk 7y ago

> 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) 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)

erik_seaberg 7y ago
On tooling, Go doesn't seem to have anything like Java's - 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)