5 ms·

> It strikes me that Go is riding the peak of hype languages. Very much so. Also it seems to be a strange choice as a solo developer when its strengths are ex

> It strikes me that Go is riding the peak of hype languages. Very much so. Also it seems to be a strange choice as a solo developer when its strengths are explicitly targeted at large organizations. And I think the tooling is actually a bit of a mess compared to some other options. God help you if as a solo developer you start building on top of protobufs (another basically default choice in the Golang world...). I just don't understand why you wouldn't choose something faster and more expressive.

ergonaught 2y ago
> I just don't understand why you wouldn't choose something faster and more expressive. The answer to this is as simple as genuinely asking, answering, and understanding why you don't do all of your development in assembly language.
- busterarm 2y ago
  I didn't mean faster in terms of execution time but in terms of development time. And more expressive is doing more with less code. We're at complete opposite ends of the spectrum here -- how that indicated to you that I meant assembly...
  - ergonaught 2y ago
    It's the same principle. My own experience (I'm not the author) is that the investment required to reach the point where Go can be a "hammer" as in this case is lower (usually significantly lower) than with "faster and more expressive" languages.
  - whstl 2y ago
    Go might not be the most concise or expressive language, but it's quite fast in terms of development time, IMO/IME.
    - Cthulhu_ 2y ago
      Yeah, you just write code without worrying about whether it can be done more concise or clever, it's a very pragmatic language. The downside is code volume, but honestly that is rarely the problem in software.
  - danielvaughn 2y ago
    I'm genuinely curious which language you see as having a better development time. I don't mean that as arguing, I'm actually curious. I don't know much about Go but I just began learning it 2 days ago. I'm already 50% of the way done through a really nice TUI app, and I haven't even touched the docs. To me at least, it feels extremely productive so far.
    - laserlight 2y ago
      Developing with Python is faster.
      - DarkNova6 2y ago
        Only for small or new projects...
      - randomdata 2y ago
        When leaning on libraries pushing what's new in computer science, like certain facets of machine learning as a prominent example, which generally aren't found outside of the Python ecosystem, certainly. But head-to-head on well-trodden computer science paths, Python doesn't stand a chance.
Thaxll 2y ago
Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good. Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.
- busterarm 2y ago
  Bazel. While not Go-specific, it's the extremely popular option in the space and I've seen it bring many-a-seasoned wizard to their knees in tears. Also managing your go dependencies if you cargo-cult other Google behaviors like monorepos tends to be painful. Basically just cargo-culting Google behavior == pain. Choosing golang can often be part of this behavior pattern.
  - tail_exchange 2y ago
    Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel. Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.
    - busterarm 2y ago
      Obviously but if you look at a lot of Go projects you tend to see it. Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people. And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainly wasn't my experience when solo contracting.
      - tail_exchange 2y ago
        Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.
markusw 2y ago
Author here. Well, it has worked pretty well for me so far, so I don't know why I would switch. Go is fast and expressive enough for my use, and it's probably outweighed by being super familiar anyway. (BTW, in my eight years of Go, I think I've used protobufs maybe once or twice. HTTP FTW!)
azthecx 2y ago
Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
azthecx 2y ago
Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.
jimbokun 2y ago
Faster on what axis? Go has maybe the fastest compile times, for example. Which is very important when you are iterating on a project. What do you dislike about the tool chain? Seems better than most languages to me.
- kaba0 2y ago
  Java’s toolchain may leave some to be desired in ergonomics, but compile time is just as fast if not faster.
  - DarkNova6 2y ago
    What do you see missing in the Java toolchain? Frankly, I see it as one of the most complete and deep of all languages.
    - kaba0 2y ago
      Only ergonomics, I do actually like most of it (maven central/repository model and gradle). It is one of two truly general build tools (other being Bazel), and being that generic/capable does mean that it can’t be as user friendly as a single-language build tool like Go’s or Rust’s. But these all break down the moment you introduce another language/build step/whatever, while Gradle can build the whole hodgepodge that is the Android platform just fine, which is quite a testament to its power.

ergonaught 2y ago

> I just don't understand why you wouldn't choose something faster and more expressive. The answer to this is as simple as genuinely asking, answering, and understanding why you don't do all of your development in assembly language.

busterarm 2y ago
I didn't mean faster in terms of execution time but in terms of development time. And more expressive is doing more with less code. We're at complete opposite ends of the spectrum here -- how that indicated to you that I meant assembly...
- ergonaught 2y ago
  It's the same principle. My own experience (I'm not the author) is that the investment required to reach the point where Go can be a "hammer" as in this case is lower (usually significantly lower) than with "faster and more expressive" languages.
- whstl 2y ago
  Go might not be the most concise or expressive language, but it's quite fast in terms of development time, IMO/IME.
  - Cthulhu_ 2y ago
    Yeah, you just write code without worrying about whether it can be done more concise or clever, it's a very pragmatic language. The downside is code volume, but honestly that is rarely the problem in software.
- danielvaughn 2y ago
  I'm genuinely curious which language you see as having a better development time. I don't mean that as arguing, I'm actually curious. I don't know much about Go but I just began learning it 2 days ago. I'm already 50% of the way done through a really nice TUI app, and I haven't even touched the docs. To me at least, it feels extremely productive so far.
  - laserlight 2y ago
    Developing with Python is faster.
    - DarkNova6 2y ago
      Only for small or new projects...
    - randomdata 2y ago
      When leaning on libraries pushing what's new in computer science, like certain facets of machine learning as a prominent example, which generally aren't found outside of the Python ecosystem, certainly. But head-to-head on well-trodden computer science paths, Python doesn't stand a chance.

Thaxll 2y ago

Protobuf is not the default in Go the default is REST. What tools are a mess? Go tooling ( runtime ) and IDE integration is very good. Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.

busterarm 2y ago
Bazel. While not Go-specific, it's the extremely popular option in the space and I've seen it bring many-a-seasoned wizard to their knees in tears. Also managing your go dependencies if you cargo-cult other Google behaviors like monorepos tends to be painful. Basically just cargo-culting Google behavior == pain. Choosing golang can often be part of this behavior pattern.
- tail_exchange 2y ago
  Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel. Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.
  - busterarm 2y ago
    Obviously but if you look at a lot of Go projects you tend to see it. Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people. And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainly wasn't my experience when solo contracting.
    - tail_exchange 2y ago
      Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.

markusw 2y ago

Author here. Well, it has worked pretty well for me so far, so I don't know why I would switch. Go is fast and expressive enough for my use, and it's probably outweighed by being super familiar anyway. (BTW, in my eight years of Go, I think I've used protobufs maybe once or twice. HTTP FTW!)

azthecx 2y ago

Do you have better alternatives to Protobuf? What are the shortcomings that you find with it? At work these choices have been out of my hands but I've used JSON Avro and Protobuf and I felt like Protobuf was the least prone to errors, best surrounding tooling and easy migrations while maintaining small payloads.

azthecx 2y ago

jimbokun 2y ago

Faster on what axis? Go has maybe the fastest compile times, for example. Which is very important when you are iterating on a project. What do you dislike about the tool chain? Seems better than most languages to me.

kaba0 2y ago
Java’s toolchain may leave some to be desired in ergonomics, but compile time is just as fast if not faster.
- DarkNova6 2y ago
  What do you see missing in the Java toolchain? Frankly, I see it as one of the most complete and deep of all languages.
  - kaba0 2y ago
    Only ergonomics, I do actually like most of it (maven central/repository model and gradle). It is one of two truly general build tools (other being Bazel), and being that generic/capable does mean that it can’t be as user friendly as a single-language build tool like Go’s or Rust’s. But these all break down the moment you introduce another language/build step/whatever, while Gradle can build the whole hodgepodge that is the Android platform just fine, which is quite a testament to its power.