4 ms·

Yeah, but aside from the singular issue of generics (which are not exactly cutting edge), I can't think of a single 'advanced' feature that would add nearly eno

by jbooth 12y ago

Yeah, but aside from the singular issue of generics (which are not exactly cutting edge), I can't think of a single 'advanced' feature that would add nearly enough utility to pay for its additional complexity. Everyone who shows up complaining about how it isn't "moving forward" by embracing features of high complexity and dubious utility is really missing the point IMO.

jksmith 12y ago
My low content response is that you are brutally correct.
anon1385 12y ago
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi...
tome 12y ago
What about sum types (discriminated unions)? Sounds like that would help make error handling a lot safer and easier.
- tuxychandru 12y ago
  How do sum types make error handling safer (without also adding exhaustive pattern matching) or easier (without adding do notation or macros)? The point I am trying to make is that adding some features from other languages doesn't provide sufficient value without also adding other features. Adding all of them can make the language significantly more complex that you wonder whether the benefits gained are worth it.
  - tome 12y ago
    The problem with omitting language features like this is that the programmer is then forced to implement them by hand in an error-prone way. It's the same issue with Python and tail call optimization. Guido refuses to implement tail call optimization, so the programmer has to implement it herself in terms of a loop. Go refuses to implement sum types, so programmers code them up by hand. In neither case is the code actually clearer. Since proper error-checking in Go actually requires doing by hand what a pattern match would have done anyway you're not simplifying anything for anyone by omitting them; you're just making it harder for the compiler to provide compile-time checks. A pattern match is basically a switch statement. Go already provides the latter so the language would not need to become more complicated.
AnimalMuppet 12y ago
Well, they're really missing the point of Go. It's fine for languages to embrace those features, and be what they are, and it's fine for Go to reject those features, and be what it is. We don't need "one language to rule them all".

by jbooth 12y ago

jksmith 12y ago

My low content response is that you are brutally correct.

anon1385 12y ago

http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare http://www.infoq.com/presentations/Null-References-The-Billi...

tome 12y ago

What about sum types (discriminated unions)? Sounds like that would help make error handling a lot safer and easier.

tuxychandru 12y ago
How do sum types make error handling safer (without also adding exhaustive pattern matching) or easier (without adding do notation or macros)? The point I am trying to make is that adding some features from other languages doesn't provide sufficient value without also adding other features. Adding all of them can make the language significantly more complex that you wonder whether the benefits gained are worth it.
- tome 12y ago
  The problem with omitting language features like this is that the programmer is then forced to implement them by hand in an error-prone way. It's the same issue with Python and tail call optimization. Guido refuses to implement tail call optimization, so the programmer has to implement it herself in terms of a loop. Go refuses to implement sum types, so programmers code them up by hand. In neither case is the code actually clearer. Since proper error-checking in Go actually requires doing by hand what a pattern match would have done anyway you're not simplifying anything for anyone by omitting them; you're just making it harder for the compiler to provide compile-time checks. A pattern match is basically a switch statement. Go already provides the latter so the language would not need to become more complicated.

AnimalMuppet 12y ago

Well, they're really missing the point of Go. It's fine for languages to embrace those features, and be what they are, and it's fine for Go to reject those features, and be what it is. We don't need "one language to rule them all".