Go runtime: 4 years later

I really like the engineering principles in general that the Go team uses, however, I just don't like Go. That isn't meant as a slight or anything other than simply my opinion. That said, I really like the idea of a simple language based on the sort of principles demonstrated here. The runtime seems really nice, I just wish I liked the language better (IMO: not expressive enough, needs better error handling, needs much better enums, needs pattern matching, has error prone C-style 'for', almost everything is statements not expressions, special comments are error prone, has nil pointers, etc.). In the end I think if someone were to write a slightly simpler version of Rust with the Go runtime it might be pretty neat. That said, I don't know what I'd want to drop from Rust so maybe I'm just fantasizing.

Love go as a platform.. self contained binaries have been a miracle for ops..but have a few big hangups about using the language full time because of the sucky ergonomics.<p>* No optional&#x2F;named parameters. Writing a whole function per parameter for function chaining is excessive. This would not be difficult to add to the compiler (i&#x27;ve done it and have seriously considered using the fork) but it seems like the team is just stubborn about adding stuff like this.<p>* No default struct values. 0 isn&#x27;t good enough in real world scenarios.. have fun writing BlahInit(...) for everything.<p>* Would be nice to get the question mark syntax for error handling. Error handling shorthand for if err != nil would also be very welcome.

I&#x27;m really grateful for everyone who has made Go possible and continues to make it better. Well done language design, extensive standard library, good tooling, and great documentation is something that&#x27;s almost impossible to find despite there being a multitude of languages.

I am not a fan of new knobs like this. It reminds me of Java where you actually have to think about -xMx blah blah and setting it is a dark art. I would really prefer if we could somehow confer the memory limit from the container environment to go so this could be set intuitively at the container level without mucking about in the go GC internals.

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&#x2F;networking systems.<p>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&#x27;s code and quickly contribute.<p>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&#x27;s compiler or runtime will automatically optimize code that may not seem to allocate optimally.<p>There are still downsides but some of them are actively worked on:<p>1. Generics are still lack-luster (... but good enough to start replacing a lot of boilerplate code and will improve later on)<p>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<p>3. Stdlib logging is too simple, lacks levels and structured-logging-style (currently actively discussed: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;discussions&#x2F;54763" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;discussions&#x2F;54763</a>)<p>4. Low-level UDP networking is weak (soon to be fixed as they accepted this proposal: <a href="https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;45886" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;golang&#x2F;go&#x2F;issues&#x2F;45886</a> ), this will become more important as we transition to QUIC protocol<p>5. CGo (C interop &#x2F; C FFI) is pretty bad performance-wise compared to other languages, it&#x27;s OK if it is an I&#x2F;O operation but anything C interop that requires low latency won&#x27;t be running great<p>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<p>The above downsides mostly come from the background of creating distributed data pipelines and certain data collectors&#x2F;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.<p>I would be interested to hear other people&#x27;s experience with Go, however!

It is probably a bit misleading when so many say: &#x27;golang is easy&#x27;, it is not, it is as difficult as Java or other language, probably easier than c++ and rust, but definitely not an easy language.<p>it makes great sense for network with concurrency, not so with real time or low resource devices to me.

Some very impressive wins here. Makes one wonder how much better things are going to get in the next few years. All without needing to change my programs!

I always thought go needed more GC knobs, good that they added this one and the strong reasoning behind it makes sense. Impressive go has got this far with just one knob!

Still yearning for an Ocaml-like language that uses the Go runtime.

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

After being bitten by the overhead of Go’s GC, we stopped using it and went back to time-tested C++.