Live data from Hacker News

Go runtime: 4 years later

go.dev

11–20 of 296 posts

Re: Go runtime: 4 years later

#11
I have been developing in Go for several years and feel like I have seen most it can offer which is quite a lot for backend/networking systems.

Besides its GC implementation that works very well most of the time, it also has simple but strong debugging tools to investigate how well you are handling memory allocation and CPU usage. Enforcing consistent coding style also makes it very easy to read other people's code and quickly contribute.

My suggestion to others is to avoid prematurely optimizing memory usage (e.g. trying to do zero-copy implementations) and always investigate performance via these profiling tools Go offers (e.g. pprof). Very often Golang's compiler or runtime will automatically optimize code that may not seem to allocate optimally.

There are still downsides but some of them are actively worked on:

1. Generics are still lack-luster (... but good enough to start replacing a lot of boilerplate code and will improve later on)

2. Error handling is still tedious (fortunately it seems to be their next big focus), it should take less code-space and have an option of stack-trace

3. Stdlib logging is too simple, lacks levels and structured-logging-style (currently actively discussed: https://github.com/golang/go/discussions/54763)

4. Low-level UDP networking is weak (soon to be fixed as they accepted this proposal: https://github.com/golang/go/issues/45886 ), this will become more important as we transition to QUIC protocol

5. CGo (C interop / C FFI) is pretty bad performance-wise compared to other languages, it's OK if it is an I/O operation but anything C interop that requires low latency won't be running great

6. Similar to other languages, nowadays there are growing external dependency trees (e.g. I always wanted to use testcontainers-go to make integration tests easier but man, have you seen the dependency tree you will pull in with that pacakge?), solution in my eyes is flattening and standardizing most commonly used packages but Go in particular is very opinionated regarding what is included in stdlib

The above downsides mostly come from the background of creating distributed data pipelines and certain data collectors/parsers. For building API servers, I keep hearing it is a godsend in its simplicity, so your mileage may vary depending on the business domain you work in.

I would be interested to hear other people's experience with Go, however!

Re: Go runtime: 4 years later

#14

Not trying to be inflammatory but has the pclntab taking ~30% for binary size been fixed yet? IMO it's a pretty severe design choice.

No one really care about binary size increase , especially because you can run a Go binary in a docker image with 0 dependencies ( scratch image ) which has a very small size.

Re: Go runtime: 4 years later

#16
post #8

Earlier quoted context omitted.

I don't see the point, just use OCaml.

I don't understand how this is a response to every "I wish I had blank but like ocaml". Threads exist.

As does OCaml since 1996, no need for sugar substitute instead of using the real deal.

Compiles to native code, has a repl, version 5 is multicore for those not happy with Lwt or multiprocessing in the UNIX classical style of each tool does one thing, and a GC only second to GHC in handling immutable types.

Re: Go runtime: 4 years later

#18

Not trying to be inflammatory but has the pclntab taking ~30% for binary size been fixed yet? IMO it's a pretty severe design choice.

> IMO it's a pretty severe design choice.

I don't think that's true, otherwise it would've been fixed already. For the main use case of Go (https://go.dev/blog/survey2022-q2-results), APIs and web services it just doesn't matter if the binary is 1MB or 30MB. Unless you are working on some embedded systems where space is scarce I don't see it as a big issue.

Re: Go runtime: 4 years later

#20
post #14

Not trying to be inflammatory but has the pclntab taking ~30% for binary size been fixed yet? IMO it's a pretty severe design choice.

No one really care about binary size increase , especially because you can run a Go binary in a docker image with 0 dependencies ( scratch image ) which has a very small size.

do you know how things like tzdata and locale are handled in a single Go executable docker image ?
Post reply on HN