3 ms·

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 langua

by 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.
      - busterarm 2y ago
        Go was designed for use in enterprise environments. It was literally designed for Google's specific development problems. Nothing about Go's design should be talked about divorced from the context of it being tailor-built to solve Google-specific problems. All other uses of Golang are basically in the territory of rounding error.
        cy_hauser 2y ago
        True for the early days of Go but I don't know about now. I think the switch started happening right after modules came out. Generics and the new range stuff seem more for the sake of growing the language than specific needs in Google.
        etse 2y ago
        The opposite seems true (regarding Go being over-fitted to Google problems). It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat. Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does. I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.
- flkenosad 2y ago
  I wish Bazel was a Go project. Unfortunately, it's written in Java.
giraffe_lady 2y ago
Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent here. I wouldn't call its tooling "a mess" but these days it's nothing notable either.
- Cthulhu_ 2y ago
  I consider that a win too tbh; JS land has improved a lot with e.g. Prettier and now Biome, and those were inspired by Go's formatter and stance saying "shut the fuck up about code formatting already, this is how it's formatted, end of story, go worry about more important things".
- jimbokun 2y ago
  Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case. It was also designed as a more modern and mature replacement for C, and I can't think of many application domains where C is still the better choice. Python is at such a different point in the design space I don't think you can really compare the two. Same with PHP, Ruby, Javascript etc. For OCaml, need to decide how strongly you want to commit yourself to functional programming. Also, didn't OCaml have weak support for concurrency? Has that changed recently? Similarly with Rust, comes down how much you want to commit yourself to learning and conforming to the borrow checker. Elixir is an interesting comparison, as it's another language that allows you to build highly concurrent back end services. The tradeoffs are that Elixir provides even more robust scaling due to the Erlang VM. But Go allows you to more easily understand and optimize the memory and CPU performance of your application.
  - kaba0 2y ago
    > Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case Well, it’s quite easy to be fast if you are just spewing out barely optimized machine code. Compilers aren’t slow just for the sake of it.

by Thaxll 2y ago

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.
    - busterarm 2y ago
      Go was designed for use in enterprise environments. It was literally designed for Google's specific development problems. Nothing about Go's design should be talked about divorced from the context of it being tailor-built to solve Google-specific problems. All other uses of Golang are basically in the territory of rounding error.
      - cy_hauser 2y ago
        True for the early days of Go but I don't know about now. I think the switch started happening right after modules came out. Generics and the new range stuff seem more for the sake of growing the language than specific needs in Google.
      - etse 2y ago
        The opposite seems true (regarding Go being over-fitted to Google problems). It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat. Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does. I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.
flkenosad 2y ago
I wish Bazel was a Go project. Unfortunately, it's written in Java.

giraffe_lady 2y ago

Go tooling was relatively very good a decade ago but other languages have improved a lot since then, significantly because of its influence, and it's now about average. It's still better than python, and C or C++ of course. But about even with typescript, ruby, shit even php and ocaml have nearly caught up with their tooling. Go's is significantly worse than rust god help us and elixir has always made good excellent here. I wouldn't call its tooling "a mess" but these days it's nothing notable either.

Cthulhu_ 2y ago
I consider that a win too tbh; JS land has improved a lot with e.g. Prettier and now Biome, and those were inspired by Go's formatter and stance saying "shut the fuck up about code formatting already, this is how it's formatted, end of story, go worry about more important things".
jimbokun 2y ago
Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case. It was also designed as a more modern and mature replacement for C, and I can't think of many application domains where C is still the better choice. Python is at such a different point in the design space I don't think you can really compare the two. Same with PHP, Ruby, Javascript etc. For OCaml, need to decide how strongly you want to commit yourself to functional programming. Also, didn't OCaml have weak support for concurrency? Has that changed recently? Similarly with Rust, comes down how much you want to commit yourself to learning and conforming to the borrow checker. Elixir is an interesting comparison, as it's another language that allows you to build highly concurrent back end services. The tradeoffs are that Elixir provides even more robust scaling due to the Erlang VM. But Go allows you to more easily understand and optimize the memory and CPU performance of your application.
- kaba0 2y ago
  > Go was explicitly designed for fast compile times, especially compared to C++, and I haven't heard anything to suggest that's no longer the case Well, it’s quite easy to be fast if you are just spewing out barely optimized machine code. Compilers aren’t slow just for the sake of it.