30 ms·

Why Go is my favorite programming language

242 points by secure 9y ago

pjmlp 9y ago
I think regardless of how each one of us sees Go, its adoption among DevOps (Docker, K8s), Apple and Microsoft means that just like with C and JavaScript it will become unavoidable to use it for certain tasks.
- romanovcode 9y ago
  Too bad
  - deleted 9y ago
    [deleted]
- coldtea 9y ago
  Adoption from Apple? If you mean on their internal services, then that's irrelevant as to the rest of us "having to use it".
  - pjmlp 9y ago
    They have quite a few open positions asking for Go knowledge. No idea how they are using it.
    - coldtea 9y ago
      Yes, I meant it's not like Apple is forcing it on external developers though, like e.g. they "force" Swift. Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC.
      - pjmlp 9y ago
        > Yes, I meant it's not like Apple is forcing it on external developers though, like e.g. they "force" Swift. Sure, but at the same time it creates awareness in other companies that Go is a good bet that they might adopt as well. > Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC. They went with Kotlin. Dart is still looking for a killer application beyond supporting AdWords, lets see how far they go with Flutter or Fuchsia.
- nindalf 9y ago
  I'm not sure that I follow. To me, it sounds like someone saying we need to program in C because we use git whereas we actually interact with git through the interface they've given us, not through its source code. Even if Docker and K8s become ubiquitous, I see no reason programmers taking advantage of these to also program in Go.
  - pjmlp 9y ago
    It means that anyone that is working on DevOps, while having Docker/K8s on their employer infrastructure, might eventually be asked to write Go for whatever reason. Given that they are written in Go, and as far as I understand it, the way to customize them also requires using Go.
empressplay 9y ago
I love Go! It houses us and puts food in our mouths. It also powers our side projects. Go is awesome!
- thesmallestcat 9y ago
  It literally houses you and puts food in your mouth? I'd like to see that.
  - swah 9y ago
    Maybe they* live inside the O? Confusing.
    - empressplay 9y ago
      She =) But thanks for your sexist assumptions! They're awesome!
      - bauerd 9y ago
        Did you just assume personhood? You might be responding to a Markov chain for all we know.
        empressplay 9y ago
        Are you saying Markov chains can't be sexist?
        coldtea 9y ago
        Seeing that they are mere algorithms, yes. Being X implies intention. At best they can accidentally put out something sexist as a result of their input.
      - nolok 9y ago
        That comment has got to be a joke... Right?
wasted_intel 9y ago
The "easy to learn" argument is getting old. If the cognitive load never decreases, that's one thing, but initial ramp-up time shouldn't be a large determining factor. The MVC pattern, ADTs, functional programming, and so many other useful concepts were foreign at first, but have a substantial impact on how you think and work. With the exception of channels, Go doesn't add much when compared to other languages. Maybe that's a pragmatic choice, but it feels short-sighted to me.
- webscalist 9y ago
  Huge success of mongodb was due to "easy to learn" advertisement, paired with getting shit done and rewrite later agile trend, and web scale.
  - eeZah7Ux 9y ago
    Is this a positive or negative example?
- emperorcezar 9y ago
  Sadly our entire industry is based around being short sighted. Quick to learn is only important if you have the lack of patience to spend the time to learn something you'll be using for years.
  - holydude 9y ago
    Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller ones. The IT industry simply forces you to re-learn the same old paradigms in a new package just to gain 0.1% of something we cannot even define as an improvement.
    - pjmlp 9y ago
      Quite common in fashion driven industries.
    - 9y ago
sandGorgon 9y ago
I'm kind of wondering about why is there no production ready JavaScript/TS to exe compiler that packages all dependencies and creates a single executable - like go. With the amount of mind share that js ecosystem has, I thought that would be a thing. The keyword being "all dependencies"
- mlcdf 9y ago
  Something like https://github.com/zeit/pkg https://github.com/zeit/pkg ?
  - sandGorgon 9y ago
    very cool! is this production ready ?
- styfle 9y ago
  A couple more: https://github.com/nexe/nexe https://github.com/nexe/nexe https://github.com/pmq20/node-compiler https://github.com/pmq20/node-compiler
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
kasey_junk 9y ago
If I were to build a list of the reasons I use go, it wouldn't be terribly different than this one. But interestingly, while I program go every day, I sort of hate it as a language. You'll note this list doesn't actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages). So for future language designers (or existing language designers that want to increase the popularity of their language) it seems like things like language ergonomics, power, etc are less important than having a standard batteries included development stack coupled with out of the box "good enough" performance.
- secure 9y ago
  I noticed as well that I didn’t mention a single language feature, even though I do actually like many :). I agree with the sentiment you expressed: the overall experience when using a language matters to me much more than individual language pros or cons.
- cyphar 9y ago
  > But interestingly, while I program go every day, I sort of hate it as a language. I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).
  - fetchfetch 9y ago
    After having coded tens of thousands of lines in Golang for 4 years, there are a list of probably hundreds of grievances I have about the language itself. The problem is that they're generally outweighed by the simplicity, consistency, and clarity of the language. Is the error system terrible? Obviously. Lack of abstract data types? Awful. Is Rust one thousand fold safer and more syntactically powerful by comparison? Sure. But the fact is, in a world where we as developers often are learning and working in a new language every year or two, time-to-productivity and proficiency in a given language is one of the most important, if not the most important, metrics for a language. And Golang knocks this out of the park with its obvious syntax and great tooling. You can bring in a new junior programmer onto your Golang stack and have then turning out useful pull requests in a week or two, which I can't say for languages like Rust. I _hate_ much of Golang's engineering, but for collaborative programming I think anyone would agree that it's a highly productive language.
steinuil 9y ago
I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this. That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.
- lanestp 9y ago
  Does someone want to give a reason for down voting this comment? There isn’t anything controversial here. For myself, lack of genetics are enough reason not to use the language. My personal style relies a lot on them and I don’t see myself sacrificing that power for above average tooling.
  - reificator 9y ago
    > For myself, lack of genetics are enough reason not to use the language. The typo/autocorrect here turns this into a much more controversial statement...
- deleted 9y ago
  [deleted]
- int08h 9y ago
  Re: getting tooling "right" and that driving adoption/popularity. I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings. However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.
  - steinuil 9y ago
    Yes, my impression is that Go was created partly to be used in corporate environments to replace Java with a less verbose language that scaled well, and it seems to be doing well in that regard.
krylon 9y ago
I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works. One point the article does not mention is the documentation. I think Go's documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the documentation that comes along with the development tools. Also, there are some pretty neat static analysis tools for Go out there, and since they are mostly developed in a development-environment-agnostic way, they tend to be usable from a relatively wide range of editors and IDEs. But even just using go vet and golint regularly goes a long way to rooting out all those tiny but tedious bugs and ensure a degree of consistency in naming conventions. I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores, but the fact that my code is laid out in the same way as that of third-party libraries means it is surprisingly easy to dive into somebody else's code and make sense of it. The fact the Go community tends to favor simplicity over brevity can get annoying at times, but when you have to read somebody else's code to figure out if it's buggy or you're using it wrong, it is priceless. There a many things Go could do better (or at all), but if there is no way to implement some feature without sacrificing simplicity, I prefer simplicity. I you want C++, as the saying goes, we know where to find it. ;-) (I'll admit though that the C# designers have done an impressive job at adding lots of features without the language collapsing under its own weight. So it's not like it's impossible.)
- pavlov 9y ago
  I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscore My taste is the opposite: I can't understand underscores in identifiers, it's like having hiccups inside every thought. But what saddens me is that we're still having this conversation in 2017. It would be trivial for editors to support either style, if only language designs included the concept of word separator inside identifiers, which could then be rendered at display/edit-time according to user preference. Somehow programming languages are extremely resistant to these kinds of improvements. ColorFORTH is the only example that comes to mind of a language designed beyond ASCII.
  - 9y ago
squeeeeeeeeeee 9y ago
I haven't looked at Go yet, but all these "is so easy to learn" and "generics are bad because they're not easy to learn" articles on HN, I have to wonder if this language is really so great or people push it because of the politics of people making it.
- secure 9y ago
  Only one way to find out… learn some Go? :) As author of this article, I can only say that I wrote about Go because I honestly like it, not because I have any agenda.
  - weberc2 9y ago
    It will take all of 2 hours tops to go from zero to writing an interesting program.
- weberc2 9y ago
  While I do like that Go is ready to learn, I like that it is small enough to hold in my head. Pretty much everything works intuitively, save for a couple surprises. The same goes for its tooling. There is no complex project or package tooling to learn either. That said, it doesn't have a passable story for sum types or generics, which are important for the kind of programs I write these days. I'm convinced that summertime could build something as simple as Go, but with better abstraction facilities. Ideally this language would look like Rust and compile to Go.
  - kuschku 9y ago
    > There is no complex project or package tooling to learn either. Question, how do you handle dependencies without them ending up checked in in your git? I’ve had no success yet with go and dependencies, there’s no simple way like in the Java world to just define a list of dependencies and have the built tool automatically fetch them in some dotfolder, and take care of the rest, is there?
    - 9y ago
jernfrost 9y ago
Wow this is extemely close to my own reasons for having a preference for Go. Very well articulated. The clarity of Go code can not be empasized enough. To be fair my favourite languages are Julia and Swift but that neither can really math Go in clarity and simplity.
chris_st 9y ago
I've been using Go for a while, and am frankly amazed at the quality of the tooling. I'll add something others haven't mentioned... the profiler produces an absolutely amazing graph of the run-time call tree[0]. This makes it incredibly easy to not only see where the code is spending its time, I can easily the context, and where else time is being spent. I recently sped some code up (5x!) using this. 0: https://blog.golang.org/profiling-go-programs https://blog.golang.org/profiling-go-programs
nnd 9y ago
What would convince an avid Python user to switch to Go st this point? Let’s narrow down the scope to an API backend to be more specific (isn’t that’s where Go’s performance thrives?)
- fetchfetch 9y ago
  - Real concurrency without having to deal with spawning multiple programs that communicate over some higher level process - Good concurrency primitive (channel), although asyncio Futures in Py3 aren't that bad either - Strong typing - Easy byte-level manipulation - Extremely easy to learn - Simplistic error handling compared to exceptions (there are problems with this I won't go into, but it's easy to learn at least) - Amazing tooling (gofmt forces your codebase to be consistent regardless of who is writing it)
- eadmund 9y ago
  I was an avid Python user for roughly a decade, and I switched to Go. IME, writing it feels a lot like writing Python, but I feel much more confident that the code I write will run the way I expect.
- luord 9y ago
  Python is my favorite language and I really liked Go as I read about it. When time came to actually learn and use it, I was... Disappointed. Sticking with python still, for the time being.
ausjke 9y ago
Just use modern C++
- andreasgonewild 9y ago
  Couldn't agree more, a much better investment of anyones time. C++ won't suddenly refuse to solve your problems because they don't fit into an arbitrarily limited view of the world. And some of the stuff coming out of standardization lately is simply awesome.
  - _binder 9y ago
    Can you share some of it. Trying to get better at C++ here.
    - andreasgonewild 9y ago
      Sure thing. Bear in mind that this is my way of doing it; plenty of people will yell blasphemy at the choices I make, and some may well turn out to be suboptimal without 32 years of experience to back them up. https://github.com/andreas-gone-wild/snackis https://github.com/andreas-gone-wild/snackis
- theshrike79 9y ago
  I would, but package management for C & C++ is still in the same shape it was 25 years ago - nonexistent.
pmoriarty 9y ago
When Java was first introduced, the world was abuzz about this cool new language which you could "write once, run anywhere". It took some time, but as it grew in popularity, articles started appearing about how much Java sucked because it was slow and bloated, required a ton of boilerplate code, and eventually because "write once, run anywhere" turned out to be a myth, along with a boatload of other reasons. The honeymoon wore off, and legions of Java-haters were born. Perl suffered a similar fate. When it came out unix was just surging in popularity with the internet boom and a lot of people were thrilled to have a single language you could learn which combined the features of common command-line tools like sed and awk, and that was a "real programming language" that was more powerful than shell scripting, and which grew to have a ton of useful libraries in the form of CPAN. Years later, and Python and Ruby started getting popular, the "Perl sucks!" mantra sprang up and the once-mighty Perl shrank before the upstarts. Ruby and Python are getting their turn now, and I'm starting to see some people expressing hate towards them as well, though it hasn't quite reached the pervasiveness of Java and Perl hate yet. Go was next. People were excited about this cool new language from Google, a place filled with great engineers, and from the mind of Rob Pike, of Unix and Plan 9 fame. It was supposed to be like a simpler and more elegant form of C. What's not to like. Well, the replies to this post are showing that for some the honeymoon is already over. Other languages had their day in the limelight, only to wind up being hated: C++, Lisp, Fortran, Cobol, HTML, Javascript. Bjarne Stroustrup observed that "there are two types of languages, the ones everyone complains about, and the ones nobody uses." Whenever some shiny new language comes out, promising to solve everyone's problems in some domain, and people start jumping on the bandwagon and singing its praises to high heaven (which seems to happen ever couple of years), I try to take a deep breath and step back. There will likely come a day, before too long, when they too will be subject to hatred and scorn, just as all the other popular languages before them.
- wyager 9y ago
  > "there are two types of languages, the ones everyone complains about, and the ones nobody uses" Of course Bjarne would say that. The reality is, there are some languages that people use a lot and don't complain about nearly as much. Some languages are just actually worse to use. http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...
gmoes 9y ago
I know a guy who used to teach Haskell at a university who now runs a development shop at a startup that uses Go. From I recall his main reason for choosing it was to hire cheaper less experienced developers. I remember talking to him about Go and he remarked something like: If you want to clean modular code don’t use Go. Not to disparage less experienced developers but I think teams of developers of any experience level need to have code governance and oversight regardless of the technologies and that a good team with good practices can create good code bases even with more complex and expressive languages. I know another colleague who did this with Scala and was able to properly mentor more junior developers by leading by example. I have not used Go. I have done and lot of Java and a bit of Scala and have many times leveraged generics to create a very high degree of reuse. Without them clearly you get a lot of boilerplate code which makes a codebase larger which leads to another type of complexity in my opinion. So the question is which scenario increases your codebase complexity and that probably boils down to what domain you are developing in. I explore some ideas relating to that tradeoff here [0]. Go has a specific use case that it targets which I believe is services and certain aspects of concurrency. Clearly the Go language and environment have value in the industry, however, as a language it offers little for people who want to have an opportunity grow and learn about more advanced concepts wrt to PLT and CS in general. I have a friend who is a Go fanatic and I try to encourage her to push her limits, but she feels and she can bang out service level code very quickly and she can as she is quite talented. Of course you can do that with Spring Boot as well. Regardless of your language you should always be trying to grow as a developer otherwise you risk becoming obsolete. To put it bluntly and I may get downvoted for this I feel Go is the “Rise of the Expert Beginner Language”. [1] [0] http://www.elegantcoding.com/2012/02/software-reuse-complexity-curve.html http://www.elegantcoding.com/2012/02/software-reuse-complexi... [1] https://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://www.daedtech.com/how-developers-stop-learning-rise-o...
- solidsnack9000 9y ago
  "The Rise of the Expert Beginner" was a great read. I do see the parallels to the tone and tenor of some arguments in favor of Go. One thing I wonder about is a seeming complementary anti-pattern, the "Expert Only Language". Perhaps C++ is the only language that truly fits this description, but one can see shades of it in Haskell, Scala & Rust. To a limited degree, Bash and SQL exhibit similar qualities, because people can use them for years but barely know them. These are languages where a certain confusing richness is accepted as the cost of doing business, and where a long period of familiarization is assumed to be necessary before doing basic things.
KirinDave 9y ago
> There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times. Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs. And so it's so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. "The repetition is simple," they reply, "and of course abstractions have cost." So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it's so tempting to start pattern matching the whole block of code and miss these subtleties. This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes. Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible. As such, it is quick to learn the syntax. It's not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library. I just don't understand why anyone appreciated go's design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don't think very much of and have no desire to train.
- treehau5 9y ago
  As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." After a decade of OOP indoctrination and misuse, we see the results of this. > Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.
  - 9y ago
DinoDano 9y ago
Its the best, but I'm sad and shamed it is owned by google.
- _binder 9y ago
  Why are you sad? It is backed up by on the biggest Software companies in the world and the amount of free stuff Google is throwing around is mind boggling.
  - kuschku 9y ago
    It is backed up by on the biggest Software companies in the world and the amount of stuff Google has their hands in is mind boggling.
deleted 9y ago
[deleted]
vbernat 9y ago
I wouldn't list the standard library as a great strength of Go. While some parts of it are quite good, some others are terrible. Notably, logging and argument parsing are pretty bad. Compare Go's "flags" and Python's "argparse" for example. And Go's "log" and Python's "logging". The Python versions are not perfect but are at least quite usable. In Go, I have yet to see a project with more than 1k lines of code that won't use a third-party argument parsing and logging package. For logging, each package will use its own logging mechanism. Sometimes, you are lucky and you can pass your own logger (with a random interface as the interface is not part of the standard library either). Sometimes not. For a language born less than 10 years ago, this is a pity.

242 points by secure 9y ago

I think regardless of how each one of us sees Go, its adoption among DevOps (Docker, K8s), Apple and Microsoft means that just like with C and JavaScript it will become unavoidable to use it for certain tasks.

romanovcode 9y ago
Too bad
- deleted 9y ago
  [deleted]
coldtea 9y ago
Adoption from Apple? If you mean on their internal services, then that's irrelevant as to the rest of us "having to use it".
- pjmlp 9y ago
  They have quite a few open positions asking for Go knowledge. No idea how they are using it.
  - coldtea 9y ago
    Yes, I meant it's not like Apple is forcing it on external developers though, like e.g. they "force" Swift. Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC.
    - pjmlp 9y ago
      > Yes, I meant it's not like Apple is forcing it on external developers though, like e.g. they "force" Swift. Sure, but at the same time it creates awareness in other companies that Go is a good bet that they might adopt as well. > Google could do that (if they adopted Go on Android), but I think they went with Dart instead IIRC. They went with Kotlin. Dart is still looking for a killer application beyond supporting AdWords, lets see how far they go with Flutter or Fuchsia.
nindalf 9y ago
I'm not sure that I follow. To me, it sounds like someone saying we need to program in C because we use git whereas we actually interact with git through the interface they've given us, not through its source code. Even if Docker and K8s become ubiquitous, I see no reason programmers taking advantage of these to also program in Go.
- pjmlp 9y ago
  It means that anyone that is working on DevOps, while having Docker/K8s on their employer infrastructure, might eventually be asked to write Go for whatever reason. Given that they are written in Go, and as far as I understand it, the way to customize them also requires using Go.

empressplay 9y ago

I love Go! It houses us and puts food in our mouths. It also powers our side projects. Go is awesome!

thesmallestcat 9y ago
It literally houses you and puts food in your mouth? I'd like to see that.
- swah 9y ago
  Maybe they* live inside the O? Confusing.
  - empressplay 9y ago
    She =) But thanks for your sexist assumptions! They're awesome!
    - bauerd 9y ago
      Did you just assume personhood? You might be responding to a Markov chain for all we know.
      - empressplay 9y ago
        Are you saying Markov chains can't be sexist?
        coldtea 9y ago
        Seeing that they are mere algorithms, yes. Being X implies intention. At best they can accidentally put out something sexist as a result of their input.
    - nolok 9y ago
      That comment has got to be a joke... Right?

wasted_intel 9y ago

The "easy to learn" argument is getting old. If the cognitive load never decreases, that's one thing, but initial ramp-up time shouldn't be a large determining factor. The MVC pattern, ADTs, functional programming, and so many other useful concepts were foreign at first, but have a substantial impact on how you think and work. With the exception of channels, Go doesn't add much when compared to other languages. Maybe that's a pragmatic choice, but it feels short-sighted to me.

webscalist 9y ago
Huge success of mongodb was due to "easy to learn" advertisement, paired with getting shit done and rewrite later agile trend, and web scale.
- eeZah7Ux 9y ago
  Is this a positive or negative example?
emperorcezar 9y ago
Sadly our entire industry is based around being short sighted. Quick to learn is only important if you have the lack of patience to spend the time to learn something you'll be using for years.
- holydude 9y ago
  Our industry is hugely based on illusions and misconceptions. There are only few places on earth where people regularly rebuild the skyscrapers to build taller ones. The IT industry simply forces you to re-learn the same old paradigms in a new package just to gain 0.1% of something we cannot even define as an improvement.
  - pjmlp 9y ago
    Quite common in fashion driven industries.
  - 9y ago

sandGorgon 9y ago

I'm kind of wondering about why is there no production ready JavaScript/TS to exe compiler that packages all dependencies and creates a single executable - like go. With the amount of mind share that js ecosystem has, I thought that would be a thing. The keyword being "all dependencies"

mlcdf 9y ago
Something like https://github.com/zeit/pkg https://github.com/zeit/pkg ?
- sandGorgon 9y ago
  very cool! is this production ready ?
styfle 9y ago
A couple more: https://github.com/nexe/nexe https://github.com/nexe/nexe https://github.com/pmq20/node-compiler https://github.com/pmq20/node-compiler

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

kasey_junk 9y ago

If I were to build a list of the reasons I use go, it wouldn't be terribly different than this one. But interestingly, while I program go every day, I sort of hate it as a language. You'll note this list doesn't actually have much to do with the language per se, the only point directly related to that is that go has a short list of reserved words (which is true of most languages). So for future language designers (or existing language designers that want to increase the popularity of their language) it seems like things like language ergonomics, power, etc are less important than having a standard batteries included development stack coupled with out of the box "good enough" performance.

secure 9y ago
I noticed as well that I didn’t mention a single language feature, even though I do actually like many :). I agree with the sentiment you expressed: the overall experience when using a language matters to me much more than individual language pros or cons.
cyphar 9y ago
> But interestingly, while I program go every day, I sort of hate it as a language. I have the exact same feeling. There's a lot wrong with Go, but it makes up for its problems by having very nice tooling (though of course there's problems with that too).
- fetchfetch 9y ago
  After having coded tens of thousands of lines in Golang for 4 years, there are a list of probably hundreds of grievances I have about the language itself. The problem is that they're generally outweighed by the simplicity, consistency, and clarity of the language. Is the error system terrible? Obviously. Lack of abstract data types? Awful. Is Rust one thousand fold safer and more syntactically powerful by comparison? Sure. But the fact is, in a world where we as developers often are learning and working in a new language every year or two, time-to-productivity and proficiency in a given language is one of the most important, if not the most important, metrics for a language. And Golang knocks this out of the park with its obvious syntax and great tooling. You can bring in a new junior programmer onto your Golang stack and have then turning out useful pull requests in a week or two, which I can't say for languages like Rust. I _hate_ much of Golang's engineering, but for collaborative programming I think anyone would agree that it's a highly productive language.

steinuil 9y ago

I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this. That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.

lanestp 9y ago
Does someone want to give a reason for down voting this comment? There isn’t anything controversial here. For myself, lack of genetics are enough reason not to use the language. My personal style relies a lot on them and I don’t see myself sacrificing that power for above average tooling.
- reificator 9y ago
  > For myself, lack of genetics are enough reason not to use the language. The typo/autocorrect here turns this into a much more controversial statement...
deleted 9y ago
[deleted]
int08h 9y ago
Re: getting tooling "right" and that driving adoption/popularity. I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings. However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.
- steinuil 9y ago
  Yes, my impression is that Go was created partly to be used in corporate environments to replace Java with a less verbose language that scaled well, and it seems to be doing well in that regard.

krylon 9y ago

I have said it before and I will say it again - for all the deficiencies Go has, it is somehow highly compatible with the way my brain works. One point the article does not mention is the documentation. I think Go's documentation is excellent, it does not overwhelm the reader with its volume, but mostly anything one might want to know about the syntax and semantic can be answered by carefully reading through the documentation that comes along with the development tools. Also, there are some pretty neat static analysis tools for Go out there, and since they are mostly developed in a development-environment-agnostic way, they tend to be usable from a relatively wide range of editors and IDEs. But even just using go vet and golint regularly goes a long way to rooting out all those tiny but tedious bugs and ensure a degree of consistency in naming conventions. I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscores, but the fact that my code is laid out in the same way as that of third-party libraries means it is surprisingly easy to dive into somebody else's code and make sense of it. The fact the Go community tends to favor simplicity over brevity can get annoying at times, but when you have to read somebody else's code to figure out if it's buggy or you're using it wrong, it is priceless. There a many things Go could do better (or at all), but if there is no way to implement some feature without sacrificing simplicity, I prefer simplicity. I you want C++, as the saying goes, we know where to find it. ;-) (I'll admit though that the C# designers have done an impressive job at adding lots of features without the language collapsing under its own weight. So it's not like it's impossible.)

pavlov 9y ago
I still do not see why somebody in their right mind would willingly prefer camelCase over using_underscore My taste is the opposite: I can't understand underscores in identifiers, it's like having hiccups inside every thought. But what saddens me is that we're still having this conversation in 2017. It would be trivial for editors to support either style, if only language designs included the concept of word separator inside identifiers, which could then be rendered at display/edit-time according to user preference. Somehow programming languages are extremely resistant to these kinds of improvements. ColorFORTH is the only example that comes to mind of a language designed beyond ASCII.
- 9y ago

squeeeeeeeeeee 9y ago

I haven't looked at Go yet, but all these "is so easy to learn" and "generics are bad because they're not easy to learn" articles on HN, I have to wonder if this language is really so great or people push it because of the politics of people making it.

secure 9y ago
Only one way to find out… learn some Go? :) As author of this article, I can only say that I wrote about Go because I honestly like it, not because I have any agenda.
- weberc2 9y ago
  It will take all of 2 hours tops to go from zero to writing an interesting program.
weberc2 9y ago
While I do like that Go is ready to learn, I like that it is small enough to hold in my head. Pretty much everything works intuitively, save for a couple surprises. The same goes for its tooling. There is no complex project or package tooling to learn either. That said, it doesn't have a passable story for sum types or generics, which are important for the kind of programs I write these days. I'm convinced that summertime could build something as simple as Go, but with better abstraction facilities. Ideally this language would look like Rust and compile to Go.
- kuschku 9y ago
  > There is no complex project or package tooling to learn either. Question, how do you handle dependencies without them ending up checked in in your git? I’ve had no success yet with go and dependencies, there’s no simple way like in the Java world to just define a list of dependencies and have the built tool automatically fetch them in some dotfolder, and take care of the rest, is there?
  - 9y ago

jernfrost 9y ago

Wow this is extemely close to my own reasons for having a preference for Go. Very well articulated. The clarity of Go code can not be empasized enough. To be fair my favourite languages are Julia and Swift but that neither can really math Go in clarity and simplity.

chris_st 9y ago

I've been using Go for a while, and am frankly amazed at the quality of the tooling. I'll add something others haven't mentioned... the profiler produces an absolutely amazing graph of the run-time call tree[0]. This makes it incredibly easy to not only see where the code is spending its time, I can easily the context, and where else time is being spent. I recently sped some code up (5x!) using this. 0: https://blog.golang.org/profiling-go-programs https://blog.golang.org/profiling-go-programs

nnd 9y ago

What would convince an avid Python user to switch to Go st this point? Let’s narrow down the scope to an API backend to be more specific (isn’t that’s where Go’s performance thrives?)

fetchfetch 9y ago
- Real concurrency without having to deal with spawning multiple programs that communicate over some higher level process - Good concurrency primitive (channel), although asyncio Futures in Py3 aren't that bad either - Strong typing - Easy byte-level manipulation - Extremely easy to learn - Simplistic error handling compared to exceptions (there are problems with this I won't go into, but it's easy to learn at least) - Amazing tooling (gofmt forces your codebase to be consistent regardless of who is writing it)
eadmund 9y ago
I was an avid Python user for roughly a decade, and I switched to Go. IME, writing it feels a lot like writing Python, but I feel much more confident that the code I write will run the way I expect.
luord 9y ago
Python is my favorite language and I really liked Go as I read about it. When time came to actually learn and use it, I was... Disappointed. Sticking with python still, for the time being.

ausjke 9y ago

Just use modern C++

andreasgonewild 9y ago
Couldn't agree more, a much better investment of anyones time. C++ won't suddenly refuse to solve your problems because they don't fit into an arbitrarily limited view of the world. And some of the stuff coming out of standardization lately is simply awesome.
- _binder 9y ago
  Can you share some of it. Trying to get better at C++ here.
  - andreasgonewild 9y ago
    Sure thing. Bear in mind that this is my way of doing it; plenty of people will yell blasphemy at the choices I make, and some may well turn out to be suboptimal without 32 years of experience to back them up. https://github.com/andreas-gone-wild/snackis https://github.com/andreas-gone-wild/snackis
theshrike79 9y ago
I would, but package management for C & C++ is still in the same shape it was 25 years ago - nonexistent.

pmoriarty 9y ago

When Java was first introduced, the world was abuzz about this cool new language which you could "write once, run anywhere". It took some time, but as it grew in popularity, articles started appearing about how much Java sucked because it was slow and bloated, required a ton of boilerplate code, and eventually because "write once, run anywhere" turned out to be a myth, along with a boatload of other reasons. The honeymoon wore off, and legions of Java-haters were born. Perl suffered a similar fate. When it came out unix was just surging in popularity with the internet boom and a lot of people were thrilled to have a single language you could learn which combined the features of common command-line tools like sed and awk, and that was a "real programming language" that was more powerful than shell scripting, and which grew to have a ton of useful libraries in the form of CPAN. Years later, and Python and Ruby started getting popular, the "Perl sucks!" mantra sprang up and the once-mighty Perl shrank before the upstarts. Ruby and Python are getting their turn now, and I'm starting to see some people expressing hate towards them as well, though it hasn't quite reached the pervasiveness of Java and Perl hate yet. Go was next. People were excited about this cool new language from Google, a place filled with great engineers, and from the mind of Rob Pike, of Unix and Plan 9 fame. It was supposed to be like a simpler and more elegant form of C. What's not to like. Well, the replies to this post are showing that for some the honeymoon is already over. Other languages had their day in the limelight, only to wind up being hated: C++, Lisp, Fortran, Cobol, HTML, Javascript. Bjarne Stroustrup observed that "there are two types of languages, the ones everyone complains about, and the ones nobody uses." Whenever some shiny new language comes out, promising to solve everyone's problems in some domain, and people start jumping on the bandwagon and singing its praises to high heaven (which seems to happen ever couple of years), I try to take a deep breath and step back. There will likely come a day, before too long, when they too will be subject to hatred and scorn, just as all the other popular languages before them.

wyager 9y ago
> "there are two types of languages, the ones everyone complains about, and the ones nobody uses" Of course Bjarne would say that. The reality is, there are some languages that people use a lot and don't complain about nearly as much. Some languages are just actually worse to use. http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-c...

gmoes 9y ago

I know a guy who used to teach Haskell at a university who now runs a development shop at a startup that uses Go. From I recall his main reason for choosing it was to hire cheaper less experienced developers. I remember talking to him about Go and he remarked something like: If you want to clean modular code don’t use Go. Not to disparage less experienced developers but I think teams of developers of any experience level need to have code governance and oversight regardless of the technologies and that a good team with good practices can create good code bases even with more complex and expressive languages. I know another colleague who did this with Scala and was able to properly mentor more junior developers by leading by example. I have not used Go. I have done and lot of Java and a bit of Scala and have many times leveraged generics to create a very high degree of reuse. Without them clearly you get a lot of boilerplate code which makes a codebase larger which leads to another type of complexity in my opinion. So the question is which scenario increases your codebase complexity and that probably boils down to what domain you are developing in. I explore some ideas relating to that tradeoff here [0]. Go has a specific use case that it targets which I believe is services and certain aspects of concurrency. Clearly the Go language and environment have value in the industry, however, as a language it offers little for people who want to have an opportunity grow and learn about more advanced concepts wrt to PLT and CS in general. I have a friend who is a Go fanatic and I try to encourage her to push her limits, but she feels and she can bang out service level code very quickly and she can as she is quite talented. Of course you can do that with Spring Boot as well. Regardless of your language you should always be trying to grow as a developer otherwise you risk becoming obsolete. To put it bluntly and I may get downvoted for this I feel Go is the “Rise of the Expert Beginner Language”. [1] [0] http://www.elegantcoding.com/2012/02/software-reuse-complexity-curve.html http://www.elegantcoding.com/2012/02/software-reuse-complexi... [1] https://www.daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/ https://www.daedtech.com/how-developers-stop-learning-rise-o...

solidsnack9000 9y ago
"The Rise of the Expert Beginner" was a great read. I do see the parallels to the tone and tenor of some arguments in favor of Go. One thing I wonder about is a seeming complementary anti-pattern, the "Expert Only Language". Perhaps C++ is the only language that truly fits this description, but one can see shades of it in Haskell, Scala & Rust. To a limited degree, Bash and SQL exhibit similar qualities, because people can use them for years but barely know them. These are languages where a certain confusing richness is accepted as the cost of doing business, and where a long period of familiarization is assumed to be necessary before doing basic things.

KirinDave 9y ago

> There is a cost to introducing an abstraction layer. Go code is usually rather clear, at the cost of being a bit repetitive at times. Go programmers say this a lot and every time I see it I wince. We've had all sorts of flights of fashion and fancy in the programming world, but one observation has emerged that seems closer to fact every time we test it: more code is more bugs. The more code you write, the more chance there is for bugs. And so it's so confusing to me why Go programmers simply discard this information, universally accepted as it has come to be. "The repetition is simple," they reply, "and of course abstractions have cost." So what is the cost? Because I can tell you the state of affairs right now. I find Go code exhausting to debug, because there is effectively no universal way to handle errors other than to copy-paste if-nil statements. Occasionally, slightly different error handling logic creeps in and it's so tempting to start pattern matching the whole block of code and miss these subtleties. This list's discussion here... Well sometimes I get the impression that Go programmers are more interested in never having the opportunity to make a conscious mistake, in exchange for making lots of unconscious mistakes. Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible. As such, it is quick to learn the syntax. It's not really any quicker to learn how to write good robust multi-threaded code though. I still think the Java standard library consistently delivers a better result for equivalent work, at the cost of learning and extra (standard) library. I just don't understand why anyone appreciated go's design space outside of engineers-turned-architects trying to staff a massive tech org with engineers they don't think very much of and have no desire to train.

treehau5 9y ago
As Sandy Metz once said, "A little duplication is far better than the wrong abstraction." After a decade of OOP indoctrination and misuse, we see the results of this. > Go has popularized a mode of writing code where not only are abstractions unwelcome, but they're nearly impossible This lends me to believe you actually haven't written any go code for yourself. This is the same thing every OOP-indoctrinated developer (Usually Java or C#) has said before. I came from those languages, and this statement is categorically false and completely unfounded in reality.
- 9y ago

DinoDano 9y ago

Its the best, but I'm sad and shamed it is owned by google.

_binder 9y ago
Why are you sad? It is backed up by on the biggest Software companies in the world and the amount of free stuff Google is throwing around is mind boggling.
- kuschku 9y ago
  It is backed up by on the biggest Software companies in the world and the amount of stuff Google has their hands in is mind boggling.

deleted 9y ago

[deleted]

vbernat 9y ago

I wouldn't list the standard library as a great strength of Go. While some parts of it are quite good, some others are terrible. Notably, logging and argument parsing are pretty bad. Compare Go's "flags" and Python's "argparse" for example. And Go's "log" and Python's "logging". The Python versions are not perfect but are at least quite usable. In Go, I have yet to see a project with more than 1k lines of code that won't use a third-party argument parsing and logging package. For logging, each package will use its own logging mechanism. Sometimes, you are lucky and you can pass your own logger (with a random interface as the interface is not part of the standard library either). Sometimes not. For a language born less than 10 years ago, this is a pity.