Hacker News Reader

Comment by karolist | Hacker News Reader

Looks pretty useless to anyone who did the Go tour and read Effective Go at least. These are just language design choices, not dark corners. It's not shooting yourself in the foot it's just doing things the Go way and there's often no other way if you want to use the language.

View on HN

The author does state that the article is just a collection of potentially surprising things from other sources. They also state the target audience is those new to Go but know other languages. Title may be a bit over the top but I'll give them a pass on that as it seems to have worked.

I did the tour, studied the spec, and read Effective Go. Don’t remember the trick of constructing a set type by way of map[<settype>]struct{} in any of them.

https://rytisbiel.com/2021/03/06/darker-corners-of-go/#mapst...

Having used this trick before, it's fine. You get the uniqueness property of a set, but no easy way to do set operations, so it's not necessarily that useful.

Yup, I also think the author has a pretty low threshold for calling something a "footgun". For me, that's something that compiles fine, but blows up later at runtime, not the compiler telling you that you can't put an opening brace on its own line - that's more like a gentle slap on the wrist. But some of his other opinions are also debatable, like calling Go "not really object-oriented" because it doesn't support inheritance...

> Looks pretty useless to anyone who did the Go tour and read Effective Go at least.

Honestly? Not everyone wants (or should have) to do that in order to touch some Go code (or code in any other language). I for one am quite happy that "cheat sheets" like this one exist - it might sound paradoxical but I'm not interested in actually learning every single language I've had to tinker with, as I have plenty of other things I'd rather be doing.

> Honestly? Not everyone wants (or should have) to do that in order to touch some Go code

For hobby projects maybe, if it's part of your job you should know what you're doing and read the fine manual (basic documentation in this case).

That literally is the point, thank you for restating it explicitly. Not everybody is trying to get a job as a Go developer. People who just want to make a change or two to a tool that they use, to follow what someone else is doing, or to even just get a quick feel for the language without being treated like an absolute beginner to programming are users too and there is nothing wrong with making resources that are helpful for them.

Ideally you'd have someone more experienced to do a code review and correct your mistakes if it's just a one off change, Go is not hard to pick up and compiler gives good hints usually.

> Ideally you'd have someone more experienced to do a code review

I cannot stress enough that not all programming occurs in a work or even social context.

Besides, I did not say Go is hard to pick up. I said people should not need to read the entire manual, so to speak, to do things involving Go or any other language or tool. Cheat sheets like the linked article that outline the language in terms of "things you need to know as someone who already programs extensively" are thus actually quite helpful. That is all.

Exactly, flagged for clickbait. I (and surely many others) wouldn’t have clicked if it is more accurately titled “a random list of extremely basic golang design choices that I as a beginner find somewhat surprising, if that.”

Reply on news.ycombinator.com