I think it's interesting that the famous tech companies are all developing programming languages that are less managed than java/c#, but more predictable (read: less undefined behavior) than c/c++. Facebook seems interested in D, Apple has Swift, Microsoft has some sort of secret project they are working on, Google has Go, and Mozilla has Rust. Even c++ seems to be attempting to modernize with the new additions to it's spec. And now we see a desire for c itself to change. I wonder if our industry is at a turning point where managed languages aren't quite cutting it, but no one is comfortable going back to the 'good old days'.
On a personal note, I like the idea of friendly C so much that I finally made an HN account. One of my favorite things to do is to take things apart and understand them. I was mortified when I learned the real meaning of undefined behavior in c/c++. It seems like the only way to be sure you understand a C program is to check the generated machine code. Even worse is that when I try to talk to other developers about undefined behavior, I tend to get the impression that they don't actually understand what undefined behavior means. I can't think of a way to verify what they think it means without insulting their intelligence, but hopefully the existence of something like friendly C will make it an easier discussion to have.
I wonder if the managed languages "aren't cutting it" because they're not fashionable and seen as stinky old dinosaurs to the generation of developers growing up now?
I mean, some people openly scoff at languages that aren't Python or ECMAScript, and it appears to be very/extremely fashionable/obligatory on HN to aggressively bash C++, even when it appears that many haven't written or maintained anything in it, and casually dismiss it as "complicated" and daft as it has no compulsory garbage collection. "Huh! It allows to you address memory! HOW STUPID. Why would a language even exist anymore that lets you do that?!"
When reading some of the concepts behind C++ and the reasons for decisions, some of them make excellent sense. The 'newer' languages are simpler, primarily because they haven't had decades of existence for people to demand the features that people have demanded in C++.
Where I work we use C and C++ for most things, but that's just the industry we're in. It appeared to become the norm to teach Java at universities now (from the people I have bumped into), so C++ and C are no longer the starting points for development for most graduates, perhaps?
I think it's also a question of using the tools that fit the problem.
If the fashionable choice is to use C++ for example, a lot more can go wrong if the programmer isn't doing thing right.
Now if you have the same situation with a higher level language, the worst that can happen is infinite loops.
Most projects don't need the extra performance C++ would provide.
So most of the time it's a better choice to use a higher level, more predictable language like Node.js or Go.
Since ECMAScript engines like V8 have been optimised a lot in the last years too, the performance difference is not that high either.
This is not only about extra computational performance, but also about predictability, I'd love to program on a hard real time system with Go instead of C++, but given it uses GC, it is not going to happen. I have mostly worked on real time embedded systems, and I only encountered C and C++, mostly because there is no other sane choice available.
> Microsoft has some sort of secret project they are working on
Microsoft has a multitude of secret programming language projects, and the nice thing about them is that when they migrate into C#, people actually will use them.
I've been a C developer most of my professional life, and I find any discussion about the 'right way to write C' to be worth the effort, usually, because it means either more C coders will be produced with always-interesting results, or the kinds of developers who shouldn't be C coders in the first place will wander off and invent something new and shiny to play with instead. Both conditions are valid.
C is such a thorny language precisely because of the trouble you can get in, and as such it does require a degree of competence that your average IDE-wielding neophytes are not willing to conjure up in all their free time. Digging into the details is the only way to succeed with C.
For me the breakthrough came during my SIL-4 professional period (safety-integrity level 4, life-critical systems..) experience, wherein I learned the value of testing, and always testing, and strict requirements with standardized rules. I also learned the value of code-coverage tools and why you use them to increase the 'safe-ness' of your code. And yes, your issue with undefined behaviour, means of course you should never rely on your compiler/IDE to tell you what is going on, and should know by inspection, always!
In the end though, C still has a lot of uses and applications left to be written - its not going away any time soon - and so as long as a group of people are willing to agree to what they are doing with the C code base, good stuff gets built.
You've made an interesting observation regarding the trend taking place in large tech companies.
>but no one is comfortable going back to the 'good old days'.
Except the open source community. Both recent and on-going projects are being done in C. I'd like to know why but I'm thinking the Linux kernel being in C has a lot to do with it.
On a personal note, I like the idea of friendly C so much that I finally made an HN account. One of my favorite things to do is to take things apart and understand them. I was mortified when I learned the real meaning of undefined behavior in c/c++. It seems like the only way to be sure you understand a C program is to check the generated machine code. Even worse is that when I try to talk to other developers about undefined behavior, I tend to get the impression that they don't actually understand what undefined behavior means. I can't think of a way to verify what they think it means without insulting their intelligence, but hopefully the existence of something like friendly C will make it an easier discussion to have.