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 548513
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: C -> Go
by moondevil on Sat 12th Jan 2013 17:22 UTC 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[8]: C -> Go
by moondevil on Sat 12th Jan 2013 18:56 in reply to "RE[7]: C -> Go"
moondevil Member since:
2005-07-08

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


These systems are also native, managed was a term coined by Microsoft to differentiate VM code from pure native code.

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.

Of course, some work is needed to really be able to write something like Crysis on those systems, or make them into server systems.

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.


Not even with Assembly you can control the internal processor optimizations, unless you're talking about simple architectures

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.

This how C++/CX works for example.

You get to use the classical manual memory management from C and C++ libraries, the reference counting wrappers from STL and the WinRT references with compiler support.

There was a talk on last BUILD, where Herb Sutter mentioned the Windows code is being slowly migrated from C to C++, where they might take advantage of such facilities.

Before I forget, in CS reference counting is also a form of GC.

Reply Parent Score: 3