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


Ken Thompson, Rob Pike & Robert Griesemer set out at Google to create a modern C.

I just can't buy into the notion of Go as a 'modern C'. There are similarities in syntax, not surprising of course when considering who the authors are, but the languages are targeting different areas.

I do like Go, it's a language I am currently dabbling with and I put it somewhere between python and C. I think it has a great future, largely due to the built-in concurrency features you mentioned since the future seems to hold an ever increasing number of cores per cpu.

But in the domains where C dominate, characteristics like high performance, deterministic memory handling, small memory footprint, no runtime overhead, low-level constructs for efficient data manipulation, ease of use from other languages, etc are what makes it so popular.

Go really doesn't apply here, it will never have the same performance due to being a 'safe' language and also due to having automatic garbage collecting which has logic using up cycles even when it's not actively reclaiming memory. It does not have a comparable small memory footprint as it includes the runtime with each binary, it lacks constructs like unions, it lacks a simple bitfield type, in short it is not a replacement for C.

And when I'm talking about domains where C is dominant, I mean things like system-level code, audio/video encoding/decoding, archivers/compressors, low level frameworks, image/sound manipulation etc.

Currently Go is making it's largest splash in web development, part if this is due to some of it's characteristics, part of it likely is that the web developer space is quite prone to experiment with new languages.

However in the longer perspective I can see Go have a 'go' at replacing C++,Java,C# for application level development.

Desktop applications like for example Libre Office, Inkscape, Gimp, etc could easily have their C++ parts replaced by Go while keeping the underlying C performance critical components (like GEGL for Gimp) where it's necessary.


* The Go compiler is extremely fast, faster than C or D

Yes, but it will get slower once more optimizations are implemented. Still they chose to write their own Go compiler from scratch due to finding the LLVM and GCC backends much too slow so there's good reason to believe it will remain quite fast.


Hmmm.. are you are cherry-picking results or am I missing something? Here is the straight-up list:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all...

Go is quite a bit slower than Java 7 and much slower than C (which is the fastest overall). Still there is a slew of performance improvements in store for Go 1.1 from what I've read so it will be interesting seeing where it lands once that is released. Certainly the performance isn't bad considering it's a 1.03 release of a very young language, but again calling it a modern C is something I find to be nonsense.


* While D appeared in 2001 and Go in 2009 D and Go are now neck and neck on stack overflow and github.

Cherry-picking D as a comparison is rather pointless I think, it does not have the resources that Go enjoys through Google, also it's development history is so unlike that of Go, with community fragmentation over runtimes and standard libraries etc.

Reply Parent Score: 2

RE[6]: C -> Go
by moondevil on Sat 12th Jan 2013 17:22 in reply to "RE[5]: C -> Go"
moondevil Member since:
2005-07-08

Just a small remark, check Native Oberon and Blue Bottle OS.

Desktop operating systems used at ETHZ in Zurich, implemented in GC enabled system languages.

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager

Only the boot loader, and hardware bindings are fully implemented in Assembly, with the remaining parts in Oberon or Active Oberon.

Fully working desktop systems, used for operating system research and teaching.

The main reason mainstream OS are still not using GC enabled system languages is inertia, but this is already changing at least in Windows with the C++/CX extensions.

Reply Parent Score: 3

RE[7]: C -> Go
by Valhalla on Sat 12th Jan 2013 18:25 in reply to "RE[6]: C -> Go"
Valhalla Member since:
2006-01-24

Fully working desktop systems, used for operating system research and teaching.

What are you trying to prove by the existance of such OS implementations? I'm sure someone has a research OS written in a interpreted language aswell.

Show me benchmarks where these systems are evaluated under pressure and compared with native unmanaged equivalents like Linux/BSD/NT.

If something had came along that used garbage collection and memory safety and magically managed to perform as well as native unmanaged code then obviously we'd all be using it by now.

The main reason mainstream OS are still not using GC enabled system languages is inertia

No, it is because we are not ready to give up performance at the system level, the amount of optimization at this level is extreme, we are talking about the use of specific compiler extensions to manually handle such low level aspects as branch prediction and cache prefetching/clearing. You don't want garbage collection pauses in this setting.

But if you have any benchmarks which supports the notion that the reason we are not seeing garbage collected safe language based operating systems used in mainstream computing is that of inertia rather than performance, please show me.

Again, I'd love it if there was some magic silver bullet that allowed us to have full memory safety while having the same performance as in unmanaged native code. In reality it's a tradeoff, and in areas such as kernel level code where low latency is absolutely crucial, performance trumps convenience.

Native code related bugs gets squashed, it's performance remains.

Reply Parent Score: 2

RE[6]: C -> Go
by voidlogic on Sat 12th Jan 2013 19:43 in reply to "RE[5]: C -> Go"
voidlogic Member since:
2005-09-03

I just can't buy into the notion of Go as a 'modern C'. There are similarities in syntax, not surprising of course when considering who the authors are, but the languages are targeting different areas.


C might have a limited domain now, but you are forgetting when it was written is was very much a general purpose language. In the same way Go is.

But in the domains where C dominate, characteristics like...

Go might not have these qualities compared to C, but it does have many of these qualities compared to modern applications programming languages. Outside of writing a OS, Go's problem domain is a super-set of C as used in modern times.

Yes, but it will get slower once more optimizations are implemented.

I think you don't understand what makes Go fast to compile: http://golang.org/doc/go_faq.html#What_is_the_purpose_of_the_projec...

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

Hmmm.. are you are cherry-picking results or am I missing something? Here is the straight-up list:

You are missing something.

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

2. If you do include it, you will see only very fast languages like C/C++/Java beat Go out (and Go is improving) Go beats most languages on the list (including C# Mono).

Most importantly:
3. Your link is only considering execution time, my link is a composite of execution time, memory usage and code size (weighted the same).

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 (hence its reputation). You can play with the weights of my first link to reflect your own priorities regarding exec time vs memory usage vs code size and make your own call.

but again calling it a modern C is something I find to be nonsense.

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. I'm not suggesting Go replaces what C is used for primaily nowadays (in some cases). The primary use cases of C has changed, I mean "modern C" in regards to C's original more general purpose nature.

Cherry-picking D as a comparison is rather pointless I think

...I was responding to someone who was comparing Go and D... I don't think D is particularly relevant to most developers.

Reply Parent Score: 2

RE[7]: C -> Go
by Valhalla on Sat 12th Jan 2013 23:30 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