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: 0) by Anonymous Coward on Friday November 13 2015, @11:53AM
Always initialize ALL variables.
Though there are some special rule about implicit initialization of global variables in C, which does make a difference in kernel development (size of the compiled kernel, I guess technically the same is valid for user programs, but 1) when was the last time you saw a user program that cared about a few kilobytes, and 2) kernel developers already need to know a whole lot more about what the compiler actually does than the average non-kernel developer).
(Score: 2) by TheRaven on Friday November 13 2015, @02:24PM
Though there are some special rule about implicit initialization of global variables in C
Uninitialised globals are implicitly initialised with 0. The reason you might want to initialise them to 0 is to avoid headaches from common linkage.
sudo mod me up
(Score: 1) by andersjm on Saturday November 14 2015, @02:42PM
Never initialise any variable if you don't know the correct value yet.
Over-initialisation with incorrect but plausible looking values is a killer for static analysis: Lint can't tell the difference between a variable that has been set to K because K is the correct value for the variable at that point, and a variable that has been set to K because the programmer decided it should be set to something, anything.
The exception is initialising to a trap value, something that will trigger a visible fault if any attempt is made to use it. I'm OK with initialising a pointer to null as a trap value on that basis, because on platforms with memory protection, null pointer accesses are trapped. It's not an ideal trap value though, because often null is considered a legal value for a variable.