Go version 1 released
Linked by Thom Holwerda on Wed 28th Mar 2012 19:22 UTC
General Development "Today marks a major milestone in the development of the Go programming language. We're announcing Go version 1, or Go 1 for short, which defines a language and a set of core libraries to provide a stable foundation for creating reliable products, projects, and publications. Go 1 is the first release of Go that is available in supported binary distributions. They are available for Linux, FreeBSD, Mac OS X and, we are thrilled to announce, Windows."
E-mail Print r 2   33 Comment(s) http://osne.ws/jv9
Permalink for comment 512370
To read all comments associated with this story, please click here.
RE[2]: Am I missing something?
by jburnett on Thu 29th Mar 2012 21:59 UTC in reply to "RE: Am I missing something?"
jburnett
Member since:
2012-03-29

You probably could implement goroutines/channels in C, but it would look hideous (in fact most multi-threading/concurrency in C does.)

Why would channels be complicated in C? They are just a queue. Instead of x <- y, you simply do push(x, y) or x.push(y) if using c++.

What makes goroutines any easier than just using pthreads? pthread_create(&pth, NULL, threadFunction, threadArgs) is not that difficult. You have to be a little careful with your function arguments. Of course having real pointers makes this easier since you can map a custom struct to a void *. Aside from that you have to worry about the same things with sync issues.

Pointers are useful for more than pointer arithmetic...

I agree with you, pointers are useful for more than pointer arithmetic. They are great when you want to copy by reference instead of value. However, after reading more about pointers in Go, they seem more like references. My understanding of pointers vs references is that pointers let you do pointer arithmetic, and thus take direct control of the memory. Whereas references take away the direct access are easier for memory management, garbage collection, and new programmers.

Slices aren't any harder to use than arrays, for that matter I don't think I've ever specifically created an array in Go. I'm not sure what you mean by "where is the semi-colon" considering you don't need to put them in.

My mistake, I meant colon, not semicolon. For example, this code is taken straight from the "Tour of Go" on the Go website.


func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}

func main() {
a := []int{7, 2, 8, -9, 4, 0}

c := make(chan int)
go sum(a[:len(a)/2], c)
go sum(a[len(a)/2:], c)
x, y := <-c, <-c // receive from c

fmt.Println(x, y, x + y)
}


It took me probably 30-40 seconds before I realized that it was a[:len(a)/2] vs a[len(a)/2:]. Note the location of the colon, which defines how the slice is re-sliced. This is really cool, but I can already see myself feeling stupid for getting it wrong and spending a couple hours trying to figure out why my results are so weird.

The syntax differences between Go and C are few and far between, but the ones that do exist make Go an easier language to teach (in my opinion.)

I agree that Go seems very C-inspired, much more so than Java. However, it changes very small details. I could be wrong, but I see typos are in store. For example, I can prototype a function - int myFunc(int *x, int *y) {} - in a couple seconds. Typing func myFunc(x *int, y *int) int {} just took me about 8 times longer. Will I get used to it, sure, but it will be a slow process. Also, Go drops parentheses and semi-colons left and right. One article I read said they are not even optional. Just another tiny difference that is going to slow me down.

So again I ask, is there some huge benefit I'm missing? Is Go going to be much faster to develop/maintain/run.? Or is it just a new way to do multi-threading/garbage collection with C inspired syntax that looks prettier to some people?

Reply Parent Score: 1