6 ms·

Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and no

by djur 12y ago

Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own. This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

nknighthb 12y ago
If there's any magic on that list, it's limited to the garbage collector, and to whatever extent it's magic, that magic would vanish if it were based on strict automatic reference counting. The others are conveniences to avoid subtle bugs and millions of developers writing the exact same code in every project. I've mentioned this before, but my experience is that "expressive" is synonymous with "obfuscated". Go helps us in writing clear, maintainable code, not clever code.
- djur 12y ago
  Generics also are a convenience to avoid subtle bugs and millions of developers writing the exact same code in every project. That's precisely what they're for. Any abstraction can be "magic" to people who don't find it appealing or useful. Go includes some of those abstractions and excludes others, like any language. I don't know of any consistent criteria by which the abstractions Go provides are non-magic and the ones it eschews are magic.
  - nknighthb 12y ago
    My criteria for magic is basically "this is difficult for the average developer to reason about the behavior of". With the exception of garbage collection (with the "asterisk" I mentioned), the things you listed are minimal abstractions which are very easy to reason about. We all understand how maps, slices, channels, and goroutines work. Their behavior is simple and mostly predictable. Developers working in C wrote these or analogous systems all the time. Over and over again, albeit commonly with subtle errors, particularly with regard to concurrency. Slices and maps (or their close equivalents) are universal. They exist in a generic form in Go because everybody needs them, in pretty much every significant codebase. There aren't many other data structures for which that is true. Perhaps as importantly, many nontrivial codebases don't really need much in the way of other data structures. Concurrency features are less universal, but are also the source of many critical bugs. One might reasonably say concurrency is inherently magic under my criteria, but unfortunately some form of it is unavoidable. Go's concurrency primitives at least make it easier to avoid common errors while minimizing additional magic. My personal problem with adding generics directly to Go is not that they are magic, exactly (which I think you may have misinterpreted georgemcbay's comment to imply), but that they lead easily to magic. Go discourages overengineering, which is a common outcome of certain people applying generics (and there are a lot of those certain people, and I've had the misfortune to deal with their code throughout my career). What I would like is for something like gen to become the de-facto standard (presumably in conjunction with the generate feature proposed for Go 1.4). I doubt if I'd use it much myself, but that outcome would at least placate demands for generics without making it all that easy to obfuscate what is actually going on in the Go code.
burntsushi 12y ago
> but it's unsurprisingly frustrating for people used to more expressive languages Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust. There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how close the core of Haskell is to just a simply typed lambda calculus. It's amazing at how Go can be so well specified in such a short document with near perfect orthogonality in the language. Many of your comments in this thread read (to me) as if you're speaking from a position of authority on what the right design for a language is. I think your comments would be better received if you expressed your thoughts as opinions rather than as things you consider facts.
- djur 12y ago
  I don't know what in my comment suggests that you can't love both Haskell and Go, but that's certainly not what I meant. Nothing I've said here is anything other than my own observation and opinion. Thank you for the advice. I'll keep it in mind.
  - burntsushi 12y ago
    > I don't know what in my comment suggests that you can't love both Haskell and Go I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false. You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more expressive languages." Many of your other comments are similarly phrased. The read as if you are privy to some truth that people who like Go do not understand.
    - djur 12y ago
      I wasn't making a statement about myself at all. The tradeoffs involved in Go's design are well-known, well-explained, and intentional. There is a great deal to admire and respect about Go and its community. Hell, my first comment in this thread was noting that Go's design makes it particularly easy to learn. If it helps, substitute "it can be frustrating" for "it's frustrating".

by djur 12y ago

nknighthb 12y ago

If there's any magic on that list, it's limited to the garbage collector, and to whatever extent it's magic, that magic would vanish if it were based on strict automatic reference counting. The others are conveniences to avoid subtle bugs and millions of developers writing the exact same code in every project. I've mentioned this before, but my experience is that "expressive" is synonymous with "obfuscated". Go helps us in writing clear, maintainable code, not clever code.

djur 12y ago
Generics also are a convenience to avoid subtle bugs and millions of developers writing the exact same code in every project. That's precisely what they're for. Any abstraction can be "magic" to people who don't find it appealing or useful. Go includes some of those abstractions and excludes others, like any language. I don't know of any consistent criteria by which the abstractions Go provides are non-magic and the ones it eschews are magic.
- nknighthb 12y ago
  My criteria for magic is basically "this is difficult for the average developer to reason about the behavior of". With the exception of garbage collection (with the "asterisk" I mentioned), the things you listed are minimal abstractions which are very easy to reason about. We all understand how maps, slices, channels, and goroutines work. Their behavior is simple and mostly predictable. Developers working in C wrote these or analogous systems all the time. Over and over again, albeit commonly with subtle errors, particularly with regard to concurrency. Slices and maps (or their close equivalents) are universal. They exist in a generic form in Go because everybody needs them, in pretty much every significant codebase. There aren't many other data structures for which that is true. Perhaps as importantly, many nontrivial codebases don't really need much in the way of other data structures. Concurrency features are less universal, but are also the source of many critical bugs. One might reasonably say concurrency is inherently magic under my criteria, but unfortunately some form of it is unavoidable. Go's concurrency primitives at least make it easier to avoid common errors while minimizing additional magic. My personal problem with adding generics directly to Go is not that they are magic, exactly (which I think you may have misinterpreted georgemcbay's comment to imply), but that they lead easily to magic. Go discourages overengineering, which is a common outcome of certain people applying generics (and there are a lot of those certain people, and I've had the misfortune to deal with their code throughout my career). What I would like is for something like gen to become the de-facto standard (presumably in conjunction with the generate feature proposed for Go 1.4). I doubt if I'd use it much myself, but that outcome would at least placate demands for generics without making it all that easy to obfuscate what is actually going on in the Go code.

burntsushi 12y ago

> but it's unsurprisingly frustrating for people used to more expressive languages Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust. There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how close the core of Haskell is to just a simply typed lambda calculus. It's amazing at how Go can be so well specified in such a short document with near perfect orthogonality in the language. Many of your comments in this thread read (to me) as if you're speaking from a position of authority on what the right design for a language is. I think your comments would be better received if you expressed your thoughts as opinions rather than as things you consider facts.

djur 12y ago
I don't know what in my comment suggests that you can't love both Haskell and Go, but that's certainly not what I meant. Nothing I've said here is anything other than my own observation and opinion. Thank you for the advice. I'll keep it in mind.
- burntsushi 12y ago
  > I don't know what in my comment suggests that you can't love both Haskell and Go I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false. You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more expressive languages." Many of your other comments are similarly phrased. The read as if you are privy to some truth that people who like Go do not understand.
  - djur 12y ago
    I wasn't making a statement about myself at all. The tradeoffs involved in Go's design are well-known, well-explained, and intentional. There is a great deal to admire and respect about Go and its community. Hell, my first comment in this thread was noting that Go's design makes it particularly easy to learn. If it helps, substitute "it can be frustrating" for "it's frustrating".