C++ in Coders at Work

Re:C++ in Coders at Work by sausagefeet on Tuesday February 15, 2011 @09:40AM (#2221327)

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.

[ Parent | on HN ]

Re:C++ in Coders at Work by dchest on Tuesday February 15, 2011 @09:55AM (#2221369)

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/di...

[ Parent | on HN ]

Re:C++ in Coders at Work by sausagefeet on Tuesday February 15, 2011 @11:19AM (#2221763)

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.

[ Parent | on HN ]

Re:C++ in Coders at Work by jbooth on Tuesday February 15, 2011 @11:47AM (#2221947)

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.

[ Parent | on HN ]

Re:C++ in Coders at Work by supersillyus on Tuesday February 15, 2011 @12:47PM (#2222278)

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.

[ Parent | on HN ]

Re:C++ in Coders at Work by jbooth on Tuesday February 15, 2011 @01:42PM (#2222566)

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.

[ Parent | on HN ]

Re:C++ in Coders at Work by supersillyus on Tuesday February 15, 2011 @06:48PM (#2224011)

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.

[ Parent | on HN ]

Re:C++ in Coders at Work by supersillyus on Tuesday February 15, 2011 @12:39PM (#2222238)

I don't agree with #1. I prefer Go error handling to pretty much any other style I've seen.

[ Parent | on HN ]

Re:C++ in Coders at Work by loup-vaillant on Wednesday February 16, 2011 @11:07AM (#2226918)

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

[ Parent | on HN ]

Re:C++ in Coders at Work by eru on Thursday February 17, 2011 @05:19AM (#2230465)

Or try D.

[ Parent | on HN ]

Re:C++ in Coders at Work by masklinn on Tuesday February 15, 2011 @09:37AM (#2221317)

No. And thank science for that.

[ Parent | on HN ]