29 ms·

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wis

by sesteel 12y ago

Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It used to drive me crazy when I would read negative comments in r/programming and HN, but I don't even pay attention to the negative comments anymore. The adoption is far better than I was afraid it was going to be.

mateuszf 12y ago
Two words: error handling and generics.
- NateDad 12y ago
  I agree, those are two great reasons to use Go.
  - NateDad 12y ago
    Totally worth the downvotes for my own amusement. :)
  - baldfat 12y ago
    Why down vote some who likes the fact that he likes the error handling method in Go and that he doesn't like generics?
- touristtam 12y ago
  that's 4 words .... and if you are not comfortable with those two aspect of the language and have the choice, I don't see why you need to use golang.
- danieldk 12y ago
  Error handling is something that I did get used to, especially considering that one can assign and check in an if-statement. Generics I still miss every single day. But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?
  - monocasa 12y ago
    No garbage collector so I can actually use it in embedded situations.
    - jksmith 12y ago
      Easy target response I know, but hey it's open source so fork it.
    - NateDad 12y ago
      That's not really what Go is for. Look at Rust if that's what you want - memory safety without a garbage collector.
    - danieldk 12y ago
      I should stop using rhetorical questions :). But indeed, such embedded applications are not Go's domain.
  - nutate 12y ago
    Have you tried go gen? It looks clearer to me than some of the hoops I've seen set up, jumped through, etc for heavy STL generics: http://clipperhouse.github.io/gen/ http://clipperhouse.github.io/gen/ It just creates the code for you, then you commit it. Easy enough.
    - danieldk 12y ago
      It just creates the code for you, then you commit it. Easy enough. Except that it does not provide the same thing. If I provide a package with e.g. a container datatype, I would have to generate for every possible data type that any user wants to put in the container. Obviously, that is not going to scale.
      - NateDad 12y ago
        Not really.. you provide the base code, and the consumer of your package generates the specific types they need. As the package author, you don't actually generate any of the concrete implementations.
- donatj 12y ago
  Go's error handling is honestly the best I've ever used. No errors go unhandled. Period. get an error? Return it or deal with it. Makes much more sense than exceptions suddenly breaking the behaviour of the language.
  - sfk 12y ago
    How are errors in deferred functions handled? How about division by zero?
    - NateDad 12y ago
      errors in deferred functions are handled just like they would be if the function were not deferred. There are some things like division by zero and array index out of bounds that cannot be used with this method without making the language incredibly cumbersome... for those, there are panics (basically like exceptions in other languages)... but they happen quite rarely in practice.
    - Jayschwa 12y ago
      Deferred functions can pass along errors by using a closure. http://play.golang.org/p/_ZqSk470-b http://play.golang.org/p/_ZqSk470-b
  - politician 12y ago
    It's not actually true that no errors go unhandled. func foo() error { return errors.New("whoa!") } func bar() { _ := foo() // onward! }
    - NateDad 12y ago
      Uh yes? This is you telling the compiler specifically that you don't care about the error. It's equivalent to try { foo() catch {} In other languages. That's not a problem, that's the computer doing what you explicitly told it to do.
  - kornish 12y ago
    Not quite: here's an example of code which returns an error but for which the return value is never even captured. http://play.golang.org/p/EL2-2gl7wh http://play.golang.org/p/EL2-2gl7wh
aros 12y ago
Can you please elaborate on the "wisdom of the language" and why you feel it's necessary to ignore all criticism?
- baldfat 12y ago
  > ignore all criticism? I don't feel like they ignored them they are basically saying they think they have a better solution.
ceronman 12y ago
You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens with Haskell and at some point with Rust. In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Note: Rust actually has a chance because it's simple compared to its competition: modern C++.
- danieldk 12y ago
  In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors). This is not a critique of Go, just to point out that it is a trade-off, and there isn't necessarily one right answer.
  - WaltPurvis 12y ago
    But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written many thousands of lines of Go and have had to resort to duplicated code once (and in that particular case all that required was a couple copy-pastes and minor edits, and I'd have to go back and revisit it but it's possible I could have solved it more elegantly if I'd known Go better).
    - danieldk 12y ago
      But that is so rarely an issue... For you... It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats. Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner. So, yes, the lack of generics is a frequent issue for me.
Dewie 12y ago
Maybe part of the problem is that people that promote Go in some capacity will at times make good arguments for certain things, but when they find something that they can't really explain, or that might seem subpar, they devolve their argument into some kind of appeal to authority - 'who am I to question their decisions. These are experienced, respected programmers with a lot of accomplishments. Who are anyone born after 1985 to judge them, really?' So maybe you'll excuse some people for not simply assuming that the masters are right just by virtue of who they are.
- jerf 12y ago
  You might find this interesting: http://www.reddit.com/r/programming/comments/2wy2qe/gos_compiler_is_now_written_in_go/covmaai http://www.reddit.com/r/programming/comments/2wy2qe/gos_comp... , my reply to someone's question about what is interesting and/or unique about Go. A bit much to just copy & paste in here, probably. While so many people are complaining about what it doesn't have, there are things it does have that, while not individually unique, are actually packaged into a unique bundle. Particularly the fact that it is a traditional imperative language. If you (like me!) don't mind picking up Haskell or O'Caml or Erlang to get weird features, it might be hard to understand the appeal, but for many people Go is the first time they've seen these features without having to drop almost everything they know about programming on the floor in the process. This probably explains some of the breathless excitement it sometimes engenders... it's the same breathless excitement that people will sometimes have when first using those other languages. (And, yeah, the traditional imperativeness does bite a bit. I'd love to be able to assert that a goroutine is fully isolated from everybody else's memory. In practice, I'm not having any trouble with that, but, then, I've got 7 years or so of Erlang under my belt so designing isolated processes that work together via clean interfaces is something I've got a ton of experience with from the most rigid language on this topic there is. YMMV, and I really mean that... you certainly can blow your foot off in Go, isolation is only convention, not enforced.)
  - danieldk 12y ago
    While so many people are complaining about what it doesn't have, The problem is not really what Go does not have, it's that often fallacies are used to react to critique on Go. Another one that pops up very often is 'you just have to use it for some time to understand why Go does not need it'. This is of course nonsense. Anyone who has programmed C and C++ knows the advantages and disadvantages of generics. And despite the disadvantages of a particular implementation, most people want still want generics for good reasons. Even if you like Go (and I do mostly), it's ok to say 'sure, that is a weakness in the current version of Go'.
CatDevURandom 12y ago
I agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+). Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not to say Go is a perfect (e.g. a 'real' debugger option), and it doesn't have to be. If you love Rust, or Ruby, or whatever, great. The programming language landscape is not a zero sum game. tl;dr Go's a fine tool to get stuff done for a large set of problem domains.
- jksmith 12y ago
  >>it's small enough to keep in your head This. And the additional effect is that you can keep more of the problem domain in your head as well. I've been in this game a long time, and my experience has been that the simpler the dev tools, the more likely the programmers working on a particular domain will be SME's in that domain.
  - jimbokun 12y ago
    SME?
    - bmelton 12y ago
      Subject Matter Expert.
  - threeseed 12y ago
    My experience is that being a domain expert and simplicity of dev tools has absolutely nothing to do with each other. At the end of the day you have to understand the problem in order to implement it. Whether you write it in Ruby, Java, Go, Assembler really doesn't change this. It just means you may take longer to do it. And your logic falls apart. If simple dev tools translate to greater productivity then how do you explain the proven benefits of IDEs with all of their "complex" features.
- 12y ago
meddlepal 12y ago
Sounds a lot like you drank the Kool-aid.
- baldfat 12y ago
  >Sounds a lot like you drank the Kool-aid. So anyone who likes Go is deceived? Why use words like that? How about just saying GO isn't for me. Saying any more is just you imposing your opinion on someone else and devaluing them.
sbt 12y ago
I've been coding Go professionally now for about 8 months. Interestingly, it has made me appreciate C++. The reason is while the Go compiler is fast, it is mostly because it doesn't do very much work. By contrast, a C++ program takes a long time to compile because the compiler does a lot. It's obviously not as black/white as I've portrayed it here for brevity, but it is nevertheless an apparent trade off. I like Go overall, but on balance I would prefer a slower compile-test cycle to have more language feature support.
- twic 12y ago
  > on balance I would prefer a slower compile-test cycle to have more language feature support So, are you sbt as in: http://www.scala-sbt.org/ http://www.scala-sbt.org/ ? I don't think i've seen a build tool posting on HN before, but now i have, i'm not surprised it's a Scala one.
theseoafs 12y ago
I can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."
- logicallee 12y ago
  fwiw, I found sesteel's comment useful and informative. (by the way, you might have misread it. I think he didn't mean "generation of masters" as "old smart people" but probably specifically the creators of Go, since they happen to include Rob Pike and Ken Thompson - two people who had separately created the B programming language (immediate predecessor of C), co-created Unix at Bell Labs in the 70's, co-authored a famous Unix book with Kernighan (of Kernighan and Ritchie fame), authored UTF-8 together, etc. They happen to be actual old masters. They created Go in 2007, from what I heard cleaning up a lot of their old mistakes along the way.)
  - theseoafs 12y ago
    I know who created Go, because everyone does. Being created by Pike, Thompson, and whoever else does not in and of itself make Go better than any other language. It also does not make it immune to criticism in such a way that you should brush off anyone who has anything negative to say about it.
    - logicallee 12y ago
      >Being created by Pike, Thompson, and whoever else does not in and of itself make Go better than any other language. which is why I called your parent useful and informative.
    - gknoy 12y ago
      It doesn't make it better, but it's a __very strong hint__ that perhaps I should look more closely at Go. Experts matter, and it would be foolish of me as a developer to discount the experience of these guys -- they've literally been programming for longer than I have been alive. I respect the creators of Go deeply, because they have been so formative of the industry. It's like being an electrical Engineer, and having Nikola Tesla make a suggestion -- I might not understand all of the lessons, but there's a distinct possibility that these guys are addressing problems I don't yet fully understand.
throwawaykf05 12y ago
This is the first time I've seen the Blub Paradox [1] portrayed as ignorance from the other direction! OK, not a big believer of the "Blub" theory, personally - every language has its place in a continuum of dimensions that are more than just technical, and I actually like Go overall. But "lack of generics" is definitely not the same as "simplicity. Not in the decade we live in. 1. http://c2.com/cgi/wiki?BlubParadox http://c2.com/cgi/wiki?BlubParadox
- Veedrac 12y ago
  The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true. > But "lack of generics" is definitely not the same as "simplicity. It's not literally the same thing, but it is an aspect that keeps Go simple.
  - jerf 12y ago
    "The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true." Yes, speaking for myself as someone often in the position of defending Go on HN (even though as a computer language polyglot it isn't part of my personal identity), I also speak several other languages that do have generics in them, along with substantial usage of the "dynamically typed" languages, and most relevantly, including reasonable fluency in Haskell, a language where the generics are so deep and fundamental they aren't even given a name, they just are. What Haskell calls "Generics" is actually more like what other languages call "reflection". Yes, there are a ton of programs that you can usefully write without "generics", especially since interfaces are about half of "generics", and arguably the more useful half in general. Yes, there are a ton of programs that you can't really write without them. We could do with a lot more sensible discussion about which programs are which and a lot less "Oh, you think it's OK for Go to not have generics? Well you must be an idiot then." (e.g., my frequent observation that if you need a rich numeric hierarchy you really need generics... but those cases really are exceptions compared to programs that are just fine on integers and floats, and, frankly, in many cases just fine on integers alone.)
talideon 12y ago
My only real issue with it is that I really with it had algebraic types. That would save me a tonne of faffing about and help make code safer to boot. Type switches are a clumsy alternative that only cover some of the cases.
- garfij 12y ago
  Specifically to be utterly pedantic: Go has algebraic types. It has both Product types (structs) and unbounded Sum types (interfaces). What you're looking for is bounded Sum types with extra language support such that when you use them, it checks that you've covered all cases.
WorldWideWayne 12y ago
Regardless of how I feel about Go as a language... I don't trust Google to perform well as the steward. It may be open source, but that means nothing if people stop working on it. If it doesn't become popular, I think they will just let it die. If they start trying to make it popular, I think there will be a big push back from the great unwashed masses of people who want obvious features and then it will die. Only time will tell.
- chwahoo 12y ago
  Who's the steward of your language of choice?
  - WorldWideWayne 12y ago
    Languages of choice...but shouldn't matter who it is. Why draw comparisons that will only serve to evoke political and ideological responses? I think that my suspicion of Google's capacity to perform here is warranted and that's really all I have to say about it.
- curun1r 12y ago
  I don't think you have to trust Google, you just have to trust the core team. While they all work for Google now, the language is open source and they have reputations that extend well beyond their time at Google. I share your distrust of Google, but I trust Ken Thompson, Rob Pike and the rest of the team enough that I don't worry about choosing Go. I have faith that if Google kills it or starts to misbehave, the team will leave and figure out a way to keep the language moving forward.
  - WorldWideWayne 12y ago
    I understand what you're saying but I think it also goes to my point - I feel like those handful of people couldn't possibly do as much to get Golang into the mainstream as could a whole company/divisional effort. I honestly don't feel like Google as a company is putting that much effort into Golang and many of their other projects. Remember when they were building Chrome and how quickly they iterated on it? That was awesome to behold! Maybe a slow pace and a smaller user base is better for developing a language, but if that's the case then I guess I'll just wait another decade before really investing time into Golang.
matthewmacleod 12y ago
I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitives, decent stdlib and tooling make Go pretty great to use in some respects. It's likely to be well-supported for a long time and is a suitable tool for many tasks. On the flipside, using it often feels like a bit of a slog. Error handling is simple (good) but repetitive (bad). Keeping generics out of the language avoids complexity (good) but results in repetitive and awkward code (bad). Lack of features like pattern matching and higher-order functions makes some code irritatingly tedious to read and write. And so on. Point is, it's perfectly valid to look at these decisions and say "I don't like Go because it is missing these features", as much as it's valid to say "The simplicity of Go is a useful feature". Ignorance is not a prerequisite for disagreement. So please have some respect for opinions which differ from your own, and think about offering something a little more constructive than insults.
- xkarga00 12y ago
  Just a note: Go supports higher-order functions
- sesteel 12y ago
  I agree, I should have grounded the claim of ignorance in a long list of specific instances or made no comment at all; sometimes less is more. Aside, I use and enjoy languages other than Go; it is simply a tool to solve problems, and I don't want to detract people from using other tools. We all develop opinions with regards to what does and does not work well. I never intended to devalue others' experience or perspective. I was simply pointing out that many people seem to not have suffered through enough bad work experiences to appreciate Go's main feature of simplicity. If you haven't run across horrible, insanely overcomplicated, code written by those that think they are the top 1% intelligence-wise, you might not appreciate Go. Likewise, if you write horrible, insanely overcomplicated, code and think you, yourself, are brilliant, you probably won't appreciate Go. If you only work alone or on small teams and projects, you might not appreciate Go.
gnuvince 12y ago
Simple languages are good, but we should be careful to understand why they are simpler: in many cases, the complexity is simply shifted from the language onto the programmer. Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.
- sampo 12y ago
  Maybe, if there were several official "levels" defined for complex languages (like Scala). So then a team that wants to keep codebases conceptually simple could decide that they are only using features up to e.g. level 3, anything above is forbidden. And the compiler would support this. A bit like you can select different languages in Dr. Racket http://docs.racket-lang.org/drracket/choose-language.html http://docs.racket-lang.org/drracket/choose-language.html
- zik 12y ago
  > the complexity is simply shifted from the language onto the programmer. That's not my experience with Go at all - it provides less resistance to getting code written than any other language I can think of offhand.
stcredzero 12y ago
but I don't even pay attention to the negative comments anymore The "not quite a field" of programming, has a famous history of being full of smarmy naysayers being spectacularly wrong. It's no wonder that the few of us who aren't bratty and quickly judgemental tend to become famous and successful. (Nor that a famous blogger once said that everything he needed to know about managing programmers, he learned from the book, "How to Talk to Your Five Year Old.")
coldtea 12y ago
>Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It's mostly the wisdom of the eighties. Today's professionals have better options.
GFK_of_xmaspast 12y ago
Aerosmith was hot in the 1970s too.

by sesteel 12y ago

mateuszf 12y ago

Two words: error handling and generics.

NateDad 12y ago
I agree, those are two great reasons to use Go.
- NateDad 12y ago
  Totally worth the downvotes for my own amusement. :)
- baldfat 12y ago
  Why down vote some who likes the fact that he likes the error handling method in Go and that he doesn't like generics?
touristtam 12y ago
that's 4 words .... and if you are not comfortable with those two aspect of the language and have the choice, I don't see why you need to use golang.
danieldk 12y ago
Error handling is something that I did get used to, especially considering that one can assign and check in an if-statement. Generics I still miss every single day. But not enough to stop using Go. It's pretty much C with interfaces, a garbage collector, and safety. What more can one wish for?
- monocasa 12y ago
  No garbage collector so I can actually use it in embedded situations.
  - jksmith 12y ago
    Easy target response I know, but hey it's open source so fork it.
  - NateDad 12y ago
    That's not really what Go is for. Look at Rust if that's what you want - memory safety without a garbage collector.
  - danieldk 12y ago
    I should stop using rhetorical questions :). But indeed, such embedded applications are not Go's domain.
- nutate 12y ago
  Have you tried go gen? It looks clearer to me than some of the hoops I've seen set up, jumped through, etc for heavy STL generics: http://clipperhouse.github.io/gen/ http://clipperhouse.github.io/gen/ It just creates the code for you, then you commit it. Easy enough.
  - danieldk 12y ago
    It just creates the code for you, then you commit it. Easy enough. Except that it does not provide the same thing. If I provide a package with e.g. a container datatype, I would have to generate for every possible data type that any user wants to put in the container. Obviously, that is not going to scale.
    - NateDad 12y ago
      Not really.. you provide the base code, and the consumer of your package generates the specific types they need. As the package author, you don't actually generate any of the concrete implementations.
donatj 12y ago
Go's error handling is honestly the best I've ever used. No errors go unhandled. Period. get an error? Return it or deal with it. Makes much more sense than exceptions suddenly breaking the behaviour of the language.
- sfk 12y ago
  How are errors in deferred functions handled? How about division by zero?
  - NateDad 12y ago
    errors in deferred functions are handled just like they would be if the function were not deferred. There are some things like division by zero and array index out of bounds that cannot be used with this method without making the language incredibly cumbersome... for those, there are panics (basically like exceptions in other languages)... but they happen quite rarely in practice.
  - Jayschwa 12y ago
    Deferred functions can pass along errors by using a closure. http://play.golang.org/p/_ZqSk470-b http://play.golang.org/p/_ZqSk470-b
- politician 12y ago
  It's not actually true that no errors go unhandled. func foo() error { return errors.New("whoa!") } func bar() { _ := foo() // onward! }
  - NateDad 12y ago
    Uh yes? This is you telling the compiler specifically that you don't care about the error. It's equivalent to try { foo() catch {} In other languages. That's not a problem, that's the computer doing what you explicitly told it to do.
- kornish 12y ago
  Not quite: here's an example of code which returns an error but for which the return value is never even captured. http://play.golang.org/p/EL2-2gl7wh http://play.golang.org/p/EL2-2gl7wh

aros 12y ago

Can you please elaborate on the "wisdom of the language" and why you feel it's necessary to ignore all criticism?

baldfat 12y ago
> ignore all criticism? I don't feel like they ignored them they are basically saying they think they have a better solution.

ceronman 12y ago

You mention the key point of Go: simplicity. I think many developers tend to underestimate the power of simplicity and overestimate the power of certain features. Every single abstraction has a price in complexity. This is why Lisp, being a super powerful language invented in the 1950s never got widely used. Even when the syntax is simple, the conceptual complexity of the language is quite big. Same thing happens with Haskell and at some point with Rust. In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Note: Rust actually has a chance because it's simple compared to its competition: modern C++.

danieldk 12y ago
In the end people realize you can actually build things up without paying this complexity tax with simpler languages. This is why languages like Go succeed. Of course, you pay the tax somewhere else and that is code duplication. You see this in Go due to the lack of generics, which often results in duplication of code for different types or reliance on reflection (which is slower and can lead to runtime errors). This is not a critique of Go, just to point out that it is a trade-off, and there isn't necessarily one right answer.
- WaltPurvis 12y ago
  But that is so rarely an issue... You might encounter an occasional specific circumstance where you will need do some code duplication in Go, but I've written many thousands of lines of Go and have had to resort to duplicated code once (and in that particular case all that required was a couple copy-pastes and minor edits, and I'd have to go back and revisit it but it's possible I could have solved it more elegantly if I'd known Go better).
  - danieldk 12y ago
    But that is so rarely an issue... For you... It depends on what kind of code you are working on. If you work a lot on numeric code (e.g. in machine learning), you want to make it easy to specialize on e.g. 32-bit or 64-bit floats. Also, since only built-in types are generic, you cannot implement other containers (you never need binary search trees?) in a safe manner. So, yes, the lack of generics is a frequent issue for me.

Dewie 12y ago

Maybe part of the problem is that people that promote Go in some capacity will at times make good arguments for certain things, but when they find something that they can't really explain, or that might seem subpar, they devolve their argument into some kind of appeal to authority - 'who am I to question their decisions. These are experienced, respected programmers with a lot of accomplishments. Who are anyone born after 1985 to judge them, really?' So maybe you'll excuse some people for not simply assuming that the masters are right just by virtue of who they are.

jerf 12y ago
You might find this interesting: http://www.reddit.com/r/programming/comments/2wy2qe/gos_compiler_is_now_written_in_go/covmaai http://www.reddit.com/r/programming/comments/2wy2qe/gos_comp... , my reply to someone's question about what is interesting and/or unique about Go. A bit much to just copy & paste in here, probably. While so many people are complaining about what it doesn't have, there are things it does have that, while not individually unique, are actually packaged into a unique bundle. Particularly the fact that it is a traditional imperative language. If you (like me!) don't mind picking up Haskell or O'Caml or Erlang to get weird features, it might be hard to understand the appeal, but for many people Go is the first time they've seen these features without having to drop almost everything they know about programming on the floor in the process. This probably explains some of the breathless excitement it sometimes engenders... it's the same breathless excitement that people will sometimes have when first using those other languages. (And, yeah, the traditional imperativeness does bite a bit. I'd love to be able to assert that a goroutine is fully isolated from everybody else's memory. In practice, I'm not having any trouble with that, but, then, I've got 7 years or so of Erlang under my belt so designing isolated processes that work together via clean interfaces is something I've got a ton of experience with from the most rigid language on this topic there is. YMMV, and I really mean that... you certainly can blow your foot off in Go, isolation is only convention, not enforced.)
- danieldk 12y ago
  While so many people are complaining about what it doesn't have, The problem is not really what Go does not have, it's that often fallacies are used to react to critique on Go. Another one that pops up very often is 'you just have to use it for some time to understand why Go does not need it'. This is of course nonsense. Anyone who has programmed C and C++ knows the advantages and disadvantages of generics. And despite the disadvantages of a particular implementation, most people want still want generics for good reasons. Even if you like Go (and I do mostly), it's ok to say 'sure, that is a weakness in the current version of Go'.

CatDevURandom 12y ago

I agree. And not for nothing, I'm shipping production code, at a real company, with real customers, with real revenue (250m+). Here's the deal -- all programming languages are just tools. Go's great because it's small enough to keep in your head, and simple. It's fast. It promotes composition. And it has sane concurrency. And quite honestly, I am more productive for the things Go left out then it includes. That's not to say Go is a perfect (e.g. a 'real' debugger option), and it doesn't have to be. If you love Rust, or Ruby, or whatever, great. The programming language landscape is not a zero sum game. tl;dr Go's a fine tool to get stuff done for a large set of problem domains.

jksmith 12y ago
>>it's small enough to keep in your head This. And the additional effect is that you can keep more of the problem domain in your head as well. I've been in this game a long time, and my experience has been that the simpler the dev tools, the more likely the programmers working on a particular domain will be SME's in that domain.
- jimbokun 12y ago
  SME?
  - bmelton 12y ago
    Subject Matter Expert.
- threeseed 12y ago
  My experience is that being a domain expert and simplicity of dev tools has absolutely nothing to do with each other. At the end of the day you have to understand the problem in order to implement it. Whether you write it in Ruby, Java, Go, Assembler really doesn't change this. It just means you may take longer to do it. And your logic falls apart. If simple dev tools translate to greater productivity then how do you explain the proven benefits of IDEs with all of their "complex" features.
12y ago

meddlepal 12y ago

Sounds a lot like you drank the Kool-aid.

baldfat 12y ago
>Sounds a lot like you drank the Kool-aid. So anyone who likes Go is deceived? Why use words like that? How about just saying GO isn't for me. Saying any more is just you imposing your opinion on someone else and devaluing them.

sbt 12y ago

I've been coding Go professionally now for about 8 months. Interestingly, it has made me appreciate C++. The reason is while the Go compiler is fast, it is mostly because it doesn't do very much work. By contrast, a C++ program takes a long time to compile because the compiler does a lot. It's obviously not as black/white as I've portrayed it here for brevity, but it is nevertheless an apparent trade off. I like Go overall, but on balance I would prefer a slower compile-test cycle to have more language feature support.

twic 12y ago
> on balance I would prefer a slower compile-test cycle to have more language feature support So, are you sbt as in: http://www.scala-sbt.org/ http://www.scala-sbt.org/ ? I don't think i've seen a build tool posting on HN before, but now i have, i'm not surprised it's a Scala one.

theseoafs 12y ago

I can't even believe this is the kind of comment that gets upvoted on HN nowadays. "Go was made by smart old people and is therefore good. If you don't understand it's good, you're stupid and I refuse to listen to you."

logicallee 12y ago
fwiw, I found sesteel's comment useful and informative. (by the way, you might have misread it. I think he didn't mean "generation of masters" as "old smart people" but probably specifically the creators of Go, since they happen to include Rob Pike and Ken Thompson - two people who had separately created the B programming language (immediate predecessor of C), co-created Unix at Bell Labs in the 70's, co-authored a famous Unix book with Kernighan (of Kernighan and Ritchie fame), authored UTF-8 together, etc. They happen to be actual old masters. They created Go in 2007, from what I heard cleaning up a lot of their old mistakes along the way.)
- theseoafs 12y ago
  I know who created Go, because everyone does. Being created by Pike, Thompson, and whoever else does not in and of itself make Go better than any other language. It also does not make it immune to criticism in such a way that you should brush off anyone who has anything negative to say about it.
  - logicallee 12y ago
    >Being created by Pike, Thompson, and whoever else does not in and of itself make Go better than any other language. which is why I called your parent useful and informative.
  - gknoy 12y ago
    It doesn't make it better, but it's a __very strong hint__ that perhaps I should look more closely at Go. Experts matter, and it would be foolish of me as a developer to discount the experience of these guys -- they've literally been programming for longer than I have been alive. I respect the creators of Go deeply, because they have been so formative of the industry. It's like being an electrical Engineer, and having Nikola Tesla make a suggestion -- I might not understand all of the lessons, but there's a distinct possibility that these guys are addressing problems I don't yet fully understand.

throwawaykf05 12y ago

This is the first time I've seen the Blub Paradox [1] portrayed as ignorance from the other direction! OK, not a big believer of the "Blub" theory, personally - every language has its place in a continuum of dimensions that are more than just technical, and I actually like Go overall. But "lack of generics" is definitely not the same as "simplicity. Not in the decade we live in. 1. http://c2.com/cgi/wiki?BlubParadox http://c2.com/cgi/wiki?BlubParadox

Veedrac 12y ago
The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true. > But "lack of generics" is definitely not the same as "simplicity. It's not literally the same thing, but it is an aspect that keeps Go simple.
- jerf 12y ago
  "The Blub Paradox would only apply if the people using Go hadn't used languages with generics (or similar); for the most part that's not true." Yes, speaking for myself as someone often in the position of defending Go on HN (even though as a computer language polyglot it isn't part of my personal identity), I also speak several other languages that do have generics in them, along with substantial usage of the "dynamically typed" languages, and most relevantly, including reasonable fluency in Haskell, a language where the generics are so deep and fundamental they aren't even given a name, they just are. What Haskell calls "Generics" is actually more like what other languages call "reflection". Yes, there are a ton of programs that you can usefully write without "generics", especially since interfaces are about half of "generics", and arguably the more useful half in general. Yes, there are a ton of programs that you can't really write without them. We could do with a lot more sensible discussion about which programs are which and a lot less "Oh, you think it's OK for Go to not have generics? Well you must be an idiot then." (e.g., my frequent observation that if you need a rich numeric hierarchy you really need generics... but those cases really are exceptions compared to programs that are just fine on integers and floats, and, frankly, in many cases just fine on integers alone.)

talideon 12y ago

My only real issue with it is that I really with it had algebraic types. That would save me a tonne of faffing about and help make code safer to boot. Type switches are a clumsy alternative that only cover some of the cases.

garfij 12y ago
Specifically to be utterly pedantic: Go has algebraic types. It has both Product types (structs) and unbounded Sum types (interfaces). What you're looking for is bounded Sum types with extra language support such that when you use them, it checks that you've covered all cases.

WorldWideWayne 12y ago

Regardless of how I feel about Go as a language... I don't trust Google to perform well as the steward. It may be open source, but that means nothing if people stop working on it. If it doesn't become popular, I think they will just let it die. If they start trying to make it popular, I think there will be a big push back from the great unwashed masses of people who want obvious features and then it will die. Only time will tell.

chwahoo 12y ago
Who's the steward of your language of choice?
- WorldWideWayne 12y ago
  Languages of choice...but shouldn't matter who it is. Why draw comparisons that will only serve to evoke political and ideological responses? I think that my suspicion of Google's capacity to perform here is warranted and that's really all I have to say about it.
curun1r 12y ago
I don't think you have to trust Google, you just have to trust the core team. While they all work for Google now, the language is open source and they have reputations that extend well beyond their time at Google. I share your distrust of Google, but I trust Ken Thompson, Rob Pike and the rest of the team enough that I don't worry about choosing Go. I have faith that if Google kills it or starts to misbehave, the team will leave and figure out a way to keep the language moving forward.
- WorldWideWayne 12y ago
  I understand what you're saying but I think it also goes to my point - I feel like those handful of people couldn't possibly do as much to get Golang into the mainstream as could a whole company/divisional effort. I honestly don't feel like Google as a company is putting that much effort into Golang and many of their other projects. Remember when they were building Chrome and how quickly they iterated on it? That was awesome to behold! Maybe a slow pace and a smaller user base is better for developing a language, but if that's the case then I guess I'll just wait another decade before really investing time into Golang.

matthewmacleod 12y ago

I think it's rather the height of hubris to accuse your contemporaries of being "ignorant" because they disagree with your assessment of this particular tool. Go is an interesting shift in language design, basically discarding many modern trends and techniques and returning to a much simpler paradigm. It's a totally valid approach with lots of merit — complexity can be a killer. In addition, the concurrency primitives, decent stdlib and tooling make Go pretty great to use in some respects. It's likely to be well-supported for a long time and is a suitable tool for many tasks. On the flipside, using it often feels like a bit of a slog. Error handling is simple (good) but repetitive (bad). Keeping generics out of the language avoids complexity (good) but results in repetitive and awkward code (bad). Lack of features like pattern matching and higher-order functions makes some code irritatingly tedious to read and write. And so on. Point is, it's perfectly valid to look at these decisions and say "I don't like Go because it is missing these features", as much as it's valid to say "The simplicity of Go is a useful feature". Ignorance is not a prerequisite for disagreement. So please have some respect for opinions which differ from your own, and think about offering something a little more constructive than insults.

xkarga00 12y ago
Just a note: Go supports higher-order functions
sesteel 12y ago
I agree, I should have grounded the claim of ignorance in a long list of specific instances or made no comment at all; sometimes less is more. Aside, I use and enjoy languages other than Go; it is simply a tool to solve problems, and I don't want to detract people from using other tools. We all develop opinions with regards to what does and does not work well. I never intended to devalue others' experience or perspective. I was simply pointing out that many people seem to not have suffered through enough bad work experiences to appreciate Go's main feature of simplicity. If you haven't run across horrible, insanely overcomplicated, code written by those that think they are the top 1% intelligence-wise, you might not appreciate Go. Likewise, if you write horrible, insanely overcomplicated, code and think you, yourself, are brilliant, you probably won't appreciate Go. If you only work alone or on small teams and projects, you might not appreciate Go.

gnuvince 12y ago

Simple languages are good, but we should be careful to understand why they are simpler: in many cases, the complexity is simply shifted from the language onto the programmer. Though simplicity of the language is important, I feel that the ability of a language to manage complexity is more important. It is probably one reason why many people (myself included) have some issues with design choices made in Go.

sampo 12y ago
Maybe, if there were several official "levels" defined for complex languages (like Scala). So then a team that wants to keep codebases conceptually simple could decide that they are only using features up to e.g. level 3, anything above is forbidden. And the compiler would support this. A bit like you can select different languages in Dr. Racket http://docs.racket-lang.org/drracket/choose-language.html http://docs.racket-lang.org/drracket/choose-language.html
zik 12y ago
> the complexity is simply shifted from the language onto the programmer. That's not my experience with Go at all - it provides less resistance to getting code written than any other language I can think of offhand.

stcredzero 12y ago

but I don't even pay attention to the negative comments anymore The "not quite a field" of programming, has a famous history of being full of smarmy naysayers being spectacularly wrong. It's no wonder that the few of us who aren't bratty and quickly judgemental tend to become famous and successful. (Nor that a famous blogger once said that everything he needed to know about managing programmers, he learned from the book, "How to Talk to Your Five Year Old.")

coldtea 12y ago

>Go, with its simplicity, is a gift from the generation of masters to today's professionals, but many of today's professionals appear too ignorant to see the wisdom of the language. It's mostly the wisdom of the eighties. Today's professionals have better options.

GFK_of_xmaspast 12y ago

Aerosmith was hot in the 1970s too.