7 ms·

> No hidden magic thats the whole point of the article. this change trashes that. now many loops are going to have hidden magic

by 38 2y ago

adeptima 2y ago
I guess my system got immuned to such things after TS/JS coding, but if 20% of community will say it has "hidden magic" I'm not excited too. Fast learning curve for new hires is a top golang feature for me too.
unscaled 2y ago
Go always had hidden magic: - Lowercase symbols are private to the package they are declared at. - A function called "init" will get executed implicitly on startup. - You can have multiple functions called "init" in the same package or even in the same file. - Files ending with "_unix.go", "_linux.go", "_windows.go" etc. will only be compiled when compiling for the specified platform. The exact list of platform is very hard to find in documentation. - There are a handful of magical built-in function that have lowercase names. - Some built-ins were generic long before generics were introduced to the language. - The copy function is defined as "copy(dst, src []Type) int" (i.e. both src and dst have to be slices of the same type), but "As a special case, it also will copy bytes from a string to a slice of bytes". There are many cases of magical behavior in classic, pre-Generic Go. Sure, if you read the documentation you can learn about these thing and you wouldn't be surprised (although good luck figuring out the order of calling init() or finding out what happened when Go introduces a new compilation target platform that happens to have the same name as the ending of one of your source files). The thing is, if you read the documentation about iterators and see that your iterating over the results of a function that returns a another function (rather than a slice, string, map or channel), you also wouldn't be surprised. And unlike the old magic, the new magic is always transparent. You can always tell what an iterator function by looking at its source code. But you can't exactly tell what suffixes trigger platform-specific compilation without looking at the Go compiler source code, and knowing where to look.
- foobiekr 2y ago
  "Lowercase symbols are private to the package they are declared at" This isn't magic, it's just a clever convention.
  - kortex 2y ago
    A sufficiently clever convention is indistinguishable from magic.
    - onefiveone 2y ago
      except there's no smoke and mirrors for this character saving trick
  - lifthrasiir 2y ago
    It is a part of the language rules that you can't ever change if you don't want it. It is magic in that sense.
    - mariusor 2y ago
      I always thought that lack of "magic" in a programming language means that when (as a human) you read through source code you are able to reach the end of the program. Opposite to that, in a language that has "magic" you reach a point where you don't know where execution will go next without the help of the compiler (or a heavy duty IDE that translates for you).
      - lifthrasiir 2y ago
        That's very subjective I guess, because it would also depend on your familiarity with the subject matter. I can for example easily read and understand a recursive descent parser in any language because I have implemented it multiple times and can catch a common pattern. Unless the language in question corrupts that pattern (highly unlikely unless it's an esolang :-), that definition of "magic" should be largely independent from the language itself.
TheDong 2y ago
If iterators are hidden magic, how are the following not hidden magic: for i, v := range someSlice { ... Shouldn't that be eschewed as magic, and instead we should write: for i := 0; i < len(someSlice); i++ { v := someSlice[i]; ... They both de-sugar to the same thing (well, now they do, it used to re-use the same 'v' in the first one, so it used to be subtly different, but they changed the language's hidden magic). How is the channel loop not hidden magic? for v := range channel // magic for for { v, ok := <-channel if !ok { break } } The iterator proposal is adding some sugar which is _less hidden_ than the current 'for range' loops, and people are complaining that's magic?
- 38 2y ago
  > for i, v := range someSlice { ... what a ridiculous comment - every single programming language has this or similar syntax for iterating a slice.
  - TheDong 2y ago
    All the languages I can think of that have iteration over a slice also have the ability for users to define iteration over custom collections, such as with generators or whatever... yet the comment I'm replying to is saying custom iterators, something every language has, is too much magic, so clearly "every language has it" isn't enough justification for something not to be magic for them. Anyway, not every language has it. C has arrays, but doesn't have any iteration sugar for them, and the general attitude of gophers does usually seem to be "if C didn't have it, it's not simple, it's magic", and that Go should just be C but with a GC, goroutines, and builtin hashmaps.

> No hidden magic thats the whole point of the article. this change trashes that. now many loops are going to have hidden magic

by 38 2y ago

> No hidden magic thats the whole point of the article. this change trashes that. now many loops are going to have hidden magic

adeptima 2y ago

I guess my system got immuned to such things after TS/JS coding, but if 20% of community will say it has "hidden magic" I'm not excited too. Fast learning curve for new hires is a top golang feature for me too.

unscaled 2y ago

Go always had hidden magic: - Lowercase symbols are private to the package they are declared at. - A function called "init" will get executed implicitly on startup. - You can have multiple functions called "init" in the same package or even in the same file. - Files ending with "_unix.go", "_linux.go", "_windows.go" etc. will only be compiled when compiling for the specified platform. The exact list of platform is very hard to find in documentation. - There are a handful of magical built-in function that have lowercase names. - Some built-ins were generic long before generics were introduced to the language. - The copy function is defined as "copy(dst, src []Type) int" (i.e. both src and dst have to be slices of the same type), but "As a special case, it also will copy bytes from a string to a slice of bytes". There are many cases of magical behavior in classic, pre-Generic Go. Sure, if you read the documentation you can learn about these thing and you wouldn't be surprised (although good luck figuring out the order of calling init() or finding out what happened when Go introduces a new compilation target platform that happens to have the same name as the ending of one of your source files). The thing is, if you read the documentation about iterators and see that your iterating over the results of a function that returns a another function (rather than a slice, string, map or channel), you also wouldn't be surprised. And unlike the old magic, the new magic is always transparent. You can always tell what an iterator function by looking at its source code. But you can't exactly tell what suffixes trigger platform-specific compilation without looking at the Go compiler source code, and knowing where to look.

foobiekr 2y ago
"Lowercase symbols are private to the package they are declared at" This isn't magic, it's just a clever convention.
- kortex 2y ago
  A sufficiently clever convention is indistinguishable from magic.
  - onefiveone 2y ago
    except there's no smoke and mirrors for this character saving trick
- lifthrasiir 2y ago
  It is a part of the language rules that you can't ever change if you don't want it. It is magic in that sense.
  - mariusor 2y ago
    I always thought that lack of "magic" in a programming language means that when (as a human) you read through source code you are able to reach the end of the program. Opposite to that, in a language that has "magic" you reach a point where you don't know where execution will go next without the help of the compiler (or a heavy duty IDE that translates for you).
    - lifthrasiir 2y ago
      That's very subjective I guess, because it would also depend on your familiarity with the subject matter. I can for example easily read and understand a recursive descent parser in any language because I have implemented it multiple times and can catch a common pattern. Unless the language in question corrupts that pattern (highly unlikely unless it's an esolang :-), that definition of "magic" should be largely independent from the language itself.

TheDong 2y ago

If iterators are hidden magic, how are the following not hidden magic: for i, v := range someSlice { ... Shouldn't that be eschewed as magic, and instead we should write: for i := 0; i < len(someSlice); i++ { v := someSlice[i]; ... They both de-sugar to the same thing (well, now they do, it used to re-use the same 'v' in the first one, so it used to be subtly different, but they changed the language's hidden magic). How is the channel loop not hidden magic? for v := range channel // magic for for { v, ok := <-channel if !ok { break } } The iterator proposal is adding some sugar which is _less hidden_ than the current 'for range' loops, and people are complaining that's magic?

38 2y ago
> for i, v := range someSlice { ... what a ridiculous comment - every single programming language has this or similar syntax for iterating a slice.
- TheDong 2y ago
  All the languages I can think of that have iteration over a slice also have the ability for users to define iteration over custom collections, such as with generators or whatever... yet the comment I'm replying to is saying custom iterators, something every language has, is too much magic, so clearly "every language has it" isn't enough justification for something not to be magic for them. Anyway, not every language has it. C has arrays, but doesn't have any iteration sugar for them, and the general attitude of gophers does usually seem to be "if C didn't have it, it's not simple, it's magic", and that Go should just be C but with a GC, goroutines, and builtin hashmaps.