5 ms·

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.

by coryrc 5y ago

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.
      - uchiga 5y ago
        No offense, but a manual tester generally doesnt have much credibility in a conversation about coding matters.
        void_mint 5y ago
        Diminishing a person's job in an attempt to discredit their feedback has even less credibility.
        coryrc 5y ago
        I don't do manual testing. (This is why the majority of people in my role hate the name).
p10jkle 5y ago
What about writing distributed systems? Cockroach, Kubernetes, the Hashicorp stack, etcd, Prometheus
- coryrc 5y ago
  I'm most familiar with Kubernetes. This[0] would not exist if the language had sufficient expressive power. But Prometheus, Kubernetes, etcd... they're distributed CRUD. There's so. much. yaml (runtime flex types) and I believe that's in part due to the inflexibility of the language itself. 0: https://github.com/kubernetes/code-generator https://github.com/kubernetes/code-generator
  - closeparen 5y ago
    The whole thing of Kubernetes is to take a goal state as data and abstract away the procedures that make it happen. You were always going to communicate with it in a data serialization format, not a programming language. It happened to choose YAML.
    - coryrc 5y ago
      > You were always going to communicate with it in a data serialization format Perhaps, it's hard to argue that a data serialization format is worse than previous alternative approaches (OLE?), but specifically a schema-less one should be up for debate? (Clearly I've become a protobuf, um, fan? Might be a bit far)
tptacek 5y ago
What you're trying to say is that Go's domain is mostly serverside. That's true. But it sounds too useful and ambitious, so you've modified it to "CRUD microservices". Which is silly and false, but works better as a slur on the language. What's dispiriting here is that there are cogent arguments against Go --- decisions Go could have made differently that probably wouldn't have cost the project much in terms of its other goals of compilation speed and simplicity, but make it more annoying to work in. I switch between Rust and Go every day and miss pattern matching almost every time, for instance. Instead, though, we get the same dumb innuendo. "It's a language for managers". "It's a language for CRUD apps". "It's a language for junior programmers". Never mind that the kernel of truth in those statements is shared by languages like Python; you can't really get away with trashing Python like that, or you'll be haunted by the ghost of one of Peter Norvig's terrifying shirts. Which is a way you know not much is really being said here, except that there's some weird turf war between Go and whatever language its haters are advocating for.
- coryrc 5y ago
  You wouldn't write a monolith in Go? I think it's fair to narrow it down to microservices (maybe just "services" though?). A lot of programming these days is translating one thing into another thing (there are several packages out there for making protobufs more efficient, f.ex.; which I think is the most I can say on the topic?). It's not a slur if it's actually good at doing something we do a lot of. I've recently tried using it as a "better shell script for gophers" but it's still too early to say. We've all heard the nulls, pattern matching, etc arguments already. I just think it's not that big of a pain if you are only doing CRUD and that's why it makes sense in its domain. EDIT: I've fallen out of love with Python because it's bad at large programs (distributed or not). Didn't think that's controversial.
  - tptacek 5y ago
    "Maybe just services" concedes the whole point. Yes, Go is not a good language to build a web browser in (and that's an important application domain, and we all suffer from not having a popular portable language to do that in; it's why we all run goofy Electron apps on our desktops now). But the space of all possible serverside apps is huge, and encompasses a pretty big chunk of what people actually build professionally.

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.

by 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.
    - uchiga 5y ago
      No offense, but a manual tester generally doesnt have much credibility in a conversation about coding matters.
      - void_mint 5y ago
        Diminishing a person's job in an attempt to discredit their feedback has even less credibility.
      - coryrc 5y ago
        I don't do manual testing. (This is why the majority of people in my role hate the name).

p10jkle 5y ago

What about writing distributed systems? Cockroach, Kubernetes, the Hashicorp stack, etcd, Prometheus

coryrc 5y ago
I'm most familiar with Kubernetes. This[0] would not exist if the language had sufficient expressive power. But Prometheus, Kubernetes, etcd... they're distributed CRUD. There's so. much. yaml (runtime flex types) and I believe that's in part due to the inflexibility of the language itself. 0: https://github.com/kubernetes/code-generator https://github.com/kubernetes/code-generator
- closeparen 5y ago
  The whole thing of Kubernetes is to take a goal state as data and abstract away the procedures that make it happen. You were always going to communicate with it in a data serialization format, not a programming language. It happened to choose YAML.
  - coryrc 5y ago
    > You were always going to communicate with it in a data serialization format Perhaps, it's hard to argue that a data serialization format is worse than previous alternative approaches (OLE?), but specifically a schema-less one should be up for debate? (Clearly I've become a protobuf, um, fan? Might be a bit far)

tptacek 5y ago

What you're trying to say is that Go's domain is mostly serverside. That's true. But it sounds too useful and ambitious, so you've modified it to "CRUD microservices". Which is silly and false, but works better as a slur on the language. What's dispiriting here is that there are cogent arguments against Go --- decisions Go could have made differently that probably wouldn't have cost the project much in terms of its other goals of compilation speed and simplicity, but make it more annoying to work in. I switch between Rust and Go every day and miss pattern matching almost every time, for instance. Instead, though, we get the same dumb innuendo. "It's a language for managers". "It's a language for CRUD apps". "It's a language for junior programmers". Never mind that the kernel of truth in those statements is shared by languages like Python; you can't really get away with trashing Python like that, or you'll be haunted by the ghost of one of Peter Norvig's terrifying shirts. Which is a way you know not much is really being said here, except that there's some weird turf war between Go and whatever language its haters are advocating for.

coryrc 5y ago
You wouldn't write a monolith in Go? I think it's fair to narrow it down to microservices (maybe just "services" though?). A lot of programming these days is translating one thing into another thing (there are several packages out there for making protobufs more efficient, f.ex.; which I think is the most I can say on the topic?). It's not a slur if it's actually good at doing something we do a lot of. I've recently tried using it as a "better shell script for gophers" but it's still too early to say. We've all heard the nulls, pattern matching, etc arguments already. I just think it's not that big of a pain if you are only doing CRUD and that's why it makes sense in its domain. EDIT: I've fallen out of love with Python because it's bad at large programs (distributed or not). Didn't think that's controversial.
- tptacek 5y ago
  "Maybe just services" concedes the whole point. Yes, Go is not a good language to build a web browser in (and that's an important application domain, and we all suffer from not having a popular portable language to do that in; it's why we all run goofy Electron apps on our desktops now). But the space of all possible serverside apps is huge, and encompasses a pretty big chunk of what people actually build professionally.