SoylentNews is people
SoylentNews
from the Obfuscated-Rust-Competition-doesn't-sound-right dept.
In spite of my status and obvious bias as co-creator of D, I'll do my best to answer candidly; I follow Go and Rust, and I also definitely know where D's dirty laundry is. I'd encourage people with similar positions in the Rust and Go communities to share their honest opinion as well. So here goes.
First off, C++ needs to be somewhere in the question. Whether it's to be replaced alongside C, or be one of the candidates that's supposed to replace C, the C++ language is a key part of the equation. It's the closest language to C and the obvious step up from it. Given C++'s age, I'll assume in the following that the question also puts C++ alongside with C as a target for replacement.
Each language has a number of fundamental advantages (I call them "10x advantages" because they are qualitatively in a different league compared to at least certain baselines) and a number of challenges. The future of these languages, and their success in supplanting C, depends on how they can use their 10x advantages strategically, and how they overcome their challenges.
[Another way to look at this is to ask "What is wrong with C?" and then assess how well these languages solve those problems. -Ed.]
(Score: 3, Informative) by TheRaven on Friday November 13 2015, @02:30PM
Nice as it is, you're not going to write a device driver in Go.
There was a paper from Sun many years ago about writing device drivers in Java. Device drivers need to be able to send exact bit patterns, with well-defined memory ordering semantics, to memory-mapped control registers, which most languages can do with a little bit of run-time environment support (maybe not Go, as it has an explicitly weak memory model with no ordering guarantees in the absence of channels). Some parts of device drivers also have realtime constraints, though often that's a little trampoline in the ISR that delegates work to a larger part of the driver. The main reason that device drivers aren't written in high-level languages is the fact that no one wants to bundle a high-level language runtime with their driver. NeXTSTEP had device drivers in Objective-C and OS X in C++ though, so it is possible to move them to slightly higher abstractions even in comparatively mainstream systems.
That said, the real question is: Which language should replace C in the 95% of places where C is completely the wrong tool for the job, but is used anyway. To address this, you need to understand why C is used and, primarily, it's because it's easy from C to integrate with C code (in both directions, exposing interfaces to C programs and using C libraries). The winning languages in this space are things like Python, not because of any intrinsic merits but simply because they focus aggressively on FFI.
sudo mod me up