8 ms·

And yet it still feels like a language out of the 60s or 70s. To me, Go feels like the programming language equivalent of insisting that everyone communicate ju

And yet it still feels like a language out of the 60s or 70s. To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting because it's less complex to teach people just grunting than it is to teach them more effective forms of communication. And in theory, they still can communicate all the same things with more grunting! Some people refer to this as simplicity, and in a way it is, but it's simplicity in the language constructs at the expense of more complexity in the usage of the language to form more complex thoughts. There must be a golden balance here, but I don't feel like Go is it for all the fanfare it has been getting lately.

WesternStar 7y ago
This is pretty much how I feel life is just too short to spend it coding in Go.
badrequest 7y ago
Any specific complaints, or did you just feel like calling us all cavedwellers?
- timothycrosley 7y ago
  Most of my complaints, I feel like are pretty well documented: No ability to do Generics, no ability to do operator overloading, no ability to make your own for each style loop objects, very manual and repetitive error handling. These are all simplifications to the language spec at the expense of more complicated usage. For the most part, I've been trying to understand myself how to express why I get a pretty bad taste in my mouth when using or looking at Go code, why it feels so much less productive to me than the higher-level languages. Which is what it has been making dents in more than anything else. I especially wanted to understand this since I do see myself as someone who values simplicity. In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. I'd instead rather learn a slightly more complicated language, and be more productive with every task I write using it. I don't see Go users as cavemen. That was admittedly an exaggeration to express my point clearly.
  - nemo1618 7y ago
    >In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. That's interesting, because to me, Go accomplishes this fairly well. Generics, operator overloading, and custom 'for' loops make it easier to write "clever" code with surprising behavior. Go's design is not elegant like Lisp or Haskell; there are some warts and special cases that exist for pragmatic reasons. But it manages to be simple and effective, which is sadly a rare thing in the modern language landscape, where the mentality seems to be "more features = better language." 90% of Go's value is in what it takes away, rather than what it adds.
    - outworlder 7y ago
      One could make the same argument for Lua.
  - zadokshi 7y ago
    Language designers: Design a language to not use generics. timothycrosley: It doesn't do generics!!! Aaargh!!
    - jeremyjh 7y ago
      Except they didn't. Go has generic maps and slices. It was never their goal to create a language without generics. What happened is they failed to come up with a satisfactory design for user defined generics in time to make Go version 1.
      - zadokshi 7y ago
        Exactly, They didn’t feel it was important. It was not part of the language design. https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
  - badrequest 7y ago
    Cool, here's my take: people who insist on a language supporting generics are lazy and uncreative.
- srparish 7y ago
  + By declaring a field/variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field/variable you need to audit all your code to make sure you haven't broken things. + gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping/unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything. + Scope of element in for-range loop isn't right, so capturing that scope in a lambda does the wrong thing with no warning. + Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map/filter/reduce or comprehensions. + No help from type-system for use of pointer without nil check. + Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man's unique_ptr<> means that I also get optional<> symantics (without the type checking) when I don't want or expect such. Also allows for aliasing when I don't want or expect such. + Difference between '=' and ':=' is silly, especially since ':=' can be used to reassign values. Even more frustrating that ':=' creates shadowing in nested scopes, so doesn't always do what one would expect it would do, such as accidentally creating a shadowed 'err' that doesn't get checked. + if/switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.
  - gameswithgo 7y ago
    I actually like Go's simplicity a lot, it was very easy for me to learn and very easy to programming with it because of that. But I agree strongly with some of your points. = vs := specifically feels like a plain mistake, and even against Go philosophy of having just 1 way to do things. I think any new language should be designed around options instead of nils. F#, Rust, Zig show different ways to do this, and often any performance penalty can be compiled away. if/switch being expressions is a simple and helpful idea, languages should allow this. using map/filter/reduce as the idiomatic way to do things I am less sure about. This can come in handy but also would add a lot of complexity to Go, and in most languages these have a performance penalty. its important to remember that not all programmers are interested in languages, they just want to get their project done. So being able to hop into a code base and have low cognitive overhead, because there are no mysterious features they have to learn, having quick compile times, and explicit semantics can be really helpful there. That can save you more time than typing less because of generics and meta programming sometimes.
- pyrale 7y ago
  Well, I don't subscribe to the deprecating aspect of the grunting stuff, but many of these discussions read very much like transcripts of Plato's cave. I had the same experience as a Java dev back when Java8 came out. To me, it felt great. To people using functional languages which this update ported to Java, it looked poorly. It is hard to understand go's criticism if you have not experienced languages leveraging modern datastructures such as, for instance, union types/pattern matching. But if you have, you really feel like the language lacks something.
  - edflsafoiewq 7y ago
    For me, it's not even things like that. It's boring things like push, pop, erase, index_of, etc. that probably everyone has seen but that can't be written in Go.
    - badrequest 7y ago
      You can write them, you just can't write them generically.
    - virmundi 7y ago
      You can write them but to do so generically you need to do code gen. Unfortunately this means learning a code green template library.
ngrilly 7y ago
> And yet it still feels like a language out of the 60s or 70s. I started programming in the 80s, and Go feels modern even compared to the mainstream languages of this era (mainly BASIC, Pascal and C). It also feels modern compared to the first versions of Java in the 90s. You don't like Go and I respect that, but Go definitely reflects its time, the 2000s, with its syntax, automatic type deduction, GC, gofmt, interfaces, goroutines, closures, built-in HTTP, built-in testing framework, etc.
- flavio81 7y ago
  >but Go definitely reflects its time, the 2000s more like the 60s, with a primitive type system, no metaprogramming, no interactive development, etc.
  - baby 7y ago
    no metaprogramming is a feature. Have you read C++ libraries?
    - hechang1997 7y ago
      C++ template metaprogramming may be overused and very difficult to use, but its prevalence despite such difficulty precisely shows how much such a type level metaprogramming tool is desired (compared to syntax level ones like lisp macros or text level ones like C preprocessor and various code generators). New programming languages should try to improve upon C++ template metaprogramming and make more powerful and effective metaprogramming language constructs, instead of completely abandoning the front.
    - mantap 7y ago
      This is the putting one's head in the sand methodology of programming lanaguge design. Go's answer to metaprogramming is source code generation. There are many problems with C++ but the existence of the template system isn't one.
      - acroback 7y ago
outworlder 7y ago
> And yet it still feels like a language out of the 60s or 70s. Lisp is from that era and is far more poweful. > To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting This is fair. I mean, Go is outright _primitive_. The most notorious things about the language itself: are Goroutines, channels and the interfaces. This is why there is so much discussion around, for instance, Generics. Noone really "wants" Generics. Instead, they just need to not repeat themselves. There are very few ways to work around issues in the language itself. Another issue is that, if a library implements something in a way that doesn't suit you, or you need to add extra behavior, you are out of luck. Say you want to add distributed tracing to code that's not owned by you (even if writting in your company). You'll have to track down people, you cannot "annotate" your way as other languages can. That said, the fact that it is mind-numbly dumb can be a feature. Everything is damn obvious. Error handlers? Staring at you in the face like the sore thumb they are supposed to be. You can't even get too fancy with 'design patterns', just go write the function you need to solve your problem and stop reading that gang of four book. They are fixing the Go modules mess, which is one of the last pieces of the ecosystem. No "coding standards" document – it is whatever go fmt and the go compiler says it is. Lots of trivial things are errors (like unused variables), which helps keep the codebase sane. The ecosystem and toolset are great (I feel like Rust learned from Go and improved on it). Go has to be compared with alternatives. Rust? Awesome language, but slightly different niche with a far higher learning curve. Java? Please. C or C++? They are the opposite of simple (C is a larger language, but with far more baggage, don't get me started on C++). I can't include Python and ilk as their purpose is completely different, although for things like backends both could be used. What else could we use to write Docker or Kubernetes, that would be more expressive, and still learnable in a weekend? > There must be a golden balance here I would argue that Go has not nailed it completely, but it is in the ballpark.
- mynameishere 7y ago
  Lots of trivial things are errors (like unused variables) My learning experience with Go ended when I happened upon this. Unused variables aren't even worth a warning, and yet it is absolutely impossible to get around them in Go. Maybe it's just my style, but I like to start out code with methods and variables in rough outline, and then build it from there. If a language makes that impossible well...there are other languages. Also, I didn't want to learn what other doozies Go had in store if they made that kind of stupid nanny issue a categorical imperative.
classified 7y ago
Google hand-crafted a language with the intention to make the production of code for their most important use cases cheaper. It was never their intention to build the general-purpose PL of the future. But then, you cannot put it this way in your marketing brochure.
- azth 7y ago
  It wasn't "Google", but a handful of employees there. Secondly, they designed or with their perceptions of some of Google's use cases, which may or may have not aligned with the actual use cases. We can see this by how much golang is actually being used at Google for critical components, where C++ and Java still dominate
eloff 7y ago
There's a balance with both expressiveness and type systems. Too little (PHP, JavaScript) is suboptimal, and too much (Scala, Haskell, Rust) is also suboptimal. Please note it depends very much on what you're building, as to where that tradeoff lies. For some things I use Rust. For others I use JavaScript. I don't touch PHP, Java, Scala, or Haskell for anything in the world - you can't practically pay me enough to want to work with them. For me, for web applications and server side software, Go is in the sweet spot more than any other language I've tried, and I've tried almost 30 by now. Go is not always elegant, it's not always the right tool, and sometimes frustrating - but it's incredibly good at enabling better productivity than the alternatives in this niche. Sample size of one, this is my opinion, and other disclaimers apply.
- baldfat 7y ago
  I am getting old and I am also finding I have just settled to languages I feel hit that balance for me. Racket for general programming (It really is the best for people learning to program and also great for making fun programs that is super easy to install on multiple of computers) R for statistics especially since I found the functional backbone of the language. Go for backend work.
- akincisor 7y ago
  > Too little (PHP, JavaScript) is suboptimal, and too much (Scala, Haskell, Rust) is also suboptimal. I find myself thinking the exact opposite. When you want to do something quick and dirty JavaScript or Ruby are my go to. When you want to do something right, do it in Haskell or Rust. The middle of the road options I find are worse for anything. Unless you want to hire big teams. Java, C#, Go are great for that.
  - eloff 7y ago
    I agree about quick and dirty, Python has been my goto there for over a decade. But I find with more complex type systems and more expressive languages (which applies to both Haskell and Rust) I spend too much time thinking of which way in going to code something, what abstractions I'm going to use. Then I spend too long trying to make the compiler happy for decreasing marginal returns in reducing bugs. Then the compiler takes too long every time I want to run it. On top of all that, the tools are subpar. I like Rust, I find it so well thought out and elegant, but I still reach for Go to get things done. All of that makes me considerably less productive. In Go I just use loops, slices, structs, and interfaces. There is usually only one obvious way to do it. It compiles right away, and I get on with my life. It's not as pretty to look at, probably more lines of code, but it takes so much less time. On larger teams having simple, consistently styled code is an understated advantage for code review and understanding the system (which together are probably 3/4 of the job.)
JyB 7y ago
> but I don't feel like Go is it for all the fanfare it has been getting lately. What happens if the 'fanfare' doesn't stop anytime soon? Will you just keep watching from afar that ever growing crowd of grunting and stinky subhumans?
- Skunkleton 7y ago
  > Grunting and stinky subhuman You're just describing me in the morning.
- deleted 7y ago
  [deleted]
rantwasp 7y ago
GUH GUUH
hliyan 7y ago
This is the most remarkable characterization of Go I have ever read. "Grunting" here probably means: short, simple syntactical structures, which as someone who has coded in BASIC, C++, Java, Python, JavaScript for over a decade, I feel is a positive. The syntax of the language gets out of the way so that programmer brainpower can focus on the logic. The best tool is one that feels like it's not even there. The author here is clearly offended by Go, but the real reasons remain unclear...
baby 7y ago
Really? Golang feels like the most evolved non-system language out there to me, perhaps with Swift. Everything works out-of-the-box, it has tooling for formatting, building, getting dependencies, generating docs, and so on. Its standard library is the most feature-complete and the most impressive standard library I've seen in any programming language. Code written in Golang is always a pleasure to read.
theonemind 7y ago
Most "corporate" languages have that character (as opposed to hacker languages that give you expressiveness and power). Go looks pretty good for a corporate language. I haven't looked at Go because...my corporation doesn't really use Go. :shrugs:. I don't understand why anyone would get personally excited about it unless it gives them a breath of fresh air from the worse languages they have to deal with, like as an officially-sanctioned second language where they work, or they just don't look at languages very much.
aminotaa 7y ago
And yet instead of celebrating the platform that gave us the most advanced frameworks in decades you choose to peddle your sad negativity.
- timothycrosley 7y ago
  What is that platform? Are you considering Go a platform, or something that was built with it (like Docker)? And what are the frameworks you consider to be the most advanced in decades?

WesternStar 7y ago

This is pretty much how I feel life is just too short to spend it coding in Go.

badrequest 7y ago

Any specific complaints, or did you just feel like calling us all cavedwellers?

timothycrosley 7y ago
Most of my complaints, I feel like are pretty well documented: No ability to do Generics, no ability to do operator overloading, no ability to make your own for each style loop objects, very manual and repetitive error handling. These are all simplifications to the language spec at the expense of more complicated usage. For the most part, I've been trying to understand myself how to express why I get a pretty bad taste in my mouth when using or looking at Go code, why it feels so much less productive to me than the higher-level languages. Which is what it has been making dents in more than anything else. I especially wanted to understand this since I do see myself as someone who values simplicity. In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. I'd instead rather learn a slightly more complicated language, and be more productive with every task I write using it. I don't see Go users as cavemen. That was admittedly an exaggeration to express my point clearly.
- nemo1618 7y ago
  >In the end, it's because I value simplicity in usage, rather than the simplicity be in the language constructs. That's interesting, because to me, Go accomplishes this fairly well. Generics, operator overloading, and custom 'for' loops make it easier to write "clever" code with surprising behavior. Go's design is not elegant like Lisp or Haskell; there are some warts and special cases that exist for pragmatic reasons. But it manages to be simple and effective, which is sadly a rare thing in the modern language landscape, where the mentality seems to be "more features = better language." 90% of Go's value is in what it takes away, rather than what it adds.
  - outworlder 7y ago
    One could make the same argument for Lua.
- zadokshi 7y ago
  Language designers: Design a language to not use generics. timothycrosley: It doesn't do generics!!! Aaargh!!
  - jeremyjh 7y ago
    Except they didn't. Go has generic maps and slices. It was never their goal to create a language without generics. What happened is they failed to come up with a satisfactory design for user defined generics in time to make Go version 1.
    - zadokshi 7y ago
      Exactly, They didn’t feel it was important. It was not part of the language design. https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- badrequest 7y ago
  Cool, here's my take: people who insist on a language supporting generics are lazy and uncreative.
srparish 7y ago
+ By declaring a field/variable []Thing vs []*Thing you get different for loop semantics. Way to easy to think your mutating the array item, but only mutating a local copy or vice versa. If you change the field/variable you need to audit all your code to make sure you haven't broken things. + gofmt feels way out of date. These days clang-format (c++), prettier (typescript), black (python), scalafmt (scala) take care of wrapping/unwrapping lines such as function definitions or function calls. They basically cover all formatting needs so you never have to manually format anything. + Scope of element in for-range loop isn't right, so capturing that scope in a lambda does the wrong thing with no warning. + Encourages use of indexes; which is error prone, most modern languages allow writing most code without needing indexes using map/filter/reduce or comprehensions. + No help from type-system for use of pointer without nil check. + Very easy to get nils in places one would hope to be able to prohibit them in. EG Using pointer as a poor man's unique_ptr<> means that I also get optional<> symantics (without the type checking) when I don't want or expect such. Also allows for aliasing when I don't want or expect such. + Difference between '=' and ':=' is silly, especially since ':=' can be used to reassign values. Even more frustrating that ':=' creates shadowing in nested scopes, so doesn't always do what one would expect it would do, such as accidentally creating a shadowed 'err' that doesn't get checked. + if/switch should be allowed to be expressions, allowing much safer single-expression initialization of variables, rather then requiring default initialization and mutation, which is much easier to get wrong.
- gameswithgo 7y ago
  I actually like Go's simplicity a lot, it was very easy for me to learn and very easy to programming with it because of that. But I agree strongly with some of your points. = vs := specifically feels like a plain mistake, and even against Go philosophy of having just 1 way to do things. I think any new language should be designed around options instead of nils. F#, Rust, Zig show different ways to do this, and often any performance penalty can be compiled away. if/switch being expressions is a simple and helpful idea, languages should allow this. using map/filter/reduce as the idiomatic way to do things I am less sure about. This can come in handy but also would add a lot of complexity to Go, and in most languages these have a performance penalty. its important to remember that not all programmers are interested in languages, they just want to get their project done. So being able to hop into a code base and have low cognitive overhead, because there are no mysterious features they have to learn, having quick compile times, and explicit semantics can be really helpful there. That can save you more time than typing less because of generics and meta programming sometimes.
pyrale 7y ago
Well, I don't subscribe to the deprecating aspect of the grunting stuff, but many of these discussions read very much like transcripts of Plato's cave. I had the same experience as a Java dev back when Java8 came out. To me, it felt great. To people using functional languages which this update ported to Java, it looked poorly. It is hard to understand go's criticism if you have not experienced languages leveraging modern datastructures such as, for instance, union types/pattern matching. But if you have, you really feel like the language lacks something.
- edflsafoiewq 7y ago
  For me, it's not even things like that. It's boring things like push, pop, erase, index_of, etc. that probably everyone has seen but that can't be written in Go.
  - badrequest 7y ago
    You can write them, you just can't write them generically.
  - virmundi 7y ago
    You can write them but to do so generically you need to do code gen. Unfortunately this means learning a code green template library.

ngrilly 7y ago

> And yet it still feels like a language out of the 60s or 70s. I started programming in the 80s, and Go feels modern even compared to the mainstream languages of this era (mainly BASIC, Pascal and C). It also feels modern compared to the first versions of Java in the 90s. You don't like Go and I respect that, but Go definitely reflects its time, the 2000s, with its syntax, automatic type deduction, GC, gofmt, interfaces, goroutines, closures, built-in HTTP, built-in testing framework, etc.

flavio81 7y ago
>but Go definitely reflects its time, the 2000s more like the 60s, with a primitive type system, no metaprogramming, no interactive development, etc.
- baby 7y ago
  no metaprogramming is a feature. Have you read C++ libraries?
  - hechang1997 7y ago
    C++ template metaprogramming may be overused and very difficult to use, but its prevalence despite such difficulty precisely shows how much such a type level metaprogramming tool is desired (compared to syntax level ones like lisp macros or text level ones like C preprocessor and various code generators). New programming languages should try to improve upon C++ template metaprogramming and make more powerful and effective metaprogramming language constructs, instead of completely abandoning the front.
  - mantap 7y ago
    This is the putting one's head in the sand methodology of programming lanaguge design. Go's answer to metaprogramming is source code generation. There are many problems with C++ but the existence of the template system isn't one.
    - acroback 7y ago

outworlder 7y ago

> And yet it still feels like a language out of the 60s or 70s. Lisp is from that era and is far more poweful. > To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting This is fair. I mean, Go is outright _primitive_. The most notorious things about the language itself: are Goroutines, channels and the interfaces. This is why there is so much discussion around, for instance, Generics. Noone really "wants" Generics. Instead, they just need to not repeat themselves. There are very few ways to work around issues in the language itself. Another issue is that, if a library implements something in a way that doesn't suit you, or you need to add extra behavior, you are out of luck. Say you want to add distributed tracing to code that's not owned by you (even if writting in your company). You'll have to track down people, you cannot "annotate" your way as other languages can. That said, the fact that it is mind-numbly dumb can be a feature. Everything is damn obvious. Error handlers? Staring at you in the face like the sore thumb they are supposed to be. You can't even get too fancy with 'design patterns', just go write the function you need to solve your problem and stop reading that gang of four book. They are fixing the Go modules mess, which is one of the last pieces of the ecosystem. No "coding standards" document – it is whatever go fmt and the go compiler says it is. Lots of trivial things are errors (like unused variables), which helps keep the codebase sane. The ecosystem and toolset are great (I feel like Rust learned from Go and improved on it). Go has to be compared with alternatives. Rust? Awesome language, but slightly different niche with a far higher learning curve. Java? Please. C or C++? They are the opposite of simple (C is a larger language, but with far more baggage, don't get me started on C++). I can't include Python and ilk as their purpose is completely different, although for things like backends both could be used. What else could we use to write Docker or Kubernetes, that would be more expressive, and still learnable in a weekend? > There must be a golden balance here I would argue that Go has not nailed it completely, but it is in the ballpark.

mynameishere 7y ago
Lots of trivial things are errors (like unused variables) My learning experience with Go ended when I happened upon this. Unused variables aren't even worth a warning, and yet it is absolutely impossible to get around them in Go. Maybe it's just my style, but I like to start out code with methods and variables in rough outline, and then build it from there. If a language makes that impossible well...there are other languages. Also, I didn't want to learn what other doozies Go had in store if they made that kind of stupid nanny issue a categorical imperative.

classified 7y ago

Google hand-crafted a language with the intention to make the production of code for their most important use cases cheaper. It was never their intention to build the general-purpose PL of the future. But then, you cannot put it this way in your marketing brochure.

azth 7y ago
It wasn't "Google", but a handful of employees there. Secondly, they designed or with their perceptions of some of Google's use cases, which may or may have not aligned with the actual use cases. We can see this by how much golang is actually being used at Google for critical components, where C++ and Java still dominate

eloff 7y ago

There's a balance with both expressiveness and type systems. Too little (PHP, JavaScript) is suboptimal, and too much (Scala, Haskell, Rust) is also suboptimal. Please note it depends very much on what you're building, as to where that tradeoff lies. For some things I use Rust. For others I use JavaScript. I don't touch PHP, Java, Scala, or Haskell for anything in the world - you can't practically pay me enough to want to work with them. For me, for web applications and server side software, Go is in the sweet spot more than any other language I've tried, and I've tried almost 30 by now. Go is not always elegant, it's not always the right tool, and sometimes frustrating - but it's incredibly good at enabling better productivity than the alternatives in this niche. Sample size of one, this is my opinion, and other disclaimers apply.

baldfat 7y ago
I am getting old and I am also finding I have just settled to languages I feel hit that balance for me. Racket for general programming (It really is the best for people learning to program and also great for making fun programs that is super easy to install on multiple of computers) R for statistics especially since I found the functional backbone of the language. Go for backend work.
akincisor 7y ago
> Too little (PHP, JavaScript) is suboptimal, and too much (Scala, Haskell, Rust) is also suboptimal. I find myself thinking the exact opposite. When you want to do something quick and dirty JavaScript or Ruby are my go to. When you want to do something right, do it in Haskell or Rust. The middle of the road options I find are worse for anything. Unless you want to hire big teams. Java, C#, Go are great for that.
- eloff 7y ago
  I agree about quick and dirty, Python has been my goto there for over a decade. But I find with more complex type systems and more expressive languages (which applies to both Haskell and Rust) I spend too much time thinking of which way in going to code something, what abstractions I'm going to use. Then I spend too long trying to make the compiler happy for decreasing marginal returns in reducing bugs. Then the compiler takes too long every time I want to run it. On top of all that, the tools are subpar. I like Rust, I find it so well thought out and elegant, but I still reach for Go to get things done. All of that makes me considerably less productive. In Go I just use loops, slices, structs, and interfaces. There is usually only one obvious way to do it. It compiles right away, and I get on with my life. It's not as pretty to look at, probably more lines of code, but it takes so much less time. On larger teams having simple, consistently styled code is an understated advantage for code review and understanding the system (which together are probably 3/4 of the job.)

JyB 7y ago

> but I don't feel like Go is it for all the fanfare it has been getting lately. What happens if the 'fanfare' doesn't stop anytime soon? Will you just keep watching from afar that ever growing crowd of grunting and stinky subhumans?

Skunkleton 7y ago
> Grunting and stinky subhuman You're just describing me in the morning.
deleted 7y ago
[deleted]

rantwasp 7y ago

GUH GUUH

hliyan 7y ago

This is the most remarkable characterization of Go I have ever read. "Grunting" here probably means: short, simple syntactical structures, which as someone who has coded in BASIC, C++, Java, Python, JavaScript for over a decade, I feel is a positive. The syntax of the language gets out of the way so that programmer brainpower can focus on the logic. The best tool is one that feels like it's not even there. The author here is clearly offended by Go, but the real reasons remain unclear...

baby 7y ago

Really? Golang feels like the most evolved non-system language out there to me, perhaps with Swift. Everything works out-of-the-box, it has tooling for formatting, building, getting dependencies, generating docs, and so on. Its standard library is the most feature-complete and the most impressive standard library I've seen in any programming language. Code written in Golang is always a pleasure to read.

theonemind 7y ago

Most "corporate" languages have that character (as opposed to hacker languages that give you expressiveness and power). Go looks pretty good for a corporate language. I haven't looked at Go because...my corporation doesn't really use Go. :shrugs:. I don't understand why anyone would get personally excited about it unless it gives them a breath of fresh air from the worse languages they have to deal with, like as an officially-sanctioned second language where they work, or they just don't look at languages very much.

aminotaa 7y ago

And yet instead of celebrating the platform that gave us the most advanced frameworks in decades you choose to peddle your sad negativity.

timothycrosley 7y ago
What is that platform? Are you considering Go a platform, or something that was built with it (like Docker)? And what are the frameworks you consider to be the most advanced in decades?