10 ms·

At launch, there was a flurry of attention. Google had produced a new programming language, and everyone was eager to check it out. Some programmers were turned

by ansible 12y ago

At launch, there was a flurry of attention. Google had produced a new programming language, and everyone was eager to check it out. Some programmers were turned off by Go's conservative feature set—at first glance they saw "nothing to see here"... This was totally me. I am very much a programming language aficionado (or maybe just a dilettante), and when I first read about Go, I dismissed it quickly. I'd mostly been using Lua at the time, and didn't really understand what was different with goroutines vs. coroutines. After the initial release, it took us a while to properly communicate the goals and design ethos behind Go. Rob Pike did so eloquently in his 2012 essay Go at Google: Language Design in the Service of Software Engineering and more personally in his blog post Less is exponentially more. Andrew Gerrand's Code that grows with grace (slides) and Go for Gophers (slides) give a more in-depth, technical take on Go's design philosophy. It was Rob Pike's essay that caused me to investigate it again. I have been quite impressed with lots of little details that have been 'fixed' (relative to C) in Go. Such as how variables are declared, the module system, and much more. And I was and continue to be impressed with the associated tooling. I hope that if Go has just one lasting legacy in the history of programming, it will be how it pushed forward people's expectations of what a good language ecosystem should provide.

wyager 12y ago
What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.
- enneff 12y ago
  This talk (mentioned in the article) captures a lot of the value that I see in Go: https://www.youtube.com/watch?v=dKGmK_Z1Zl0 https://www.youtube.com/watch?v=dKGmK_Z1Zl0
- kjksf 12y ago
  You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html http://yager.io/programming/go.html for an example of that line of thinking. Those people won't get Go. Designing a language is not about cramming every feature you can think of. It's about making good trade offs. A trade off is: you get something but you also loose something. I use Go because it made the biggest number of good trade offs. Or to put it differently: I program in Go because when writing code, it irritates me less than other languages. If you want a longer explanation of that: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
  - wcummings 12y ago
    I get the impression some of the folks in the Golang crowd are "Blub" programmers [1]. It's not so much a matter of simplicity and trade-offs as it is a matter of "I don't need things I don't know about", which isn't a good argument to use Golang. [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
    - enneff 12y ago
      Most Go programmers I know, including the language designers themselves, have a lot of experience in more feature rich and expressive languages. What appeals is the simplicity of Go, which gives you a lot less of a language to think about, so you can just think about solving problems instead. “I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creator of Scala. I don't think anyone would accuse Odersky of being a "blub programmer."
      - jeremyjh 12y ago
        Martin has something nice to say about everyone's project. I seriously doubt he likes that a new language was created in 2009 that allows null references. But we'll never hear about it if he doesn't. Still, that doesn't make him a Go programmer.
    - tree_of_item 12y ago
      This is a great way to insult a bunch of people and start a fight. "Beating the averages" is not a very good essay, I don't think you need to drag it in here.
    - timtadh 12y ago
      I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers. Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want that feature. But, I find Go to occupy an extremely practical position in my personal programming language continuum do to its fairly unique mix of features. Note, it is not the features themselves that are unique many languages individually have them. Indeed, they often also include features I miss in Go. Rather, it is the particular mixture which is useful. EDIT: To respond directly to the Blub article. Features pg calls out for LISP: Garbage collection, introduced by Lisp in about 1960, is now widely considered to be a good thing. Runtime typing, ditto, is growing in popularity. Lexical closures, introduced by Lisp in the early 1970s, are now, just barely, on the radar screen. Macros, introduced by Lisp in the mid 1960s, are still terra incognita. Go score card: Garbage Collection [x] Runtime Typing [p]* Lexical Clusures [x] Macros [ ] * Go has some dynamic typing capabilities but nothing like Python or LISP. Many would consider that a "good thing". It partially depends on what you are doing. Go has a 3/4 on the score card of features. Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice. I can't speak for pg, but Go has many fantastic features and is not a Blub. The features which are missing are not, by and large, features of LISP. EDIT 2: To add some more fuel to this fire... pg concludes the article with: During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. Note, he explicitly says here: not all languages are the same. He would worry when a company wanted Python programmers. Why? Because to him Python mixture of features represented a nice chunk of what LISP is providing him. Let's do another score card: Python Score Card Garbage Collection [x] Runtime Typing [x] Lexical Clusures [x] Macros [ ]* * It is somewhat possible through black magic hackery to create an AST level macro in Python. It is messy. It is cool. It's kinda crunky. And I am not sure anyone has ever seriously used this ability. It certainly isn't main stream. Checkout https://github.com/lihaoyi/macropy for inspiration. Norvig agrees with this assessment: http://norvig.com/python-lisp.html http://norvig.com/python-lisp.html . Given that many people are ok with moving from Python to Go <https://www.reddit.com/r/golang/comments/2aup1g/why_are_people_ditching_python_for_go/> https://www.reddit.com/r/golang/comments/2aup1g/why_are_peop... it seems reasonable to conclude that Go is an exceptible replacement for Python. Something no one has concluded about Java (for instance). Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.
- tptacek 12y ago
  That's a reductive summary of goroutines. I don't doubt other languages have competitive features, but let's be clear about what the feature is: * Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time. * Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from goroutine to goroutine. * A data sharing scheme that makes sense with promiscuous threading ("synchronized" data structures often don't, because they'll end up serializing threads) Lots of languages have green threads, but not all these properties. I'm guessing Haskell does? I don't write Haskell, but my impression is that it has everything.
  - lobster_johnson 12y ago
    Erlang has the first two concepts nailed down. I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access. I don't know Haskell's concurrency tools very well, but I believe it can provide much of the same functionality as Erlang, but the whole OTP toolset is missing — just as it is in Go. (Certain aspects of OTP can't be implemented in Go at all without additional changes to language/runtime.)
    - tptacek 12y ago
      Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?
      - jerf 12y ago
        Yes, both in Haskell and Erlang. For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?
- camgunz 12y ago
  The difference is I can read Go code while having no experience with it. Erlang and Haskell are inscrutable to 90% of programmers. If you think this isn't important, I will point out that Rust has been frantically trying to look more like Go and less like garbage in every release. Or, I will also point out that the Elixir project exists, which basically does the same thing for Erlang.
  - pcwalton 12y ago
    Rust is not "frantically trying to look more like Go". There are places where Rust's syntax deliberately differs from that of Go (for example, putting colons between values and types), and that will not change.
- grey-area 12y ago
  What do you think is worthwhile about Go? Simplicity - the main feature is all the interesting things they left out.

by ansible 12y ago

wyager 12y ago

What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.

enneff 12y ago
This talk (mentioned in the article) captures a lot of the value that I see in Go: https://www.youtube.com/watch?v=dKGmK_Z1Zl0 https://www.youtube.com/watch?v=dKGmK_Z1Zl0
kjksf 12y ago
You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html http://yager.io/programming/go.html for an example of that line of thinking. Those people won't get Go. Designing a language is not about cramming every feature you can think of. It's about making good trade offs. A trade off is: you get something but you also loose something. I use Go because it made the biggest number of good trade offs. Or to put it differently: I program in Go because when writing code, it irritates me less than other languages. If you want a longer explanation of that: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
- wcummings 12y ago
  I get the impression some of the folks in the Golang crowd are "Blub" programmers [1]. It's not so much a matter of simplicity and trade-offs as it is a matter of "I don't need things I don't know about", which isn't a good argument to use Golang. [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  - enneff 12y ago
    Most Go programmers I know, including the language designers themselves, have a lot of experience in more feature rich and expressive languages. What appeals is the simplicity of Go, which gives you a lot less of a language to think about, so you can just think about solving problems instead. “I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creator of Scala. I don't think anyone would accuse Odersky of being a "blub programmer."
    - jeremyjh 12y ago
      Martin has something nice to say about everyone's project. I seriously doubt he likes that a new language was created in 2009 that allows null references. But we'll never hear about it if he doesn't. Still, that doesn't make him a Go programmer.
  - tree_of_item 12y ago
    This is a great way to insult a bunch of people and start a fight. "Beating the averages" is not a very good essay, I don't think you need to drag it in here.
  - timtadh 12y ago
    I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers. Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want that feature. But, I find Go to occupy an extremely practical position in my personal programming language continuum do to its fairly unique mix of features. Note, it is not the features themselves that are unique many languages individually have them. Indeed, they often also include features I miss in Go. Rather, it is the particular mixture which is useful. EDIT: To respond directly to the Blub article. Features pg calls out for LISP: Garbage collection, introduced by Lisp in about 1960, is now widely considered to be a good thing. Runtime typing, ditto, is growing in popularity. Lexical closures, introduced by Lisp in the early 1970s, are now, just barely, on the radar screen. Macros, introduced by Lisp in the mid 1960s, are still terra incognita. Go score card: Garbage Collection [x] Runtime Typing [p]* Lexical Clusures [x] Macros [ ] * Go has some dynamic typing capabilities but nothing like Python or LISP. Many would consider that a "good thing". It partially depends on what you are doing. Go has a 3/4 on the score card of features. Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice. I can't speak for pg, but Go has many fantastic features and is not a Blub. The features which are missing are not, by and large, features of LISP. EDIT 2: To add some more fuel to this fire... pg concludes the article with: During the years we worked on Viaweb I read a lot of job descriptions. A new competitor seemed to emerge out of the woodwork every month or so. The first thing I would do, after checking to see if they had a live online demo, was look at their job listings. After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. Note, he explicitly says here: not all languages are the same. He would worry when a company wanted Python programmers. Why? Because to him Python mixture of features represented a nice chunk of what LISP is providing him. Let's do another score card: Python Score Card Garbage Collection [x] Runtime Typing [x] Lexical Clusures [x] Macros [ ]* * It is somewhat possible through black magic hackery to create an AST level macro in Python. It is messy. It is cool. It's kinda crunky. And I am not sure anyone has ever seriously used this ability. It certainly isn't main stream. Checkout https://github.com/lihaoyi/macropy for inspiration. Norvig agrees with this assessment: http://norvig.com/python-lisp.html http://norvig.com/python-lisp.html . Given that many people are ok with moving from Python to Go <https://www.reddit.com/r/golang/comments/2aup1g/why_are_people_ditching_python_for_go/> https://www.reddit.com/r/golang/comments/2aup1g/why_are_peop... it seems reasonable to conclude that Go is an exceptible replacement for Python. Something no one has concluded about Java (for instance). Therefore, I believe pg would have been equally worried or almost as concerned about Go programmers as Python programmers.
tptacek 12y ago
That's a reductive summary of goroutines. I don't doubt other languages have competitive features, but let's be clear about what the feature is: * Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time. * Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from goroutine to goroutine. * A data sharing scheme that makes sense with promiscuous threading ("synchronized" data structures often don't, because they'll end up serializing threads) Lots of languages have green threads, but not all these properties. I'm guessing Haskell does? I don't write Haskell, but my impression is that it has everything.
- lobster_johnson 12y ago
  Erlang has the first two concepts nailed down. I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access. I don't know Haskell's concurrency tools very well, but I believe it can provide much of the same functionality as Erlang, but the whole OTP toolset is missing — just as it is in Go. (Certain aspects of OTP can't be implemented in Go at all without additional changes to language/runtime.)
  - tptacek 12y ago
    Neat. You can start an Erlang process (or whatever they're called) with an anonymous function, and pass it another anonymous function that closes over another lexical environment?
    - jerf 12y ago
      Yes, both in Haskell and Erlang. For me, Go's big win is that I can finally bring this, the right way to do it, to work, because it's the first time this paradigm is present in a conventional imperative language, not that it is the first in general. Many other languages got it right in theory before Go, but there was always some practical stopper, involving some obscure programming paradigm that I stood no chance of getting buy-in on (from engineering or management) or an ecosystem that simply couldn't be reasonably be called production-ready across the set of tasks I needed to accomplish. Go finally gave me almost everything I wanted for work. If it isn't everything, well, that's life sometimes, you know?
camgunz 12y ago
The difference is I can read Go code while having no experience with it. Erlang and Haskell are inscrutable to 90% of programmers. If you think this isn't important, I will point out that Rust has been frantically trying to look more like Go and less like garbage in every release. Or, I will also point out that the Elixir project exists, which basically does the same thing for Erlang.
- pcwalton 12y ago
  Rust is not "frantically trying to look more like Go". There are places where Rust's syntax deliberately differs from that of Go (for example, putting colons between values and types), and that will not change.
grey-area 12y ago
What do you think is worthwhile about Go? Simplicity - the main feature is all the interesting things they left out.