I've seen some commotion about it lately. Your thoughts?
Edited by Rafael Abreu
on
Reason: Initial post
No chance.
C is about being a simple language that gets out of the programmers way. C++ CAN be about that, depending how you use it. Rust is a completely different beast.
C is about being a simple language that gets out of the programmers way. C++ CAN be about that, depending how you use it. Rust is a completely different beast.
Ok that's good to see.
As a new programmer myself I have just started learning C/C++ so to see people saying that "it's finally being replaced" didn't fill me with joy.
So I hope to get a discussion about this here which is a community I respect so I can make a decision to stick with C/C++ or get into Rust.
As a new programmer myself I have just started learning C/C++ so to see people saying that "it's finally being replaced" didn't fill me with joy.
So I hope to get a discussion about this here which is a community I respect so I can make a decision to stick with C/C++ or get into Rust.
RafaelAC
I've seen some commotion about it lately. Your thoughts?
My response depends on where you see this commotion coming from. Languages like Go, Rust, etc. have big companies promoting them through sheer PR muscle, often in ways invisible to us, for reasons entirely unrelated to your individual well-being.
The type of people who use C professionally are not going to be on Twitter passionately advocating for it. The simplicity of the language remains a necessary property for critical industries around the world. These industries are not on social media talking about programming languages either :P
That doesn't mean I'm not in favor of evolving beyond C. I'm rooting for Zig, and Odin, and so on. So is John Carmack (at least for Zig), whom I've said before is an ally of Handmade.
Our time will come.
If a language "replaces" c++, we might as well think of it as c+++. C will remain the binary interface language for understanding how dynamic libraries work. C++ provides abstraction with optional safety, but not fool-proof safety.
Wouldn't mind having a safe C++ subset similar to Basic for the majority of high-level code that doesn't have to touch raw pointers or uninitialized variables, so that beginners can join a project without shooting their legs off. Just have to interface well with C and allow replacing the core types for specific needs. Sometimes you're in a company full of juniors and just have to make the best of the situation. Either build a little fortress around the codebase and watch them resign, or give them tools that they can handle and prevent 90% of their mistakes.
Wouldn't mind having a safe C++ subset similar to Basic for the majority of high-level code that doesn't have to touch raw pointers or uninitialized variables, so that beginners can join a project without shooting their legs off. Just have to interface well with C and allow replacing the core types for specific needs. Sometimes you're in a company full of juniors and just have to make the best of the situation. Either build a little fortress around the codebase and watch them resign, or give them tools that they can handle and prevent 90% of their mistakes.
First off, there is no language called "C/C++".
I have said it before and I'll say it again. There is one main thing preventing Rust from "replacing" C or C++: the existence of 10-year-old codebases that are still being actively maintained.
Greenfield languages might be fine for a startup that may not exist in five years' time. But they aren't a safe bet for anything which must last. Not because Rust won't be around in 10 years, because it probably will. But of the five possible ways to solve a tricky system problem, we don't know which one will still be supported and which three will force a substantial rewrite. And we won't until we have that much experience.
If we had 10-year-old codebases in Rush which had been continuously maintained for that time, this would imply a critical mass of other Rust stuff. That’s the point where we could say that Rust might be a language that you could rely on.
The same goes for languages like JAI, by the way. I like it. I want to use it. I want to write stuff in it. I still wouldn't bet my startup on it at this point in history.
I have said it before and I'll say it again. There is one main thing preventing Rust from "replacing" C or C++: the existence of 10-year-old codebases that are still being actively maintained.
Greenfield languages might be fine for a startup that may not exist in five years' time. But they aren't a safe bet for anything which must last. Not because Rust won't be around in 10 years, because it probably will. But of the five possible ways to solve a tricky system problem, we don't know which one will still be supported and which three will force a substantial rewrite. And we won't until we have that much experience.
If we had 10-year-old codebases in Rush which had been continuously maintained for that time, this would imply a critical mass of other Rust stuff. That’s the point where we could say that Rust might be a language that you could rely on.
The same goes for languages like JAI, by the way. I like it. I want to use it. I want to write stuff in it. I still wouldn't bet my startup on it at this point in history.
Edited by Andrew Bromage
on
My response depends on where you see this commotion coming from.
I've seen a youtube video about it in my native language. They were basing this claim on a piece of news about microsoft rewriting parts of windows in Rust. I found this on the subject.
The term memory safety keeps coming up in this conversation and I confess I don't really understand what it means, can anyone explain what is so unsafe about C/C++?
RafaelAC
The term memory safety keeps coming up in this conversation and I confess I don't really understand what it means, can anyone explain what is so unsafe about C/C++?
int myArray[32];
By default, an array using square brackets have no run-time bound checks. You can use template classes to go around this, but with a more verbose syntax.
int myUninitializedVariable;
int myInitializedVariable = 0;
When declaring an integer or float without directly assigning a value, it may be uninitialized and suddenly start with a high value on another computer with less memory where old data is more likely to contain ones.
In safe languages like Basic, a bound-checked collection uses a class under the hood while allowing to turn it off using a compiler flag. Most modern languages initialize new variables to zero when left undefined. Safety doesn't have to cost any performance at run-time, but C++ is relevant when the safety adds restrictions that doesn't work for a specific purpose. Writing a memory allocator only makes sense in C-level programming where a buffer of data is just generic data without any higher meaning.
Edited by Dawoodoz
on
So the difference between a safe to an unsafe language when it comes to memory would be that in the case when I try to access an array out of its bounds the safe language would throw an error while the unsafe one would crash the app?
Similarly with uninitialized variables, unsafe language would behave unexpectedly with no warnings while safe language would warn you about it. Do I understand it correctly?
On that note, would a safe language be able to catch such violations when they occur after a long sequence of user interactions? If not I fail to see how much that even helps since we can see such crashs immediately.
I am biased towards C of course so maybe Im not seeing it clearly, is this safety issue really a big deal?
Similarly with uninitialized variables, unsafe language would behave unexpectedly with no warnings while safe language would warn you about it. Do I understand it correctly?
On that note, would a safe language be able to catch such violations when they occur after a long sequence of user interactions? If not I fail to see how much that even helps since we can see such crashs immediately.
I am biased towards C of course so maybe Im not seeing it clearly, is this safety issue really a big deal?
Yes, pretty much. Some languages can throw exceptions for overflow and limit the size of user input. It's easier to catch and recover from errors in secure systems when attacked...
Overflow detection is difficult to implement in C++ (because expansive multiplication and branch prediction hints are hardware specific), so an implementation might end up slower than a safe language if you try to re-implement all the higher features. It might be easier to write your own compiler than to implement it well in C++. A higher language can also recognize its own types on a higher level and do powerful optimizations adapted for abstract programming patterns. Convert tail recursion into a loop, replace heap allocation with stack allocation, re-use register using alias detection, remove run-time checks where proven correct using static analysis...
A safe language will say that index 20 in staffArray was out of bound 0..19 and instantly take you to the line you have to fix in the IDE, therefore saving precious minutes paid by a company. Then you can make a release after testing and be sure that the customer gets the same quality that you experienced on your system.
An unsafe language will act strange with memory corruption until the operating system shows you an unrelated error in a completely different module. Sometimes looks okay until years later when an assumption about hardware no longer holds true. Might even get a blue-screen and lose a day's work.
The sooner you get the crash, the less it costs to fix by still remembering what might have caused it. The more information you get from the crash, the easier it is to fix.
Overflow detection is difficult to implement in C++ (because expansive multiplication and branch prediction hints are hardware specific), so an implementation might end up slower than a safe language if you try to re-implement all the higher features. It might be easier to write your own compiler than to implement it well in C++. A higher language can also recognize its own types on a higher level and do powerful optimizations adapted for abstract programming patterns. Convert tail recursion into a loop, replace heap allocation with stack allocation, re-use register using alias detection, remove run-time checks where proven correct using static analysis...
A safe language will say that index 20 in staffArray was out of bound 0..19 and instantly take you to the line you have to fix in the IDE, therefore saving precious minutes paid by a company. Then you can make a release after testing and be sure that the customer gets the same quality that you experienced on your system.
An unsafe language will act strange with memory corruption until the operating system shows you an unrelated error in a completely different module. Sometimes looks okay until years later when an assumption about hardware no longer holds true. Might even get a blue-screen and lose a day's work.
The sooner you get the crash, the less it costs to fix by still remembering what might have caused it. The more information you get from the crash, the easier it is to fix.
Edited by Dawoodoz
on
RafaelAC
So the difference between a safe to an unsafe language when it comes to memory would be that in the case when I try to access an array out of its bounds the safe language would throw an error while the unsafe one would crash the app?
Throwing some kind of catchable error, and unceremoniously crashing the application, are actually both considered to be memory-safe things to do in that scenario. The important thing is that you don't allow out-of-bounds array access one way or another. What would make a language unsafe, is if it sometimes allows you to successfully read or write data from outside of array bounds and then continue running the program, because that leaves the door open for hard-to-diagnose memory corruption bugs, or worse, potential malicious attacks that take advantage of memory corruption to steal data or hijack the software.