16 ms·

Darker Corners of Go

185 points by signa11 6y ago

kbar13 6y ago
pretty overstated title but i guess it did catch my attention so there's that. anyways it is a nice thorough writeup of things that are different about golang. don't think they are particularly "darker" or bad or anything like that.
EdwardDiego 6y ago
Archive, as it looks like it's being hugged to death: https://web.archive.org/web/20210322154522/https://rytisbiel.com/2021/03/06/darker-corners-of-go/ https://web.archive.org/web/20210322154522/https://rytisbiel...
mseepgood 6y ago
The title is strange. This is regular intermediate level Go knowledge, not dark corners.
- tgv 6y ago
  Sure. The only thing that was obscure to me in the beginning was slices. I could not comprehend at first that an append could modify the underlying and possibly aliased data structure, and other slices. I blame the pseudo-functional use, x = append(x, ...), and the fact that taking a slice looks so much like making a copy for that. It simply deviated too much from all the other languages I've programmed in.
  - mappu 6y ago
    It's following C: x = realloc(x, ...)
  - everybodyknows 6y ago
    Same here. I found it helpful to bear in mind that y := append(x, ...), while seldom wanted, is legal.
- gher-shyu3i 6y ago
  The entire premise of golang was that it was a "simple" language with only a few keywords and a standard that's only a few pages long. While these metrics look good on paper, they are secondary (or even less) when it comes to real world complexity and gotchas in the language. IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use.
  - mseepgood 6y ago
    Almost nothing in this article is a "gotcha". It simply describes the features Go has, such as a formatter, bitwise operators, or things that Go does differently/better compared to other languages, such as strings can't be nil, break is the default in switch cases, etc. > IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use. There's an entire book titled "Java Puzzlers".
    - knorker 6y ago
      Slices are definitely full of "gotcha". As is the fact that interfaces have two types of nil, type and untyped. And the extremely leaky implementation detail of maps and slices is definitely a gotcha. Usage wise both slice and map can be nil, but map has to be make()d, for no obvious reason. The fact that the author was confused about "strings can't be nil" shows their Java experience, I think. Coming from C++ programmer I would go "well of course it can't be nil". (But slices and maps can? Wat?) Slices have another gotcha, described, where yes there are arrays, but you basically never use them. They're just a ghost that pops its head in and is the explanation for why your code that treated slices like lists/arrays failed. You're (almost) only supposed to use this leaky abstraction that'll bite you if you think your "list of items" is "a list". I say this as someone who's coded a lot of Go, and reviewed much much more: Go, like other things Rob Pike makes, only make sense and are consistent and intuitive inside his brain. They don't make objective sense. The poster child for this is "Go doesn't have exceptions". It has "unwind the stack, call cleanup code along the way, until a handler is met. If there's no handler it'll terminate the application". In Rob Pike's brain the very definition of "exception" is something completely different from "exception". Even the defense "we don't call them exceptions because they should not be used e.g. for failing to open a file!" is complete nonsense to anyone who's ever heard of C++. Yeah. File not found is not an exception in C++, what's your point? That and "well OF COURSE the go compiler for ARM is called 5g and x86 is called 6g!!!".
- skywhopper 6y ago
  You’re reading too much into it.
rob74 6y ago
I haven't read the article to the end, but many of the "footguns" the author talks about could be avoided by simply reading this document: https://golang.org/doc/effective_go https://golang.org/doc/effective_go . It's pretty old already, but still valid, and emphasizes some of the ways Go is different from other languages. So more or less exactly what this article is doing...
- beranabus 6y ago
  More like the go tour, which is about the most basic introduction a go developer can get.
xaduha 6y ago
What's the point of writing a clickbaity blogpost if your blog can't handle the attention?
posharma 6y ago
It looks like it has become fashionable to write Go related posts as they sure get the attention on HN :-). I don't use Go, but all these posts remind me of what Bjarne Stroustroup said [1] about C++: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.” [1]: https://www.goodreads.com/quotes/226225-there-are-only-two-kinds-of-languages-the-ones-people https://www.goodreads.com/quotes/226225-there-are-only-two-k...
- cy_hauser 6y ago
  >> It looks like it has become fashionable to write Go related posts as they sure get the attention on HN No, not really. I filter for Go, Rust, Nim, and Dart on HN. Rust is the most popular with at least a post every day or two and Go about half that time or less. There used to be way more Go articles in past years. Some of the recent Go posts have gotten traction so maybe you're seeing that.
  - DiggyJohnson 6y ago
    >> it has become fashionable > no not really This doesn’t make sense to me at all. 50% as popular as Rust is considerably fashionable. I imagine that Rust is one of the most common programming languages to appear in post titles on HN.
- CraigJPerry 6y ago
  I kind of wish people would make more posts about c++ - idiomatic c++ today is totally different than the c++ knowledge i have from pre-2010. The fact that c++ has changed so much in the past 10 years - it’s possible to write completely type and resource safe code in c++ now - this passed me by until a year or two ago when i attended a Bjarne talk. Also the c++ folks have written up a core guidelines doc (this was the main topic of that Bjarne talk), and it’s really good https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
  - pjmlp 6y ago
    The problem is that there is even a counter movement to it, praising C with Classes kind of code, Orthodox C++.
dustinmoris 6y ago
Flagged for being so shite that you can’t even handle a few dozen clicks per second. What a pathetic website.
- dang 6y ago
  Please stop posting unsubstantive and/or flamebait comments to HN. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
karolist 6y ago
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.
- cy_hauser 6y ago
  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.
- oefrha 6y ago
  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.”
- filleduchaos 6y ago
  > 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.
  - gcmrtc 6y ago
    > 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).
    - filleduchaos 6y ago
kylequest 6y ago
Golang gotchas are fun :) Some of them are for beginners while others will trip you up even when you've done a lot (e.g., variable shadowing). Here's another golang gotchas post from a while back: http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...
veltas 6y ago
It feels like the 'traps' rather than just things which are unique to Go should be highlighted differently, so if you're interested in the traps you can go straight to them.
thysultan 6y ago
>Operator precedence This is a Light Corner and a Dark Corner of C.
dmitriid 6y ago
> Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. I'm reading this and I can't shake the feeling that this is really bad compiler and/or language design. Why would the compiler import (that is, parse and compile) a package that's unused in the code? > A better solution is to use goimports tool. Goimports removes unreferenced imports for you. What’s even better it tries to automatically find and add missing ones. Why can't the compiler do that? Why do you need a few dozen separate tools to complement the compiler?
- konart 6y ago
  >Why would the compiler import (that is, parse and compile) a package that's unused in the code? Parse - yes, compile - no. Compiler still needs to parse your code to determine if your import is used or not. Go team decided that compilation should take as little time as possible, so it is easier to make sure that the compiler does not have to worry about unused imports at all. Not to mention that this keeps your code clean. Dozen separate tools can be used effectively in your workflow (say CI\CD pipeline). Or just executed on every save. (or both) https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports
  - dmitriid 6y ago
    > Compiler still needs to parse your code to determine if your import is used or not. Parsing is easy. And it's fast. On top of that the compiler already knows it's unused: --- start quote --- Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. --- end quote --- So, the compiler has already parsed the file, and determined that the import is unused. And refuses to compile further, because... it needs to import that package anyway? Why? > Dozen separate tools can be used effectively in your workflow Haha, no. If you need a dozen different tools, there's no question about effectiveness at all.
    - deleted 6y ago
      [deleted]
ThePhysicist 6y ago
Another underused language feature is the "reflect" package, which for me is the most powerful meta-programming tool that Go offers: It basically allows you to introspect data structures at runtime, in combination with struct tags (e.g. commonly used in the json package like `json:"foo"`) it becomes really really powerful. I've written automated database mapping / ORM code and struct deserialization code with it (e.g. here were we build a function that serializes arbitrary JSON-like data structures into deeply nested structs: https://github.com/kiprotect/go-helpers/blob/master/forms/coerce.go https://github.com/kiprotect/go-helpers/blob/master/forms/co...), but you could do even more powerful things like completely automated generation of gRPC/REST interfaces at runtime. Another interesting but underused capability are go plugins, which allow us to dynamically load external code at runtime. They are similar to DLLs but unfortunately not as powerful as they e.g. need to be compiled against the exact same Go version & runtime. We still use them at various points in our codebase (e.g. here: https://github.com/kiprotect/kodex/tree/master/plugins/writers/example https://github.com/kiprotect/kodex/tree/master/plugins/write...).
- pjmlp 6y ago
  Plugins are half-done feature, I would like for them to finish the implementation across all supported OSes and improve the way the code gets loaded as well. Hence why they are underused.
- konart 6y ago
  I wouldn't say reflection is being underused. It's just that the reflection is a powerful tool AND a necessary evil. https://blog.golang.org/laws-of-reflection https://blog.golang.org/laws-of-reflection "Once you understand these laws reflection in Go becomes much easier to use, although it remains subtle. It's a powerful tool that should be used with care and avoided unless strictly necessary."
gizzlon 6y ago
He lost me very early: "Opening bracket must be placed at the end of the line in Go. Interestingly this is not enforced by gofmt," Eh, no, of course it's not. It's a syntax error, fixing those are NOT the point of go fmt
- dvh 6y ago
  If only you would read 5 more lines you would notice author says it is syntax error.
  - oefrha 6y ago
    Yes, the fact that the author knows it’s a syntax error yet still made that bizarre comment about gofmt not enforcing the style indicates that he doesn’t realize gofmt is not for fixing syntax errors (in fact, it refuses to format anything when there’s a syntax error and simply errors out, so my guess is the author only used gofmt as a formatting action in an editor like VS Code, and assumed no code change on shift+option+f means gofmt doesn’t enforce it). And that’s exactly what gp’s complaining about — demonstrated lack of understanding of gofmt.
    - josefx 6y ago
      I think that it is a syntax error is the weird part, in most languages it wouldn't be. So people stumble over an error that normally is considered a style choice.
dvh 6y ago
The amount of crying go fanboys here is staggering. Author merely points out minute gotchas, IMHO invaluable information.
- Philip-J-Fry 6y ago
  I think it's a bit ridiculous how every other day the Go post on HN is just about how shit it is. And then people arguing in the comments about how "it's not simple" and bringing up things you can learn in 5 minutes. It's just old and tiring to hear the same shit over and over again.
- tsdlts 6y ago
  I barely hear a word out of go fanboys outside of their own respective bubbles. Rust fanboys however...
parhamn 6y ago
> In the early days of Go this was a serious trap for programmers who didn’t read the instructions and relied in some way on maps being iterated in a certain order. To help spot these issues early on rather than in production, Go developers made map iterations random-ish I didn’t know this about go specifically (as I generally expect maps to be unordered). But it is pretty funny because the Python folks did the opposite: they ensured order stability on the dict because people started relying on it.
JulianMorrison 6y ago
Aside to the multidimensional slices thing: if you want a dense "multidimensional slice", it's probably going to be a lot more efficient (if more verbose) to allocate an underlying array by multiplying the dimensions and then make your easy to use slice-of-slices point into that array. Note that this implies you need to avoid any operations that might resize the slices.
magwa101 6y ago
In the end, you have to understand the fundamental CPU/memory/IO architecture to make anything efficient and safe. C++ gives you foot and moon shots. You spend a lot of time "in the language" and system arch. When I converted to Java, I spent a lot of time in the VM. I found that time spent not useful.
bfrog 6y ago
Go, the RSL inducing language
makeworld 6y ago
The example for how to count Unicode characters (actually graphemes I think) is incorrect. It won't catch more complicated things like emojis with skin tone modifiers. Currently the best way I know to do this is to use the uniseg library. https://github.com/rivo/uniseg https://github.com/rivo/uniseg
Hublium 6y ago
The title seems exaggerated, but skimming through this, it seems like a good introduction to the language. I definitely want to learn it sometime. "Slices" and "iota" seem like interesting concepts. I don't know whether they are better than usual collections and enums, but they feel different in an interesting way.

185 points by signa11 6y ago

pretty overstated title but i guess it did catch my attention so there's that. anyways it is a nice thorough writeup of things that are different about golang. don't think they are particularly "darker" or bad or anything like that.

EdwardDiego 6y ago

Archive, as it looks like it's being hugged to death: https://web.archive.org/web/20210322154522/https://rytisbiel.com/2021/03/06/darker-corners-of-go/ https://web.archive.org/web/20210322154522/https://rytisbiel...

mseepgood 6y ago

The title is strange. This is regular intermediate level Go knowledge, not dark corners.

tgv 6y ago
Sure. The only thing that was obscure to me in the beginning was slices. I could not comprehend at first that an append could modify the underlying and possibly aliased data structure, and other slices. I blame the pseudo-functional use, x = append(x, ...), and the fact that taking a slice looks so much like making a copy for that. It simply deviated too much from all the other languages I've programmed in.
- mappu 6y ago
  It's following C: x = realloc(x, ...)
- everybodyknows 6y ago
  Same here. I found it helpful to bear in mind that y := append(x, ...), while seldom wanted, is legal.
gher-shyu3i 6y ago
The entire premise of golang was that it was a "simple" language with only a few keywords and a standard that's only a few pages long. While these metrics look good on paper, they are secondary (or even less) when it comes to real world complexity and gotchas in the language. IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use.
- mseepgood 6y ago
  Almost nothing in this article is a "gotcha". It simply describes the features Go has, such as a formatter, bitwise operators, or things that Go does differently/better compared to other languages, such as strings can't be nil, break is the default in switch cases, etc. > IMO, Java, even with a longer standard, is a safer and more sane language and ecosystem to use. There's an entire book titled "Java Puzzlers".
  - knorker 6y ago
    Slices are definitely full of "gotcha". As is the fact that interfaces have two types of nil, type and untyped. And the extremely leaky implementation detail of maps and slices is definitely a gotcha. Usage wise both slice and map can be nil, but map has to be make()d, for no obvious reason. The fact that the author was confused about "strings can't be nil" shows their Java experience, I think. Coming from C++ programmer I would go "well of course it can't be nil". (But slices and maps can? Wat?) Slices have another gotcha, described, where yes there are arrays, but you basically never use them. They're just a ghost that pops its head in and is the explanation for why your code that treated slices like lists/arrays failed. You're (almost) only supposed to use this leaky abstraction that'll bite you if you think your "list of items" is "a list". I say this as someone who's coded a lot of Go, and reviewed much much more: Go, like other things Rob Pike makes, only make sense and are consistent and intuitive inside his brain. They don't make objective sense. The poster child for this is "Go doesn't have exceptions". It has "unwind the stack, call cleanup code along the way, until a handler is met. If there's no handler it'll terminate the application". In Rob Pike's brain the very definition of "exception" is something completely different from "exception". Even the defense "we don't call them exceptions because they should not be used e.g. for failing to open a file!" is complete nonsense to anyone who's ever heard of C++. Yeah. File not found is not an exception in C++, what's your point? That and "well OF COURSE the go compiler for ARM is called 5g and x86 is called 6g!!!".
skywhopper 6y ago
You’re reading too much into it.

rob74 6y ago

I haven't read the article to the end, but many of the "footguns" the author talks about could be avoided by simply reading this document: https://golang.org/doc/effective_go https://golang.org/doc/effective_go . It's pretty old already, but still valid, and emphasizes some of the ways Go is different from other languages. So more or less exactly what this article is doing...

beranabus 6y ago
More like the go tour, which is about the most basic introduction a go developer can get.

xaduha 6y ago

What's the point of writing a clickbaity blogpost if your blog can't handle the attention?

posharma 6y ago

It looks like it has become fashionable to write Go related posts as they sure get the attention on HN :-). I don't use Go, but all these posts remind me of what Bjarne Stroustroup said [1] about C++: “There are only two kinds of languages: the ones people complain about and the ones nobody uses.” [1]: https://www.goodreads.com/quotes/226225-there-are-only-two-kinds-of-languages-the-ones-people https://www.goodreads.com/quotes/226225-there-are-only-two-k...

cy_hauser 6y ago
>> It looks like it has become fashionable to write Go related posts as they sure get the attention on HN No, not really. I filter for Go, Rust, Nim, and Dart on HN. Rust is the most popular with at least a post every day or two and Go about half that time or less. There used to be way more Go articles in past years. Some of the recent Go posts have gotten traction so maybe you're seeing that.
- DiggyJohnson 6y ago
  >> it has become fashionable > no not really This doesn’t make sense to me at all. 50% as popular as Rust is considerably fashionable. I imagine that Rust is one of the most common programming languages to appear in post titles on HN.
CraigJPerry 6y ago
I kind of wish people would make more posts about c++ - idiomatic c++ today is totally different than the c++ knowledge i have from pre-2010. The fact that c++ has changed so much in the past 10 years - it’s possible to write completely type and resource safe code in c++ now - this passed me by until a year or two ago when i attended a Bjarne talk. Also the c++ folks have written up a core guidelines doc (this was the main topic of that Bjarne talk), and it’s really good https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC...
- pjmlp 6y ago
  The problem is that there is even a counter movement to it, praising C with Classes kind of code, Orthodox C++.

dustinmoris 6y ago

Flagged for being so shite that you can’t even handle a few dozen clicks per second. What a pathetic website.

dang 6y ago
Please stop posting unsubstantive and/or flamebait comments to HN. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

karolist 6y ago

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.

cy_hauser 6y ago
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.
oefrha 6y ago
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.”
filleduchaos 6y ago
> 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.
- gcmrtc 6y ago
  > 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).
  - filleduchaos 6y ago

kylequest 6y ago

Golang gotchas are fun :) Some of them are for beginners while others will trip you up even when you've done a lot (e.g., variable shadowing). Here's another golang gotchas post from a while back: http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...

veltas 6y ago

It feels like the 'traps' rather than just things which are unique to Go should be highlighted differently, so if you're interested in the traps you can go straight to them.

thysultan 6y ago

>Operator precedence This is a Light Corner and a Dark Corner of C.

dmitriid 6y ago

> Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. I'm reading this and I can't shake the feeling that this is really bad compiler and/or language design. Why would the compiler import (that is, parse and compile) a package that's unused in the code? > A better solution is to use goimports tool. Goimports removes unreferenced imports for you. What’s even better it tries to automatically find and add missing ones. Why can't the compiler do that? Why do you need a few dozen separate tools to complement the compiler?

konart 6y ago
>Why would the compiler import (that is, parse and compile) a package that's unused in the code? Parse - yes, compile - no. Compiler still needs to parse your code to determine if your import is used or not. Go team decided that compilation should take as little time as possible, so it is easier to make sure that the compiler does not have to worry about unused imports at all. Not to mention that this keeps your code clean. Dozen separate tools can be used effectively in your workflow (say CI\CD pipeline). Or just executed on every save. (or both) https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports
- dmitriid 6y ago
  > Compiler still needs to parse your code to determine if your import is used or not. Parsing is easy. And it's fast. On top of that the compiler already knows it's unused: --- start quote --- Go programs with unused imports do not compile. This is a deliberate feature of the language as importing packages slow down the compiler. --- end quote --- So, the compiler has already parsed the file, and determined that the import is unused. And refuses to compile further, because... it needs to import that package anyway? Why? > Dozen separate tools can be used effectively in your workflow Haha, no. If you need a dozen different tools, there's no question about effectiveness at all.
  - deleted 6y ago
    [deleted]

ThePhysicist 6y ago

Another underused language feature is the "reflect" package, which for me is the most powerful meta-programming tool that Go offers: It basically allows you to introspect data structures at runtime, in combination with struct tags (e.g. commonly used in the json package like `json:"foo"`) it becomes really really powerful. I've written automated database mapping / ORM code and struct deserialization code with it (e.g. here were we build a function that serializes arbitrary JSON-like data structures into deeply nested structs: https://github.com/kiprotect/go-helpers/blob/master/forms/coerce.go https://github.com/kiprotect/go-helpers/blob/master/forms/co...), but you could do even more powerful things like completely automated generation of gRPC/REST interfaces at runtime. Another interesting but underused capability are go plugins, which allow us to dynamically load external code at runtime. They are similar to DLLs but unfortunately not as powerful as they e.g. need to be compiled against the exact same Go version & runtime. We still use them at various points in our codebase (e.g. here: https://github.com/kiprotect/kodex/tree/master/plugins/writers/example https://github.com/kiprotect/kodex/tree/master/plugins/write...).

pjmlp 6y ago
Plugins are half-done feature, I would like for them to finish the implementation across all supported OSes and improve the way the code gets loaded as well. Hence why they are underused.
konart 6y ago
I wouldn't say reflection is being underused. It's just that the reflection is a powerful tool AND a necessary evil. https://blog.golang.org/laws-of-reflection https://blog.golang.org/laws-of-reflection "Once you understand these laws reflection in Go becomes much easier to use, although it remains subtle. It's a powerful tool that should be used with care and avoided unless strictly necessary."

gizzlon 6y ago

He lost me very early: "Opening bracket must be placed at the end of the line in Go. Interestingly this is not enforced by gofmt," Eh, no, of course it's not. It's a syntax error, fixing those are NOT the point of go fmt

dvh 6y ago
If only you would read 5 more lines you would notice author says it is syntax error.
- oefrha 6y ago
  Yes, the fact that the author knows it’s a syntax error yet still made that bizarre comment about gofmt not enforcing the style indicates that he doesn’t realize gofmt is not for fixing syntax errors (in fact, it refuses to format anything when there’s a syntax error and simply errors out, so my guess is the author only used gofmt as a formatting action in an editor like VS Code, and assumed no code change on shift+option+f means gofmt doesn’t enforce it). And that’s exactly what gp’s complaining about — demonstrated lack of understanding of gofmt.
  - josefx 6y ago
    I think that it is a syntax error is the weird part, in most languages it wouldn't be. So people stumble over an error that normally is considered a style choice.

dvh 6y ago

The amount of crying go fanboys here is staggering. Author merely points out minute gotchas, IMHO invaluable information.

Philip-J-Fry 6y ago
I think it's a bit ridiculous how every other day the Go post on HN is just about how shit it is. And then people arguing in the comments about how "it's not simple" and bringing up things you can learn in 5 minutes. It's just old and tiring to hear the same shit over and over again.
tsdlts 6y ago
I barely hear a word out of go fanboys outside of their own respective bubbles. Rust fanboys however...

parhamn 6y ago

> In the early days of Go this was a serious trap for programmers who didn’t read the instructions and relied in some way on maps being iterated in a certain order. To help spot these issues early on rather than in production, Go developers made map iterations random-ish I didn’t know this about go specifically (as I generally expect maps to be unordered). But it is pretty funny because the Python folks did the opposite: they ensured order stability on the dict because people started relying on it.

JulianMorrison 6y ago

Aside to the multidimensional slices thing: if you want a dense "multidimensional slice", it's probably going to be a lot more efficient (if more verbose) to allocate an underlying array by multiplying the dimensions and then make your easy to use slice-of-slices point into that array. Note that this implies you need to avoid any operations that might resize the slices.

magwa101 6y ago

In the end, you have to understand the fundamental CPU/memory/IO architecture to make anything efficient and safe. C++ gives you foot and moon shots. You spend a lot of time "in the language" and system arch. When I converted to Java, I spent a lot of time in the VM. I found that time spent not useful.

bfrog 6y ago

Go, the RSL inducing language

makeworld 6y ago

The example for how to count Unicode characters (actually graphemes I think) is incorrect. It won't catch more complicated things like emojis with skin tone modifiers. Currently the best way I know to do this is to use the uniseg library. https://github.com/rivo/uniseg https://github.com/rivo/uniseg

Hublium 6y ago

The title seems exaggerated, but skimming through this, it seems like a good introduction to the language. I definitely want to learn it sometime. "Slices" and "iota" seem like interesting concepts. I don't know whether they are better than usual collections and enums, but they feel different in an interesting way.