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."
Permalink for comment 548546
To read all comments associated with this story, please click here.
RE[9]: C -> Go
by Valhalla on Sun 13th Jan 2013 00:25 UTC in reply to "RE[8]: C -> Go"
Member since:

These systems are also native

Heh, I should have checked up the name of the language, Native Oberon is a quite telling name ;)

I just have user experience, no benchmarks.

They are good enough to use as desktop system, with text editing software, video and sound processing, Internet usage, for example.

Which really doesn't tell me anything, it's an unmeasurable anecdote.

But let me reiterate, should there be a garbage collected memory safe operating system with the same or just about the same performance as that of native, manually memory managed operating systems then the industry would pounce on it in a heartbeat since these are all great features... until you factor in the performance cost, which is why Linux/BSD/NT/Darwin haven't been replaced.

There really isn't any conspiracy going on, there's simply no 'oh, this is good enough performance' when we are talking about operating systems / kernels. In userspace, sure, but not in such core functionality which in turn has such a profound impact on the overall performance when put under pressure like in high performing servers, computing clusters, super computers etc. Areas where something like even a 3% performance difference isn't brushed off as irrelevant.

Heck I've seen hardcore gamers curse for less of a performance drop than that ;)

System programming languages with GC, also allow you to disable the GC in critical sections and make use of manual memory management in unsafe/system code sections.

Yes, pretty much all garbage collected languages allows for some sort of unsafe operation/mode, but entering and leaving critical sections comes with a performance cost and you are then adding complexity + possible bugs you tried to avoid by using a safe garbage collected language in the first place.

You are still left with less performance than native code and you may have introduced memory bugs, can't say I personally find that solution very attractive.

I don't always use garbage collecting, but when I do, I use full garbage collecting.

Reply Parent Score: 2