5 ms·

Perhaps Google's Go will end up being the answer.

by gms 16y ago

masklinn 16y ago
No. And thank science for that.
sausagefeet 16y ago
I think many people were hoping for it but Go fell fatally short in 2 key areas IMO: 1 - Error handling - Go doesn't have any powerful mechanism for error handling. The code I have seen is rather inconsistent and it doesn't solve the main problem from C of forcing people to handle errors. 2 - Polymorphism - They left any kind of generics out. I think this could go a long ways for (1) too, just look at Either or Maybe type in Haskell. Combine this with some pattern matching and you have a really powerful way to enforce error handling and have polymorphic data structures and functions. IMO this is the biggest failing of Go. I think the failure to provide those two things also makes Go a future mess. Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess.
- dchest 16y ago
  Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess. Actually, the creators of Go are still not afraid of breaking things. For example, recent release (2011-02-01.1¹) changed the syntax of non-blocking channel operations, and it broke code. [1] https://groups.google.com/d/topic/golang-nuts/uHfjRyO1Q6c/discussion https://groups.google.com/d/topic/golang-nuts/uHfjRyO1Q6c/di...
  - sausagefeet 16y ago
    That is good to see. But I would argue that the change described here is a rather small change while the 2 missing features I described have a larger effect on how you design your application.
    - jbooth 16y ago
      Well, adding generics shouldn't break working code.. it's an additive change. It says something that for the built-in collection types, Slice and Map, they had to hack around their own API and implement this-case-only ad hoc generics. Slice and Map should be fully implementable within the language.
      - supersillyus 16y ago
        Why should Slice be fully implementable within the language? C++ is another systems language that decided that everything should be able to be done in libraries, and we've all seen the complexity that results.
        jbooth 16y ago
        Well, I'll back off slightly from the assertion "fully implementable" because you have the f = s[i] syntax which wouldn't be fully implementable unless you allow the user to define [], which I agree is crazytown. However, the make() functions for slice and map are the only functions in the language that allow you to pass in a type and get that type back as a return function. Why can't users have that functionality? Generics seem to be the easiest way to get it.
        supersillyus 16y ago
        I think I agree, but I'm not good enough at language design to be sure. :) In the current language, all uses of type literals need to be known at compile time; if I could pass a variable containing a type to "make" or use it to instantiate a map, the language needs generics to deal with that, and all of the complications that come with it. The current idiom seems to be (if I wanted my own "make"): myslice := mymake((MyType)(nil), 10).([]MyType) which is much uglier than the built-in way. However, I'm kinda okay with reflection-laden runtime tomfoolery looking a bit messy, mostly because I rarely use it, and when I do I like it to stand out and be obvious what is going on.
- deleted 16y ago
  [deleted]
- supersillyus 16y ago
  I don't agree with #1. I prefer Go error handling to pretty much any other style I've seen.
- loup-vaillant 16y ago
  To date, I have seen no language except Qi that (1) supports sum types, and (2) isn't a statically typed functional language. Anyway, it's not like a wannabe OO language would adopt Algebraic Data Types. "Those are for these ivory tower languages that no one use in the real world", one might say. Qi: http://en.wikipedia.org/wiki/Qi_%28programming_language%29 http://en.wikipedia.org/wiki/Qi_%28programming_language%29
eru 16y ago
Or try D.

Perhaps Google's Go will end up being the answer.

by gms 16y ago

Perhaps Google's Go will end up being the answer.

masklinn 16y ago

No. And thank science for that.

sausagefeet 16y ago

I think many people were hoping for it but Go fell fatally short in 2 key areas IMO: 1 - Error handling - Go doesn't have any powerful mechanism for error handling. The code I have seen is rather inconsistent and it doesn't solve the main problem from C of forcing people to handle errors. 2 - Polymorphism - They left any kind of generics out. I think this could go a long ways for (1) too, just look at Either or Maybe type in Haskell. Combine this with some pattern matching and you have a really powerful way to enforce error handling and have polymorphic data structures and functions. IMO this is the biggest failing of Go. I think the failure to provide those two things also makes Go a future mess. Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess.

dchest 16y ago
Adding them later either breaks a lot of outstanding code or it means you have to versions of Go, the original and new which is a mess. Actually, the creators of Go are still not afraid of breaking things. For example, recent release (2011-02-01.1¹) changed the syntax of non-blocking channel operations, and it broke code. [1] https://groups.google.com/d/topic/golang-nuts/uHfjRyO1Q6c/discussion https://groups.google.com/d/topic/golang-nuts/uHfjRyO1Q6c/di...
- sausagefeet 16y ago
  That is good to see. But I would argue that the change described here is a rather small change while the 2 missing features I described have a larger effect on how you design your application.
  - jbooth 16y ago
    Well, adding generics shouldn't break working code.. it's an additive change. It says something that for the built-in collection types, Slice and Map, they had to hack around their own API and implement this-case-only ad hoc generics. Slice and Map should be fully implementable within the language.
    - supersillyus 16y ago
      Why should Slice be fully implementable within the language? C++ is another systems language that decided that everything should be able to be done in libraries, and we've all seen the complexity that results.
      - jbooth 16y ago
        Well, I'll back off slightly from the assertion "fully implementable" because you have the f = s[i] syntax which wouldn't be fully implementable unless you allow the user to define [], which I agree is crazytown. However, the make() functions for slice and map are the only functions in the language that allow you to pass in a type and get that type back as a return function. Why can't users have that functionality? Generics seem to be the easiest way to get it.
        supersillyus 16y ago
        I think I agree, but I'm not good enough at language design to be sure. :) In the current language, all uses of type literals need to be known at compile time; if I could pass a variable containing a type to "make" or use it to instantiate a map, the language needs generics to deal with that, and all of the complications that come with it. The current idiom seems to be (if I wanted my own "make"): myslice := mymake((MyType)(nil), 10).([]MyType) which is much uglier than the built-in way. However, I'm kinda okay with reflection-laden runtime tomfoolery looking a bit messy, mostly because I rarely use it, and when I do I like it to stand out and be obvious what is going on.
deleted 16y ago
[deleted]
supersillyus 16y ago
I don't agree with #1. I prefer Go error handling to pretty much any other style I've seen.
loup-vaillant 16y ago
To date, I have seen no language except Qi that (1) supports sum types, and (2) isn't a statically typed functional language. Anyway, it's not like a wannabe OO language would adopt Algebraic Data Types. "Those are for these ivory tower languages that no one use in the real world", one might say. Qi: http://en.wikipedia.org/wiki/Qi_%28programming_language%29 http://en.wikipedia.org/wiki/Qi_%28programming_language%29

eru 16y ago

Or try D.