Linked by Thom Holwerda on Mon 11th Feb 2013 22:59 UTC
General Development "I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.
Permalink for comment 552199
To read all comments associated with this story, please click here.
My thoughts on Go
by Nelson on Tue 12th Feb 2013 08:25 UTC
Member since:

Very thoughtful and concise, a breath of fresh air from a lot of other languages. At first it seemed confusing but over time I've come to appreciate it.

Read left to right and having the variable be described exactly as read is valuable.

This is an egregious omission. While it is true that Exceptions encourage bad devs from making non-exceptional situations exceptional, the problem is that it isn't black and white.

My method X may be perfectly fine with accepting a null reference, it may even have a specific code path for dealing with it.

Method Y may fail fast when taking a null because there isn't much it can do with it. It wouldn't make sense to try.

Therefore it is at the discretion of the programmer to decide which instances call for an exceptional situation and which don't.

Defer/Panic/Recover are Try/Catch/Finally/Using in an almost comically worse syntax.

Exceptions are also about proving the end user context at run time to perform corrective action and fix the state to potentially try and recover. Error codes or multi return values on their own don't convey this information.

Goroutines / Channels:
I'm not sure I like this as much as I like async/await operations in C# using the TPL. It seems like a much more natural fit to the language without resorting to channels. I'm not sure I like Goroutine isolation.

I'm not really a fan of blocking to receive from a channel when it is all asynchronous in C# and fits elegantly with the language in the form of return values being coerced from Futures.


public async Task<int> GetNumberAsync()
return 42;

it is clear to see the GetNumberAsync() is an asynchronous operation that returns 42 (which may or may not happen immediately)

when I do

var result = await GetNumberAsync();

all the code following this statement gets spun off as a continuation of this operation and the current method returns immediately.

To me it makes async code much less of a disjointed experience when writing it in a sequential fashion. Imagine a chain of awaits in C# vs trying to get a bunch of Goroutines to understand each other via channels that have a non trivial cost.

Still, the intention is a good one. Get people to stop thinking about threads, cores, and pools and start thinking on a higher level. I wonder how their Task (or Goroutine) scheduler compares to the Work stealing task scheduler in .NET

Love the lack of pointer arithmetic. Smart move and +1 for safety.

Overall my problem with Go is that it is just one solution to a multi-faceted problem. Its hard to for example promote asynchrony when you need to maintain support for things like the STD C Lib which destroys the advantages of async code (making async code behave like sync code kills any gains, and degrades perf) and in addition to this, Go requires an IDE effort to make it productive.

I'm a fan of their simplified inheritance model, but you need IDE support to make up for the difference in productivity that's provided out of the box. Its hard at a glance to know which types implement which given interfaces.

It'd probably be worth while for them to do something like explicit interface declarations where a class can explicitly state to support an interface and it can be checked in much the same manner they currently do. What they have now seems to be an inference based inheritance model

Edited 2013-02-12 08:26 UTC

Reply Score: 4