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."
Thread beginning with comment 512370
To view parent comment, click here.
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

satsujinka Member since:
2010-03-11

Please keep in mind that I never said it would be complicated in C. I said it would look bad.

goroutines:
go fun()

channels:
c<-"send a string"
receive<-c

these look much nicer than your C example, in my opinion. Similarly, I like the re-slicing syntax (I believe python has a similar syntax.)
It is true C function declarations are simpler, however, you do get used to Go really quickly. Go is simpler to parse (pure left to right with no look ahead) and function declarations are one thing that needed to change.
Btw, if you have two *int variables you can do this (including multiple returns):

func myFunc(x,y *int) (int, error) {}

Reply Parent Score: 1

jburnett Member since:
2012-03-29

Ahh, now I get it. Some of Go is based on python syntax. I guess that is why they named arrays slices. Actually, it almost looks like somebody took Python, stripped out the OO part, added data typing, and said lets compile this. Which is really cool.

Of course I'm basing this on about 30 minutes spent reading Python docs and about the same time with Go docs. Despite 25 years of coding experience in everything from assembly to ruby, I never learned Python. One of the very few popular languages I have just never needed. Maybe it is time to learn.

Reply Parent Score: 1