Some of these are really unsurprising. I mean, it’s a “WAT” that Go’s variables are block scoped? Really?
I think this kind of “look out for these slightly unexpected behaviors” talk is a good thing, but trying to liken them to Gary Bernhardt’s WAT talk seems a bit disingenuous.
So I don’t know whether that is intense or not, but most of the content is covered very clearly in the Go spec, which is not exactly big, as far as specs go…. so yeah. This.
I mean, it’s a “WAT” that Go’s variables are block scoped? Really?
It’s not just block scope, it’s block scope plus shadowing, plus allowing you to declare and assign a visible variable using the value from the variable that you’re shadowing. You could have block scope without allowing either of the latter two choices.
Java doesn’t let you do this, even though it has block scope. The second declaration of a fails. I was mildly surprised that C lets you do the same thing, though given the origins of go, I shouldn’t have been.
I think the link is more an appeal to popular culture.
Either way, WAT8 was pretty surprising for me. I would never expect that to happen, that seems more like a quirk of code generation than an actual intentional feature.
My initial instinct was the same; but I tried to suspense my knowledge in interest of “austerity”, and with this I personally believe a lot of them are warts indeed. I’d say in other words: “not following the principle of least surprise”. Including that I actually guessed wrong in ~2 of them indeed. (Also: even though the append semantics are ingrained in my mind, and I get where they’re coming from, honestly I can’t say I find them friendly.) OTOH, maybe the fact that the Go “spec” is actually so short is an important saving grace here. That said, I think I’d be super happy if all of those “WATs” were somehow removed in e.g. Go 2 or something. (Go 3? ;P)
I mean, if you WUT at hash map iteration order being undefined, you need to reevaluate some things. Its fine if someone doesn’t know, or hasn’t needed to know the internals of hash maps… but at some point it is effectively insulting a project while having a totally uninformed opinion.
golang maps the heap at a fixed address (0xc000000000 on FreeBSD/HardenedBSD). This makes the -buildmode=pie option useless, since the heap is at a known, fixed location.
Not saying your wat is invalid but this is their response:
“(Russ Cox) Address space randomization is an OS-level workaround for a language-level problem, namely that simple C programs tend to be full of exploitable buffer overflows. Go fixes this at the language level, with bounds-checked arrays and slices and no dangling pointers, which makes the OS-level workaround much less important. In return, we receive the incredible debuggability of deterministic address space layout. I would not give that up lightly.”
Yeah, I read the 2012 thread in which Russ said that. However, -buildmode=pie didn’t exist then. The existence of PIE support infers that the project as a whole has changed its mind: that a non-deterministic address space as modified by ASLR is worth it. I’ve submitted a new email to the golang-nuts mailing list to re-address the issue.
I’d say that golang is a “safer” language, just like Rust. However, I don’t think we’re to the point where we can say any language is 100% safe. Sure, golang and Rust improve the situation quite drastically, but they’re both written by humans and are still subject to the mistakes humans make.
So, it seems weird to me that golang would take the time to implement PIE support, but neglect to address the fixed heap. Hopefully my email on the mailing list will get some informative replies.
As someone who’s forgotten a lot of Go, I see the first two and I am left wondering how do I properly pass by reference into a Go function. It would be nice to have the ‘solutions’ for some of these explicitly coded up as well.
Some of these are really unsurprising. I mean, it’s a “WAT” that Go’s variables are block scoped? Really?
I think this kind of “look out for these slightly unexpected behaviors” talk is a good thing, but trying to liken them to Gary Bernhardt’s WAT talk seems a bit disingenuous.
So I don’t know whether that is intense or not, but most of the content is covered very clearly in the Go spec, which is not exactly big, as far as specs go…. so yeah. This.
It’s not just block scope, it’s block scope plus shadowing, plus allowing you to declare and assign a visible variable using the value from the variable that you’re shadowing. You could have block scope without allowing either of the latter two choices.
Java doesn’t let you do this, even though it has block scope. The second declaration of
afails. I was mildly surprised that C lets you do the same thing, though given the origins of go, I shouldn’t have been.I think the link is more an appeal to popular culture.
Either way, WAT8 was pretty surprising for me. I would never expect that to happen, that seems more like a quirk of code generation than an actual intentional feature.
Not even close to the JavaScript’s and Ruby’s hilarious code snippets.
Maybe because I do lots of go programming, many of these weren’t surprising and were never surprising. Some are good though.
My initial instinct was the same; but I tried to suspense my knowledge in interest of “austerity”, and with this I personally believe a lot of them are warts indeed. I’d say in other words: “not following the principle of least surprise”. Including that I actually guessed wrong in ~2 of them indeed. (Also: even though the append semantics are ingrained in my mind, and I get where they’re coming from, honestly I can’t say I find them friendly.) OTOH, maybe the fact that the Go “spec” is actually so short is an important saving grace here. That said, I think I’d be super happy if all of those “WATs” were somehow removed in e.g. Go 2 or something. (Go 3? ;P)
I mean, if you WUT at hash map iteration order being undefined, you need to reevaluate some things. Its fine if someone doesn’t know, or hasn’t needed to know the internals of hash maps… but at some point it is effectively insulting a project while having a totally uninformed opinion.
I read two and a half blog posts about Go in my life and most of them seemed totally unsurprising lol
One of the key to understand Go code is to translate the following types to their underlying data structures:
Map: pointer to hashmap
Slick: struct{ptr, len, cap}
Interface: struct{ptr, type}
After that Go is surprisingly unsurprising.
Never heard of a Slick before! What language has those!?
Oh, you probably meant slice…
I wish Go would remove named returns.
I had no idea about named returns, doesn’t seem like a very go-like feature at all. So many good talks at gopher con this year!
A golang wat-ism I just found:
golang maps the heap at a fixed address (0xc000000000 on FreeBSD/HardenedBSD). This makes the
-buildmode=pieoption useless, since the heap is at a known, fixed location.Not saying your wat is invalid but this is their response:
“(Russ Cox) Address space randomization is an OS-level workaround for a language-level problem, namely that simple C programs tend to be full of exploitable buffer overflows. Go fixes this at the language level, with bounds-checked arrays and slices and no dangling pointers, which makes the OS-level workaround much less important. In return, we receive the incredible debuggability of deterministic address space layout. I would not give that up lightly.”
Yeah, I read the 2012 thread in which Russ said that. However, -buildmode=pie didn’t exist then. The existence of PIE support infers that the project as a whole has changed its mind: that a non-deterministic address space as modified by ASLR is worth it. I’ve submitted a new email to the golang-nuts mailing list to re-address the issue.
I’d say that golang is a “safer” language, just like Rust. However, I don’t think we’re to the point where we can say any language is 100% safe. Sure, golang and Rust improve the situation quite drastically, but they’re both written by humans and are still subject to the mistakes humans make.
So, it seems weird to me that golang would take the time to implement PIE support, but neglect to address the fixed heap. Hopefully my email on the mailing list will get some informative replies.
In WAT 8, the * are missing from the Naive Guess (because Markdown).
As someone who’s forgotten a lot of Go, I see the first two and I am left wondering how do I properly pass by reference into a Go function. It would be nice to have the ‘solutions’ for some of these explicitly coded up as well.