10 ms·

It would be kind of a fun experiment to require a rough estimate of LoC written in a given language be included in feedback about that language. These comments

It would be kind of a fun experiment to require a rough estimate of LoC written in a given language be included in feedback about that language. These comments are kind of a cesspool of poorly written feedback that wraps ambiguous complaints about "readability", "maintenance" and even the silly take of "Go is a language for engineering managers", whatever that means. I suspect most of the negative comments on any language come from people that have spent practically no time writing it, and thus are inherently uninformed. Of course, if you hate a language, you're not going to write lots of code in it (unless you have to, and then I would expect your feedback to be pretty negative but at least informed). Feedback from beginners/programmers external to a language is super important for the success of that language of course, but lots of debates about things like programming language are cluttered with feedback that isn't really made in good faith. Someone that doesn't like static typing is going to leave feedback about Go that may not directly say "I just don't like static typing", but ultimately is as simple to reconcile (and thus, should mostly be discarded).

byronr 5y ago
I have written hundreds of thousands of lines of plain old C, as well hundreds of thousands of lines of Go over a career spanning three decades. I've used Go in earnest since 2013. I would pick Go for any large project in a heartbeat. I have to concur that the haters who post to HN probably have never used this language in earnest. Here's what you get out of the box: * Extensive standard library * Cheap concurrency * Fast compilation * Built-in test/benchmark framework, including coverage and race detection * Built-in heap and CPU profiling Of all the complaints the one I understand the least is the reservations about performance. It is within 10-20% of C, and callouts to C and assembly are possible. (My 8-way multiplexed MD5 routine was written in AVX assembler and lives on in minio.) Extracting that last 10-20% is two or three sigmas away from the norm of how programming languages are used these days. The objection to generics is similar. The lack of generics shows up -- once in a long while. It doesn't prevent me from being immensely productive with this language. Looking back at the last few years I've wondered if I could have accomplished what I did in Go by using a different language (C in particular) and the answer, for me, is "not a chance".
- auxym 5y ago
  Sincere question out of curiosity, since I have not been exposed to Go at all. How do container types, like arrays or hashmaps work without generics? Do you basically have to declare and implement types/methods for each different contained type?
  - jimsmart 5y ago
    Arrays/slices and maps are in fact provided as built-ins that function like generics, e.g. []foo and map[foo]bar work as expected, as do associated helper methods. But those are the only container types with built-in support like that. (Channels can similarly be of any type)
  - zeugmasyllepsis 5y ago
    Go supports a handful of built-in generic types, like hashmaps. What Go currently lacks is user-defined generics, though that is actively being worked on.
  - tptacek 5y ago
    Roughly the same way containers work in Python.
    - dragonwriter 5y ago
      > Roughly the same way containers work in Python. That’s not really true, since built-in containers are special sui generis generics in Go, whereas in an untyped python they get by being untyped, and in python’s statically-checked type system (as implemented in pyright, mypy, etc.) they use general-purpose generics.
      - tptacek 5y ago
        That complaint is as old as the language --- the first piece about Go I ever read, after my friend Yan convinced me to pick up Go, called it out for having "generics for me and no generics for thee". I've never understood why I'm meant to care. I get, if you want to write your own generic containers, being irritated that there aren't universally available generics (yet). I don't get being upset that the language has some special-cased generics. It's not personal. They're not rubbing salt in your wounds. They just need a map type that works. At any rate: the person asking the question is wondering how you manage to have performant containers with reasonable interfaces in a language without generics. That's a good question! If you've worked a lot in C, you might be imagining a horrible mess of void-stars or something. But no, the ergonomics are basically those of Python, with extra typing.
eptcyka 5y ago
I have spent 3 years being employed to write Go, and i think the language is abhorrent. Once I moved to a job where I didn't need to write Go, I quit smoking.
- void_mint 5y ago
  I appreciate you adding context to your negative comment. I wouldn't really call it feedback, though, as you kinda just said "I hate it" a couple different ways. What didn't you like about it?
- tcbasche 5y ago
  Can you elaborate on why?
  - eptcyka 5y ago
    Writing code that does a lot of IO gets very repetetive quick - `if err != nil` is just stupid. Different libraries have different conventions on matching on errors. Then there's the inability to know if an interface pointer is valid. Comments that change the way the code is built. The type system felt like it was forcing me to expose either interfaces that are either too restrictive or too open.
    - yaml-ops-guy 5y ago
      So the whole "quitting smoking" thing was...a happy coincidence? Did you go cold turkey? What were the nicotine withdrawal nightmares like? I had fierce ones when I quit
      - eptcyka 5y ago
        Switching jobs helped a lot. Not writing Go, I think definitely helped.
- terminenzio 5y ago
  At least it's not JS, the modern stack is awful and I miss the times when we used jquery and everything worked in IE6 with 2MB of RAM
coryrc 5y ago
Go's domain is CRUD microservices, for which abstraction is generally distraction. If that's all you use it for, of course you are going to like it.
- void_mint 5y ago
  Any chance you could humor me (per my original post) and describe your professional/working relationship with Go?
  - coryrc 5y ago
    Been primarily using it for two years at Google as IC.
    - void_mint 5y ago
      Thanks.
    - catillac 5y ago
      That’s true, but you appear to be a test engineer at Google. Absolutely nothing wrong with that, but it’s also not the same as writing large scale services in Go so I don’t think the experiences are suuuuuper overlapping. I’m a designer and have worked at Google and seen lots of this first hand.
      - deleted 5y ago
        [deleted]
      - coryrc 5y ago
        I didn't claim to be writing large scale services? I'm on the team with people who are though. The code I write is adjacent: refactoring the tests so they run faster with less flakiness (guess what Go makes extremely annoying: mocking concrete types from dependencies! You must either wrap it in your own code (and continuously, manually, maintain that abstraction), give up, or alter the upstream) and writing internal services and tools. Tools are primarily in Go so we can share libraries.
latte 5y ago
My experience in Go in production is limited to ~150 lines of code I wrote to contribute a small feature for one Terraform provider. The provider in question is a very thin wrapper over an API library. The feature I added contained almost no business logic of its own and would probably take 15-20 lines in a more expressive language. Based on that experience, I would not choose Go for a project of my own (unless it could directly benefit from Go's strengths, i.e. unless it required fast startup, portability and concurrency).
- void_mint 5y ago
  Thanks a lot for responding. This is a pretty good example of feedback provided by language novices. You have almost no experience with the language, complained about an aspect of it (line count), and then said you wouldn't use it again, unless you would (as you defined in your closing parens). I'm not trying to diminish your feedback at all. You like what you like, don't what you don't like, etc. Nobody is forcing otherwise. It's just an interesting pattern that you can see with parallels in almost any language. Much like when novice Clojurists say "I wouldn't use Clojure because of all the parens" - there are things that, for most novice+ users, just kind of end up not mattering a ton. The things inexperienced users think are a big deal (in your example, line count) usually end up not being a big deal.
  - cy_hauser 5y ago
    Infix notation with all the parens is the primary reason I never got comfortable with the lisps. My mind never worked like that. So I really believe there are valid personal preferences that keep people from liking languages right from the start. (I loved forth though. My mind took to it immediately.)
    - void_mint 5y ago
      Sorry, in my post I never said or implied that having personal reasons for not liking something was invalid. Distinctly the opposite. The point I was making is mostly that not liking something doesn't mean it is less functional or successful. The parens in clojure are something to acclimate to, not a forever debt. But time and time again you'll see posts discounting the entire language because of them. Much the same with Go and lack of generics/verbosity.
Supermancho 5y ago
I wrote 5000 lines of java for a simple multi-user chat room server. I had a separate Java client. I replaced the server with half a page (~200 lines of Erlang) as my first attempt at using Erlang with the exact same functionality. I still write copious amounts of Java for work and Java is still horrid.
- winrid 5y ago
  Curious, got a link to source? Using an existing websocket library, that chat client, with multithreading, should be a handful of lines in Java. Even writing the raw socket handling yourself, with multithreading, should only be a few classes and maybe 500 lines...
ChrisMarshallNY 5y ago
I’ve not used Go, so I have no opinion. I know some folks that really like it, though, and I respect their opinion. Same with Rust. I programmed PHP for twenty years (not full-time). I never learned to like the language, but got fairly good at it. I now program pretty much exclusively in Swift. It is full-time. I’ve been writing it since it was announced. I like Swift quite a bit. One of the things that I’ve learned, is that there aren’t actually that many shops that have done industrial-scale Swift projects. Lots of people have done fairly small ones, but very few really big ones (like you will find with ObjC). Writing a half million lines in any language gives you some authority.
- void_mint 5y ago
  > Writing a half million lines in any language gives you some authority. Totally. In this blog post, Khan Academy says "It is performant enough for us and our team likes it". In this comment section, there are people insisting it's a bad language while having never used it. Not just "Haven't used it at that scale". Legitimately have never written a line of Go. This is part of why I made my post, to try to highlight the silliness of a lot of the "feedback" being slung around.
  - ModernMech 5y ago
    At the same time, I would expect the people who like it the least to have written on average fewer lines of code in Go than people who like it. It's probably like that for most languages; people tend to not heavily use tools they don't like. I've written some Go, but I have enough experience with enough languages to know I wouldn't like it any more if I were to use it more.
    - void_mint 5y ago
      "I don't like it" != "It is bad"
      - ModernMech 5y ago
        "I don't like it" == "It is a bad tool for me". That's about all anyone ever means when they call something bad. Or it's at least all they can mean. I just think you can have a valid and informed opinion of some tool without having written 500k lines in it.
fmakunbound 5y ago
It was a fluff piece, but I’m curious if the author could give a LoC with Go’s ubiquitous, hard-coded control structure line count removed? if err != nil { return err }
- dangoor 5y ago
  That structure is about 7% of our lines of code.
  - fmakunbound 5y ago
    Dang.
unscaled 5y ago
I find your characterization of critica of Go, highly uncharitable, but unfortunately all too common with Go apologetics. If we look outside of Go, I see a lot of criticism of C++, Java, PHP and Node.js, but I rarely see the critics being attacked with "You just didn't write enough C++ code" to qualify for a critic license. I find this approach hypocritical. For what it's worth, I wrote several software systems in Go, and deployed them in production. At least one of them is serving millions of daily active users. Some things I'm happy about (and these were my reasons to use Go in the first place), like: 1. No JIT = no warmup 2. Portable static binaries 3. Solid tooling 4. (Mostly) high quality static library What I really find frustrating in Go is not the verbosity (Rust is probably equally verbose, and I get over that), but the utter lack of type safety. You see, most critics of Go (definitely the people complaining about lack of genrics), DO NOT complain about static typing. In fact, I don't remember ever seeing anyone complain about that. What people often complain about is _not enough static typing_. Due to lack of genrics and other limitations of the language, Go essentially forces you to use empty intrrfaces, stringly-typed data, weak enums and runtime type checks all over the place. This leads to fragile code, and makes it very hard to have the same safety guarantees you could have in Java - let alone in a more FP-oriented language like Rust or Haskell.
- void_mint 5y ago
  > I find your characterization of critica of Go, highly uncharitable, but unfortunately all too common with Go apologetics. I might suggest that if you're the type to use the phrase "Go apologetics", you misinterpreted my post and also emit uncharitable feedback quite often :) > If we look outside of Go, I see a lot of criticism of C++, Java, PHP and Node.js, but I rarely see the critics being attacked with "You just didn't write enough C++ code" to qualify for a critic license. I find this approach hypocritical. If you scroll up, you'll find my request was simply to include the level of involvement a programmer has with a given language as part of their critique. Critique away! But as with all things, when novices critique things they don't understand, they're mostly just being negative for negativity's sake. Go into a C++ space and include "I've never written C++", followed by any criticism and let me know how serious your criticisms are taken. I can wait :) > Due to lack of genrics and other limitations of the language, Go essentially forces you to use empty intrrfaces, stringly-typed data, weak enums and runtime type checks all over the place. This leads to fragile code, and makes it very hard to have the same safety guarantees you could have in Java - let alone in a more FP-oriented language like Rust or Haskell. We can disagree - the purpose of my post was not to prove Go was a "good" language or not. These bits of feedback sound like you're following antipatterns, but you're welcome to program in Go however you'd like.

byronr 5y ago

I have written hundreds of thousands of lines of plain old C, as well hundreds of thousands of lines of Go over a career spanning three decades. I've used Go in earnest since 2013. I would pick Go for any large project in a heartbeat. I have to concur that the haters who post to HN probably have never used this language in earnest. Here's what you get out of the box: * Extensive standard library * Cheap concurrency * Fast compilation * Built-in test/benchmark framework, including coverage and race detection * Built-in heap and CPU profiling Of all the complaints the one I understand the least is the reservations about performance. It is within 10-20% of C, and callouts to C and assembly are possible. (My 8-way multiplexed MD5 routine was written in AVX assembler and lives on in minio.) Extracting that last 10-20% is two or three sigmas away from the norm of how programming languages are used these days. The objection to generics is similar. The lack of generics shows up -- once in a long while. It doesn't prevent me from being immensely productive with this language. Looking back at the last few years I've wondered if I could have accomplished what I did in Go by using a different language (C in particular) and the answer, for me, is "not a chance".

auxym 5y ago
Sincere question out of curiosity, since I have not been exposed to Go at all. How do container types, like arrays or hashmaps work without generics? Do you basically have to declare and implement types/methods for each different contained type?
- jimsmart 5y ago
  Arrays/slices and maps are in fact provided as built-ins that function like generics, e.g. []foo and map[foo]bar work as expected, as do associated helper methods. But those are the only container types with built-in support like that. (Channels can similarly be of any type)
- zeugmasyllepsis 5y ago
  Go supports a handful of built-in generic types, like hashmaps. What Go currently lacks is user-defined generics, though that is actively being worked on.
- tptacek 5y ago
  Roughly the same way containers work in Python.
  - dragonwriter 5y ago
    > Roughly the same way containers work in Python. That’s not really true, since built-in containers are special sui generis generics in Go, whereas in an untyped python they get by being untyped, and in python’s statically-checked type system (as implemented in pyright, mypy, etc.) they use general-purpose generics.
    - tptacek 5y ago
      That complaint is as old as the language --- the first piece about Go I ever read, after my friend Yan convinced me to pick up Go, called it out for having "generics for me and no generics for thee". I've never understood why I'm meant to care. I get, if you want to write your own generic containers, being irritated that there aren't universally available generics (yet). I don't get being upset that the language has some special-cased generics. It's not personal. They're not rubbing salt in your wounds. They just need a map type that works. At any rate: the person asking the question is wondering how you manage to have performant containers with reasonable interfaces in a language without generics. That's a good question! If you've worked a lot in C, you might be imagining a horrible mess of void-stars or something. But no, the ergonomics are basically those of Python, with extra typing.

eptcyka 5y ago

I have spent 3 years being employed to write Go, and i think the language is abhorrent. Once I moved to a job where I didn't need to write Go, I quit smoking.

void_mint 5y ago
I appreciate you adding context to your negative comment. I wouldn't really call it feedback, though, as you kinda just said "I hate it" a couple different ways. What didn't you like about it?
tcbasche 5y ago
Can you elaborate on why?
- eptcyka 5y ago
  Writing code that does a lot of IO gets very repetetive quick - `if err != nil` is just stupid. Different libraries have different conventions on matching on errors. Then there's the inability to know if an interface pointer is valid. Comments that change the way the code is built. The type system felt like it was forcing me to expose either interfaces that are either too restrictive or too open.
  - yaml-ops-guy 5y ago
    So the whole "quitting smoking" thing was...a happy coincidence? Did you go cold turkey? What were the nicotine withdrawal nightmares like? I had fierce ones when I quit
    - eptcyka 5y ago
      Switching jobs helped a lot. Not writing Go, I think definitely helped.
terminenzio 5y ago
At least it's not JS, the modern stack is awful and I miss the times when we used jquery and everything worked in IE6 with 2MB of RAM

coryrc 5y ago

Go's domain is CRUD microservices, for which abstraction is generally distraction. If that's all you use it for, of course you are going to like it.

void_mint 5y ago
Any chance you could humor me (per my original post) and describe your professional/working relationship with Go?
- coryrc 5y ago
  Been primarily using it for two years at Google as IC.
  - void_mint 5y ago
    Thanks.
  - catillac 5y ago
    That’s true, but you appear to be a test engineer at Google. Absolutely nothing wrong with that, but it’s also not the same as writing large scale services in Go so I don’t think the experiences are suuuuuper overlapping. I’m a designer and have worked at Google and seen lots of this first hand.
    - deleted 5y ago
      [deleted]
    - coryrc 5y ago
      I didn't claim to be writing large scale services? I'm on the team with people who are though. The code I write is adjacent: refactoring the tests so they run faster with less flakiness (guess what Go makes extremely annoying: mocking concrete types from dependencies! You must either wrap it in your own code (and continuously, manually, maintain that abstraction), give up, or alter the upstream) and writing internal services and tools. Tools are primarily in Go so we can share libraries.

latte 5y ago

My experience in Go in production is limited to ~150 lines of code I wrote to contribute a small feature for one Terraform provider. The provider in question is a very thin wrapper over an API library. The feature I added contained almost no business logic of its own and would probably take 15-20 lines in a more expressive language. Based on that experience, I would not choose Go for a project of my own (unless it could directly benefit from Go's strengths, i.e. unless it required fast startup, portability and concurrency).

void_mint 5y ago
Thanks a lot for responding. This is a pretty good example of feedback provided by language novices. You have almost no experience with the language, complained about an aspect of it (line count), and then said you wouldn't use it again, unless you would (as you defined in your closing parens). I'm not trying to diminish your feedback at all. You like what you like, don't what you don't like, etc. Nobody is forcing otherwise. It's just an interesting pattern that you can see with parallels in almost any language. Much like when novice Clojurists say "I wouldn't use Clojure because of all the parens" - there are things that, for most novice+ users, just kind of end up not mattering a ton. The things inexperienced users think are a big deal (in your example, line count) usually end up not being a big deal.
- cy_hauser 5y ago
  Infix notation with all the parens is the primary reason I never got comfortable with the lisps. My mind never worked like that. So I really believe there are valid personal preferences that keep people from liking languages right from the start. (I loved forth though. My mind took to it immediately.)
  - void_mint 5y ago
    Sorry, in my post I never said or implied that having personal reasons for not liking something was invalid. Distinctly the opposite. The point I was making is mostly that not liking something doesn't mean it is less functional or successful. The parens in clojure are something to acclimate to, not a forever debt. But time and time again you'll see posts discounting the entire language because of them. Much the same with Go and lack of generics/verbosity.

Supermancho 5y ago

I wrote 5000 lines of java for a simple multi-user chat room server. I had a separate Java client. I replaced the server with half a page (~200 lines of Erlang) as my first attempt at using Erlang with the exact same functionality. I still write copious amounts of Java for work and Java is still horrid.

winrid 5y ago
Curious, got a link to source? Using an existing websocket library, that chat client, with multithreading, should be a handful of lines in Java. Even writing the raw socket handling yourself, with multithreading, should only be a few classes and maybe 500 lines...

ChrisMarshallNY 5y ago

I’ve not used Go, so I have no opinion. I know some folks that really like it, though, and I respect their opinion. Same with Rust. I programmed PHP for twenty years (not full-time). I never learned to like the language, but got fairly good at it. I now program pretty much exclusively in Swift. It is full-time. I’ve been writing it since it was announced. I like Swift quite a bit. One of the things that I’ve learned, is that there aren’t actually that many shops that have done industrial-scale Swift projects. Lots of people have done fairly small ones, but very few really big ones (like you will find with ObjC). Writing a half million lines in any language gives you some authority.

void_mint 5y ago
> Writing a half million lines in any language gives you some authority. Totally. In this blog post, Khan Academy says "It is performant enough for us and our team likes it". In this comment section, there are people insisting it's a bad language while having never used it. Not just "Haven't used it at that scale". Legitimately have never written a line of Go. This is part of why I made my post, to try to highlight the silliness of a lot of the "feedback" being slung around.
- ModernMech 5y ago
  At the same time, I would expect the people who like it the least to have written on average fewer lines of code in Go than people who like it. It's probably like that for most languages; people tend to not heavily use tools they don't like. I've written some Go, but I have enough experience with enough languages to know I wouldn't like it any more if I were to use it more.
  - void_mint 5y ago
    "I don't like it" != "It is bad"
    - ModernMech 5y ago
      "I don't like it" == "It is a bad tool for me". That's about all anyone ever means when they call something bad. Or it's at least all they can mean. I just think you can have a valid and informed opinion of some tool without having written 500k lines in it.

fmakunbound 5y ago

It was a fluff piece, but I’m curious if the author could give a LoC with Go’s ubiquitous, hard-coded control structure line count removed? if err != nil { return err }

dangoor 5y ago
That structure is about 7% of our lines of code.
- fmakunbound 5y ago
  Dang.

unscaled 5y ago

I find your characterization of critica of Go, highly uncharitable, but unfortunately all too common with Go apologetics. If we look outside of Go, I see a lot of criticism of C++, Java, PHP and Node.js, but I rarely see the critics being attacked with "You just didn't write enough C++ code" to qualify for a critic license. I find this approach hypocritical. For what it's worth, I wrote several software systems in Go, and deployed them in production. At least one of them is serving millions of daily active users. Some things I'm happy about (and these were my reasons to use Go in the first place), like: 1. No JIT = no warmup 2. Portable static binaries 3. Solid tooling 4. (Mostly) high quality static library What I really find frustrating in Go is not the verbosity (Rust is probably equally verbose, and I get over that), but the utter lack of type safety. You see, most critics of Go (definitely the people complaining about lack of genrics), DO NOT complain about static typing. In fact, I don't remember ever seeing anyone complain about that. What people often complain about is _not enough static typing_. Due to lack of genrics and other limitations of the language, Go essentially forces you to use empty intrrfaces, stringly-typed data, weak enums and runtime type checks all over the place. This leads to fragile code, and makes it very hard to have the same safety guarantees you could have in Java - let alone in a more FP-oriented language like Rust or Haskell.

void_mint 5y ago
> I find your characterization of critica of Go, highly uncharitable, but unfortunately all too common with Go apologetics. I might suggest that if you're the type to use the phrase "Go apologetics", you misinterpreted my post and also emit uncharitable feedback quite often :) > If we look outside of Go, I see a lot of criticism of C++, Java, PHP and Node.js, but I rarely see the critics being attacked with "You just didn't write enough C++ code" to qualify for a critic license. I find this approach hypocritical. If you scroll up, you'll find my request was simply to include the level of involvement a programmer has with a given language as part of their critique. Critique away! But as with all things, when novices critique things they don't understand, they're mostly just being negative for negativity's sake. Go into a C++ space and include "I've never written C++", followed by any criticism and let me know how serious your criticisms are taken. I can wait :) > Due to lack of genrics and other limitations of the language, Go essentially forces you to use empty intrrfaces, stringly-typed data, weak enums and runtime type checks all over the place. This leads to fragile code, and makes it very hard to have the same safety guarantees you could have in Java - let alone in a more FP-oriented language like Rust or Haskell. We can disagree - the purpose of my post was not to prove Go was a "good" language or not. These bits of feedback sound like you're following antipatterns, but you're welcome to program in Go however you'd like.