[sanjayts]

Sorry if you saw this coming but do you really not miss generics and exceptions? I like Go given that it's a lean language and the compiles down to a self contained binary which doesn't consume gobs of CPU or memory and is pretty quick to start-up and run. Perfect language for writing command line tools and one-off network clients.

But I dread the feeling of writing repetitive error handling code and copy-pasta to get a simple generic functionality to work across data types. Maybe I should just consider it a better C and move on...

[bborud]

I haven't wrapped my head around how I want to do error handling in Go yet, so it is a bit early to say. I think I really need to write more code that deals with abstraction layers before I can have a useful opinion on the matter. Not that I'm too worried about not having figured out that bit yet since error handling took me a while in all other languages as well. (I think my first approach was to use panic() where I used exceptions in Java. But that doesn't really tell you anything very useful unless you also know how I use exceptions in Java :-))

I don't mind a bit of boilerplate as long as it produces understandable code. Writing boilerplate can be automated. Reading and understanding code can't.

I do understand where you are coming from though. Perhaps we're getting a bit spoilt as programmers in feeling that error handling should be ... more elegant for a language designed within the last decade? :-)

I think the same goes for generics, though I have a hunch that I'm not going to miss it. And I'm not sure why, but that's how it feels now. Whenever I do design classes that are genericized in Java I do so sparingly. This is mostly to ensure that the code is easy to reason about. I'm not fond of "clever" uses of generics because while it may feel satisfactory to have things click together in a beautifully complex manner, it can make code hard to read.