5 ms·

"I want all this <-done synchronizations and select sacramentals to be entire hidden" Then perhaps Go is not the language for you. There are a lot of design d

"I want all this <-done synchronizations and select sacramentals to be entire hidden" Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic". This is, IMO, a feature and not a bug, but YMMV.

dkarapetyan 12y ago
What exactly do you mean by "magic"? Most of the time when I hear people talk about "magic" they usually mean a theory or abstraction that they don't understand or don't want to understand. Are generics magical in your opinion?
- georgemcbay 12y ago
  What makes things magical or not (the way I think of magical) isn't about the theory of the feature but rather how they are implemented and how much is hidden from the person using them in terms of code complexity and just overall work being done relative to what they think they did. I'm perfectly comfortable with the "theory of generics", but when generics first came on the scene for C++ back during the time period I used to program primarily in C and C++ they were very magical. Not on the run-time side where the eventual result of any sane compiler is easy to understand, but magical on the compile-time side where when using them it was nearly impossible to determine how much time they would add to the overall compilation and how complex and unreadable the error messages would be if you had a problem. When you make a single simple syntax error and the compiler presents you with an error that is 2 pages long that is the result of an implementation that is, IMO, very "magical".
  - dkarapetyan 12y ago
    There is a bit of contradiction in your definition then. I don't think anyone using Go understands how the compiler does all the transformations necessary to get from Go to machine code. In that sense Go as a whole is pretty magical but you seem perfectly happy with that. Modern application programmers and even system programmers by your definition rely on a lot of "magic". Even the machine code these days is a layer or two removed from the actual metal with all the caching and microcode that reside on the CPU.
  - pjmlp 12y ago
    Generics appeared in programming languages with CLU back in 1974 followed by many others, C++ was hardly the first language to get them. The first version of STL was actually done in Ada. Don't mistake generics in programming languages with what C++ does.
  - nickik 12y ago
    My probken with your "what avg programmer find easy to understand" stick is that this basiclly means, never add anything new. Many thing common today where 'magic' once. So the line where something is magic is kind of meaningless.
wyager 12y ago
Go doesn't prevent "magic", it just makes you hide the magic in ugly places. Can't have a flexible iterator system because it might introduce complexity? Better just hide complexity in a next() function. Can't have generics (except for the google-approved map, slice, chan...) because it might introduce complexity? Better just shift that complexity to unsafe use of interface{}.
- georgemcbay 12y ago
  It doesn't "prevent" "magic", but it "highly discourages" it. And again, I think it is a feature and not a bug. I didn't always think that way, I had a really rough start with Go because I was using it as if I were programming in a slightly different dialect of C++ which it isn't. When I write Go as if it is Go, I just don't see these "missing features" as problems at all. But this debate has been going back and forth since Go was first made public, so anyone who has tried Go and dismissed it based on these lack of features is unlikely to be persuaded otherwise here and they should continue to use other languages until such a time as Go supports what they want (if ever). That's the beauty of having so many languages to choose from.
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.
MoOmer 12y ago
I pasted this in the gist comments, and I'll reproduce it here from Hoare's Communicating Sequential Processes: [0] > But the dangers of convenient facilities are notorious. For example, the repetitive commands with input guards may tempt the programmer to write them without making adequate plans for their termination; and if it turns out that the automatic termination is unsatisfactory, reprogramming for explicit termination will involve severe changes, affecting even the interfaces between the processes. [0]: http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf

dkarapetyan 12y ago

What exactly do you mean by "magic"? Most of the time when I hear people talk about "magic" they usually mean a theory or abstraction that they don't understand or don't want to understand. Are generics magical in your opinion?

georgemcbay 12y ago
What makes things magical or not (the way I think of magical) isn't about the theory of the feature but rather how they are implemented and how much is hidden from the person using them in terms of code complexity and just overall work being done relative to what they think they did. I'm perfectly comfortable with the "theory of generics", but when generics first came on the scene for C++ back during the time period I used to program primarily in C and C++ they were very magical. Not on the run-time side where the eventual result of any sane compiler is easy to understand, but magical on the compile-time side where when using them it was nearly impossible to determine how much time they would add to the overall compilation and how complex and unreadable the error messages would be if you had a problem. When you make a single simple syntax error and the compiler presents you with an error that is 2 pages long that is the result of an implementation that is, IMO, very "magical".
- dkarapetyan 12y ago
  There is a bit of contradiction in your definition then. I don't think anyone using Go understands how the compiler does all the transformations necessary to get from Go to machine code. In that sense Go as a whole is pretty magical but you seem perfectly happy with that. Modern application programmers and even system programmers by your definition rely on a lot of "magic". Even the machine code these days is a layer or two removed from the actual metal with all the caching and microcode that reside on the CPU.
- pjmlp 12y ago
  Generics appeared in programming languages with CLU back in 1974 followed by many others, C++ was hardly the first language to get them. The first version of STL was actually done in Ada. Don't mistake generics in programming languages with what C++ does.
- nickik 12y ago
  My probken with your "what avg programmer find easy to understand" stick is that this basiclly means, never add anything new. Many thing common today where 'magic' once. So the line where something is magic is kind of meaningless.

wyager 12y ago

Go doesn't prevent "magic", it just makes you hide the magic in ugly places. Can't have a flexible iterator system because it might introduce complexity? Better just hide complexity in a next() function. Can't have generics (except for the google-approved map, slice, chan...) because it might introduce complexity? Better just shift that complexity to unsafe use of interface{}.

georgemcbay 12y ago
It doesn't "prevent" "magic", but it "highly discourages" it. And again, I think it is a feature and not a bug. I didn't always think that way, I had a really rough start with Go because I was using it as if I were programming in a slightly different dialect of C++ which it isn't. When I write Go as if it is Go, I just don't see these "missing features" as problems at all. But this debate has been going back and forth since Go was first made public, so anyone who has tried Go and dismissed it based on these lack of features is unlikely to be persuaded otherwise here and they should continue to use other languages until such a time as Go supports what they want (if ever). That's the beauty of having so many languages to choose from.

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.

MoOmer 12y ago

I pasted this in the gist comments, and I'll reproduce it here from Hoare's Communicating Sequential Processes: [0] > But the dangers of convenient facilities are notorious. For example, the repetitive commands with input guards may tempt the programmer to write them without making adequate plans for their termination; and if it turns out that the automatic termination is unsatisfactory, reprogramming for explicit termination will involve severe changes, affecting even the interfaces between the processes. [0]: http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf