I know zero go, despite having worked with it professionally for a short stint that I try and block out of my memory (not go's fault), anyway that first example looks like gibberish to me while the second is super clear.

FWIW i also know zero Go but the first example made sense (though while i don't know Go, i do know it has multiple return values): the "m[key]" part returns two values which are assigned to the "_, ok" expression which represents a value to be ignored and an "ok" variable which is later used in the "; ok" part (i guess ; separates multiple subexpressions similar to C's "," and the overall expression's value is the last subexpression) and so the two values returned from "m[key]" are the map's value and a boolean (or something that can be used like that) that checks if the value was found. In which case "if _,ok := m[key] {" would be the same as something like "if m.contains(key) {".

Of course this is all guesswork based on similar stuff i've seen elsewhere, so i might be off, but i think despite not knowing the language it still looks readable if you know any other mainstream language (and exercise some guesswork/imagination :-P).

Well, that's because you do not work with go much I guess?

I can say the same about Fennel, List or Haskell.

The first example is the way to go in Go. It's idiomatic, not a hack. And it works the same way for many things (for example checking if a channel's closed)

It is deeply idiomatic in the language.

But only because there's no `contains` function!

If perl has taught us anything... 3 ways to do something is worse than 1.

what `contains` what?

you could write this in Go

   if m[key] { }

the comma ok idiom simply lets you distinguish a "zero" value from a missing value.

Agreed that `key in m` or `m.contains(key)` would be clearer, but checking the value rather than the presence is asking for trouble.

`if m[key] { }` is only valid Go if m is a map from something to bool, so I don't know what you even mean.

Your parent knows how's to read code and can recognize the purpose of the second statement but not the first. While that is not some end-all metric, it does says something about the Go idiom's clarity.

Hopefully that helps explain the matter...

You missed why his comment is insightful. It's for the very reason he knows a bit about the topic but not too much.

It is. Because everyone starts out knowing zero go, and so the learning curve of a language (and for people who know another programming language first) is very much a key metric.

I know pretty much nothing about Scala. Anybody cares for my criticism of its type system? And what's with Rust and those ampersands everywhere?

GP wasn't discussing the language in general, just a small feature that depends on an idiomatic pattern used in many other places, saying "it looks gibberish." Of course it does, because it isn't idiomatic for you.

You don’t need to know that to do the comparison. If I tell you to do the same thing in one language it’s “(!:;$&)” and in another it’s “array_contains”, you don’t even need to know the languages to have a reasonable opinion on which is superior.

No, but IMO the cognitive load for the second one is a lot lower; it says what it does, not how it does it. It's like using `for i := i; i < len(slice); i++` vs `for i in range(slice)` or other languages' versions thereof; it reads in what you want it to do instead of how it should do it.

It's less about length of code and more about cognitive load; this is why functional programming constructs are frowned upon in Go code, because the cognitive load per line of code is much higher.

Also `if m.contains(key) { }` is even more obvious IMO.

the difference is visible cognitive load. The first has me looking at commas and underscores and colons and equals, for a map lookup.