Live data from Hacker News

Ask HN: What do you like/dislike about Golang?

news.ycombinator.com

21–30 of 111 posts

Re: Ask HN: What do you like/dislike about Golang?

#21
Below are my current feelings having worked with it as my primary language over the last 16 months. My previous 7 years of development focused on Java, C++, Python, and JavaScript.

Like:

- Standard Tooling: formatting coverage, dependencies, BIN install, versioning, vendoring all done in Go CLI

- Opinionated, minimal design: often I feel like there are fewer ways to do things in Go than in other languages.

- Readability: fewer operators and minimal language design make it feel easier to ramp up and read most go programs

Dislike:

- Hard to master: some elements are very unintuitive coming from other languages (interfaces). I feel like a lot of content on go.dev is out of date (Effective Go). The Google Style guide is helping to light a path and when they publish Go Tips I think it will get better.

- Too Minimal: in some cases it feels like Go went too far in not building language features (no set, use map[$TYPE]bool instead or map[$TYPE]struct{} for more efficiency but less readable imo)

Re: Ask HN: What do you like/dislike about Golang?

#22
post #16

As someone who likes async/await/coroutines, I really miss them in Go. Channels are the GOTO of synchronisation, they lead to confusing spaghetti code because there is no structure. Go is really nice to read (once you get used to the fact that half the lines of code in any function are for error handling) unless it uses a lot of channels. Then you need to take great care to understand every <-.

> As someone who likes async/await/coroutines, I really miss them in Go

Interesting. Most complain about languages with async/await and say they want goroutines. What is it about async/await that you prefer over Go's approach?

Re: Ask HN: What do you like/dislike about Golang?

#23
Like:

- Ecosystem

- Static linking

- goroutines

- small and light runtime

- fast compilation speed

Dislike:

- missing shorthand lambda functions, making functional programming very painful

- typed nils

- billion dollar mistake (lack of non-nullable types)

- implicit/automatic copying on value types. Value types as a whole need to be re-thought.

- too much error handling boilerplate

- unused variables are compiler errors

- struct init not exhaustive

Re: Ask HN: What do you like/dislike about Golang?

#24
post #5

Not too many complaints. I like it much better than Java backend. Go and Typescript are now my go to for everything I think.

curious if you prefer Typescript or Go for backend development. My friend group told me they prefer Typescript because of shared code with client and ease of hiring.

I have a nodejs+typescript backend stuck in a limbo state because of the whole esm modules fiasco. I have outdated npm modules I can't upgrade because they are ESM only, and I have old modules that will likely never update.

It's to the point where I will only be using golang for backends moving forward.

Re: Ask HN: What do you like/dislike about Golang?

#26

It's a very practical language, and I like its affinity for static binaries. A downside is Google's approach to handling modules: https://drewdevault.com/2021/08/06/goproxy-breaks-go.html

This seems to only be a complaint about a particular (granted, default) proxy for downloading modules, and no criticism of the actual module system (which does not depend on a proxy) nor the idea of a proxy (which is pretty easy to run, especially when compared to most other languages' package repositories).

As to the criticism, if a public module isn't playing well with the default proxy, it's a good sign I don't want to use it to begin with.

Re: Ask HN: What do you like/dislike about Golang?

#27
post #5

Not too many complaints. I like it much better than Java backend. Go and Typescript are now my go to for everything I think.

curious if you prefer Typescript or Go for backend development. My friend group told me they prefer Typescript because of shared code with client and ease of hiring.

I’ve heard the shared code argument before, but in practice the only shared code I’ve really ever seen used is shared type definitions. Now shared type definitions are huge, but they’re a solved problem using JSON schema, GraphQL, or some other interface definition language that don’t necessarily require the same language in the front end and backend.

Re: Ask HN: What do you like/dislike about Golang?

#28
post #4

Love: - Ecosystem - Clean code - Single executable file Dislike: - Pointers -- maybe I am still getting the hang of it. But I feel like pointers throw off a lot of beginner programmers. Would love some practical advice here

> pointers

Stick with pass-by-value and non-pointer receivers. Use pointers only if you have to.

Re: Ask HN: What do you like/dislike about Golang?

#29
post #15
post #7

For me Go is unique in that it can produce a fully static binary that can fetch from a HTTPS endpoint. It also supports many architectures. On top of that the package system and it's just way more convenient to use than other languages. Easy to learn, easy to put somewhere in practice. Not every program has to be 100% safe and delivering 2M req/s. Sometimes you just want to build a program once and ship it. What othe…

Static linking predates dynamic linking by several decades, hardly unique.

Wait, what prior programming language is compiled, can be statically linked, and has an https implementation in it's standard library?

Re: Ask HN: What do you like/dislike about Golang?

#30
post #7

For me Go is unique in that it can produce a fully static binary that can fetch from a HTTPS endpoint. It also supports many architectures. On top of that the package system and it's just way more convenient to use than other languages. Easy to learn, easy to put somewhere in practice. Not every program has to be 100% safe and delivering 2M req/s. Sometimes you just want to build a program once and ship it. What othe…

> For me Go is unique in that it can produce a fully static binary that can fetch from a HTTPS endpoint.

What do you mean? C, C++, D, Rust, Haskell, and Common Lisp seem to be capable of static linking. (Admittedly Common Lisp seems to require a fork of SBCL that was written about last year, but still)

Post reply on HN