I'm sorry to be this blunt, but it's quite apparent that you haven't done any serious systems programming. That you were surprised by the syscall underlying multiprocessing...says a lot although I could point to other indications.
Please don't make assertions as to the necessities of a specialty you haven't delved in, it makes it very difficult for me to be civil and respectful.
There is...no real comparison between C/C++ and Java for last-mile performance at the bleeding edge, even if Java is a VERY good high-performance replacement for Python for stuff like network services.
There are a variety of other use-cases where C/C++/Fortran/Ada are extremely necessary. Also note how abysmal Java has been for Android compared to Obj-C with its ever-present escape-hatch to raw C for making responsive and pleasant mobile apps. Especially games.
That aside, stuff like Singularity is research-grade only for very clear and obvious reasons. It isn't practical yet, if ever it would be.
Losing a lot of potential performance and control over the machine at the universal OS level is pretty...damaging and limiting.
It's bad enough that an entire programming language ecosystem can put a cap on your power over the computer and the performance/behavior thereof, to do that at the OS level except as a research project is unconscionable.
Please don't act as if Wikipedia articles about Microsoft Research projects are some indication of the vanguard of operating systems.
> you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++.
Er, maybe in the trivial case. You won't have anything close to a deterministic or real-time model for memory management available to you though. And never will.
Everything Go provides on top of C in terms of extra features essentially requires GC to function. (goroutines, and related features). The only thing it really adds on top of C that doesn't necessitate the GC is most aspects of the type system. That could be reused in a hypothetical systems language.
Go itself, in its current design, has absolutely zero future as a systems-language-of-first-resort outside of tinkering. (Some people will cross-compile Go code to chumbys and stuff.)
However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it. I would rather it did that than focused on trying to compete with C or C++. It's not suited to the task and cannot be reconciled with that goal as a fundamental property of its design.
Go is an excellent language for network services. Like Java. Doubly so once they replace that awful garbage collector in 1.1
now we both came here to get a discussion going; now we've got one, you can drop out of the troll personal attack mode.
So you have made quite clear that you find the various named non-bare-metal languages used for 'systems projects' distasteful. But you can't make them undone. You can say they were the wrong tool for the job in your opinion, too, but you can't say that others are wrong to consider them system languages.
An easy and accessible rule of thumb goes as follows:
Could I use this language for:
Writing an OS for a PDP-11 that was reasonably close to the assembler in performance albeit not compactness?
&&
Writing hard real-time constrained avionics software?
&&
Writing HPC software for scientific purposes that takes advantage of strict memory control and vectorized, hardware-specific instructions for maximum throughput?
With varying degrees of expertise and specialty, C, Fortran, Ada, and C++ all qualify.
Try writing even a simple linear algebra algorithm in Java. You won't get anywhere near Fortran or C++. Try as you might. Even relatively sundry CV work is unpleasant outside of the prototype phase on anything but C++/et al.
I'm sorry you felt attacked, but the scope of experience is relevant to the subject. I realize it's very difficult to discuss one's limitations, or have them pointed out by others, without internalizing it and making it a subject of ego.
I generally stick to the high level tier of languages until I am forced to drop down a layer. Experience and pain have stripped me of all hubris that could lead me to believe humans could overcome the fundamental semantic and informational constraints involved in optimizing code that needs to concern itself with the machine-behavior from a higher abstraction layer. I've done more JVM and GC fiddling than I care to recall.
There's a glass ceiling, you won't escape it. Even Paul Graham, the master Common Lisper himself, took advantage of the relatively easy to use FFI faculties in Lisp to drop down to C to optimize hotspots. This was a common pattern when he was doing ViaWeb, I'm told.
It doesn't have to be that way. I am genuinely sorry if you felt attacked or that I was uncivil. I will find other ways to express myself if I run into another similar situation here. That was a failing on my part, please forgive me.
I'm not wont to pontificate to plumbers as to how they should go about plumbing. I say that as someone who's actually redone the plumbing in a residence from top to bottom with my bare hands before. Despite that, I know I'm not a professional plumber and I don't have the experience necessary to say much about it even if I've technically "dabbled".
I don't let a little experience overstep its bounds.
I was pretty familiar with the intracities of real-time called iirc "guaranteed service" back when I worked at Symbian. That was a kernel written in dialect of C++. And I've written camera and video capture software for, among others, Android phones. So fairly general experience, I'd say. Still so much more to learn.
You, on the other hand Chris, keep calling out Rob, me and anyone else who thinks that PDP-11 is not a necessary requirement for the next decade's "system language" ;) What systems projects have you worked on then?
Indeed I used Oberon (both native and windows-hosted) for a few intense months back some summer in the 90s. I still have a fondness, perhaps rose-tinted by time, for Pascal languages.
I particularly remember when someone made an Oberon pcode VM browser plugin as a 'competitor' to the newfangled Java applets. I think it was caled Juice or something.
Interestingly Chrome NaCL is going in the same direction, distributing pcode (well, LLVM IR iirc) and doing final compilation on-target.
>However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it.
If you had to stay on the JVM platform (for argument's sake) and supplant the Java language - would you choose a particular language ? I have read your comments above on Clojure and was wondering what you thought about Scala ?
For my preference, I'd rather use Haskell or Clojure but, I appreciate the ecumenical attitude it brings to the table and I think it's an excellent choice for Java developers that want to grow and learn.
Please don't make assertions as to the necessities of a specialty you haven't delved in, it makes it very difficult for me to be civil and respectful.
There is...no real comparison between C/C++ and Java for last-mile performance at the bleeding edge, even if Java is a VERY good high-performance replacement for Python for stuff like network services.
There are a variety of other use-cases where C/C++/Fortran/Ada are extremely necessary. Also note how abysmal Java has been for Android compared to Obj-C with its ever-present escape-hatch to raw C for making responsive and pleasant mobile apps. Especially games.
That aside, stuff like Singularity is research-grade only for very clear and obvious reasons. It isn't practical yet, if ever it would be.
Losing a lot of potential performance and control over the machine at the universal OS level is pretty...damaging and limiting.
It's bad enough that an entire programming language ecosystem can put a cap on your power over the computer and the performance/behavior thereof, to do that at the OS level except as a research project is unconscionable.
Please don't act as if Wikipedia articles about Microsoft Research projects are some indication of the vanguard of operating systems.
> you can still x-ray some Go code and have a pretty shrewd idea what the resulting machine code looks like, just like C/C++.
Er, maybe in the trivial case. You won't have anything close to a deterministic or real-time model for memory management available to you though. And never will.
Everything Go provides on top of C in terms of extra features essentially requires GC to function. (goroutines, and related features). The only thing it really adds on top of C that doesn't necessitate the GC is most aspects of the type system. That could be reused in a hypothetical systems language.
Go itself, in its current design, has absolutely zero future as a systems-language-of-first-resort outside of tinkering. (Some people will cross-compile Go code to chumbys and stuff.)
However, it has something more excellent available to it. A potential future as the hero that slayed Java and supplanted it. I would rather it did that than focused on trying to compete with C or C++. It's not suited to the task and cannot be reconciled with that goal as a fundamental property of its design.
Go is an excellent language for network services. Like Java. Doubly so once they replace that awful garbage collector in 1.1