Linked by MOS6510 on Thu 10th Jan 2013 23:25 UTC
General Development "For years I've tried my damnedest to get away from C. Too simple, too many details to manage, too old and crufty, too low level. I've had intense and torrid love affairs with Java, C++, and Erlang. I've built things I'm proud of with all of them, and yet each has broken my heart. They've made promises they couldn't keep, created cultures that focus on the wrong things, and made devastating tradeoffs that eventually make you suffer painfully. And I keep crawling back to C."
Thread beginning with comment 548549
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[9]: C -> Go
by Valhalla on Sun 13th Jan 2013 00:49 UTC in reply to "RE[8]: C -> Go"
Valhalla
Member since:
2006-01-24

Even though it didn't appear so initially I think we agree more than we disagree.

I think so too, like I said, I like Go ;)


I disagree with you here. Performance is multidimensional and those three factors are the primary factors.

Sure, but if you omit the words memory usage or code size and simply say 'language performance' it will most likely be the generated code performance that is being referring to as that is the most common metric being compared, particularly in benchmarks.


Also, you are correct, the Go tip/1.1 garbage collector is much better.

Great, haven't built tip since before 1.03 so I'm in for a nice surprise by the sound of it. Go 1.1 still slated for Q1 I hope?

"We did not want to be writing in C++ forever" -Rob Pike

Well, like I said I think Go has a good chance at taking on C++/Java/C# in the application space, both on the end user desktop and enterprise.

From my as of yet meager time with the language I think that the built-in concurrency primitives (goroutines and channels) are likely the best features when it comes to 'selling' the language.

Again given how 'more cores!' seem to be the cpu manufacturers battlecry these days, a language like Go which makes it easier to make use of an increasing number of cores without exposing the programmer to increasing complexity has a very bright future in my opinon.

Reply Parent Score: 2

RE[10]: C -> Go
by voidlogic on Sun 13th Jan 2013 16:25 in reply to "RE[9]: C -> Go"
voidlogic Member since:
2005-09-03

Go 1.1 still slated for Q1 I hope?

Nope, I was hoping it would be that soon as well.

Here is a burn down graph, my understanding is when the blue line hits bottom 1.1 will be ready for release: http://swtch.com/~rsc/go11.html#

In the meantime you can always grab a snapshot of Go tip. A couple of the go core devs I talked to feel that for performance intensive uses this is the way to go. You can use the google issue tracker to make sure you don't care about any issues in a particular snapshot (many are feature enchantments, etc)

Reply Parent Score: 2

RE[11]: C -> Go
by Valhalla on Sun 13th Jan 2013 18:39 in reply to "RE[10]: C -> Go"
Valhalla Member since:
2006-01-24


In the meantime you can always grab a snapshot of Go tip. A couple of the go core devs I talked to feel that for performance intensive uses this is the way to go. You can use the google issue tracker to make sure you don't care about any issues in a particular snapshot (many are feature enchantments, etc)

Probably give it a shot again, last time I tried it (pre 1.03) there were some problems with some cgo bindings I used.

Still it's not as if I can't wait for the 1.1 release, as I said I'm not doing any production code in Go so performance isn't really an issue. Just trying to grok the language on my spare time, sofar so good ;)

Reply Parent Score: 2