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 548536
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: C -> Go
by Valhalla on Sat 12th Jan 2013 23:30 UTC in reply to "RE[6]: C -> Go"
Valhalla
Member since:
2006-01-24


Furthermore, Go tip (1.1 in dev) has many many more optimizations than Go 1.0.3 and the compiler is 30% faster yet....

Sounds great, but it most likely means that the original compiler had lots of untapped speed improvements prior to this upcoming version. Implementing optimizations to be applied during code generation will slow the compiling down.

Oh, and both the Go compiler and the Go runtime are written in, you guessed it, C ;)


1. Your link does not include Go in the comparison.

Yes it does, it's two steps behind Java 7.


Your link is only considering execution time

That is how you measure language performance. Memory usage and code size are other metrics.


The is important because although Go is a little slower than Java (which is actually one of the fastest languages, BUT Java uses MUCH more memory

I actually don't think that matters much when it comes to the areas where Go and Java are likely to be deployed (which are unlikely memory constrained areas), obviously it's not a bad trait to use less memory though.

Still I think Go has every chance of eventually beating Java in raw performance, currently Java has what is probably the best in class garbage collector, Go's garbage collector is (as of 1.03 atleast) likely far behind.

Also in overall compiler optimizations the Go compiler sometimes loses out heavily to Gccgo on the exact same code, indicating that there is still alot of room for improvements to be made.

Again, I mean modern C as in C the general purpose language of the 1970/80s, not C is the systems programing language of today.

Well if you had framed it as such then I would have had no problem with your claim, although I would still find it odd to compare Go with C's much more widespread usage in the 70/80's as opposed to the areas it mainly occupies today.

...I was responding to someone who was comparing Go and D...

Ah, my bad, sorry.

Reply Parent Score: 2

RE[8]: C -> Go
by voidlogic on Sat 12th Jan 2013 23:51 in reply to "RE[7]: C -> Go"
voidlogic Member since:
2005-09-03

Even though it didn't appear so initially I think we agree more than we disagree. Perhaps with different emphasis, but:

"Your link is only considering execution time
That is how you measure language performance. Memory usage and code size are other metrics. "

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

Look at something like car performance, it is a combination attributes like maximum speed, acceleration, breaking, handling etc. Again, multidimensional.

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

"Again, I mean modern C as in C the general purpose language of the 1970/80s, not C is the systems programing language of today.
Well if you had framed it as such then I would have had no problem with your claim, although I would still find it odd to compare Go with C's much more widespread usage in the 70/80's as opposed to the areas it mainly occupies today. "

"We did not want to be writing in C++ forever" -Rob Pike
This goes back to the Bell labs guys feeling that C++ took C in the wrong direction. Go is Ken, Rob and Robert's attempt at C like language that they feel improves on C as a general purpose language, going a different direction than C++ took (a path mostly followed by Java/C++).

http://commandcenter.blogspot.co.il/2012/06/less-is-exponentially-m...

Reply Parent Score: 2

RE[9]: C -> Go
by Valhalla on Sun 13th Jan 2013 00:49 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