Solved Is Rust now killing C++ and eventually C with it ?

ralphbsz
Let us assume C/C++ goes away.
What will happen to Vulkan, WINE, FreeBSD, OpenBSD, NetBSD, and many applications, operating systems written in that languages ?

Sure they both are ugly, but if it comes to raw speed, they are unmatched I believe.
The last performance benchmark I saw between Rust and C++ was very close if it comes to performance.
However the C++ runtime is still better than Rusts, or C#.

An example, I had Yuzu vs. Ryujinx, both being nintendo switch emulators.
Yuzu is written in C++.
Ryujinx is written in C#.

Due to yuzu being written in C++ it is faster, but very very broken.
Ryujinx is very accurate, clean, but slower.
But at one point, if the hardware handles it, you do not really notice the runtime performance impact, eventually favoring the slower, but cleaner alternative.

Why the example, I want to say that I agree to your point, but there are so many things which depend on these "ugly" language.

About Rust, I cannot say much, but I am not against it, in general.
I was skeptical of C#, because microsoft, but Ryujinx had proven me that even something created by microsoft can be valuable.
 
6502 said:
Rust killing C... Maybe it will kill also COBOL, C#, Perl and PHP.
Click to expand...
It is not my intention, but a topic I found in the internet.
Rust is developed with system programming in mind, and there is already a progressing Rust based OS.
Only the future can tell what will happen I guess.
 
LillieNB said:
Only the future can tell what will happen I guess.
Click to expand...
This kind of foundational stuff happens very slowly. We will all be long dead before C (or even C++) ever starts to disappear and FreeBSD begins having to rewrite code.

Vulkan should remain unaffected. Just like the poorly named OpenGL, it is a specification rather than a library. It is up to the vendors to implement it in whatever language they like. The main 4 tend to be C++ but this is probably inertia (more mature tools, more skilled workforce, etc).

Besides, one day C++ might be supplanted (whilst it is currently the best native choice outside of C, it *is* horribly broken). But I don't believe Rust will be doing it. Its interop with C and assembly is too naive. Foundational stuff tends to dictate evolution rather than revolution. For example, if Rust came with a minimal C front-end bolted on, it would have made much more impact by now because codebases could evolve rather than become rewrite "memes".
 
I don't think Rust (or Zig for that matter) will come to replace C(++). Yes, the old beasts have a lot of corner cases and undefined/implementation defined behavior that may very opaquely hide problematic access. But as mentioned in other comments, a huge part of that is big corps pushing for faster output and devs taking shortcuts.

When you look at what Rust does to prevent a lot of the safety and access problems, it's mostly inserting things like bounds checks and preventing things like allowing mutability in more than one place. Things that people can do in C(++) as well, but they need to do so manually. If gcc or llvm would start screeching similarly from just static analysis, then most of the advantages Rust had would be ergonomic.

Rewriting things where C and C++ are advantageous in C# or Python had me chuckle though. For any low level access and perf use cases, those are out the window before you consider them.
 
ralphbsz said:
You're ugly.
And you're drunk.
Yes, but I'll be sober tomorrow.
Click to expand...
My favorite of WC Fields

Maybe another applicable story:

A friend of Fields walked to his house and found him sitting on the front porch reading the Bible. Surprised, he asked, "Bill, what are you doing?!"
"Looking for loopholes," he replied.
 
Some have mentioned the US government recommendation to use Rust but here's a reminder that there were a few other languages also mentioned. C#, Go, Java, Python, and Swift.
I quite liked Go myself.
 
LillieNB said:
As I searched the web today, I found that Bjarne Stroustrup called for assistance/help, for making the language more memory-safe ?
Click to expand...

Bjarne and friends have spent more time on politics than coding for most of my adult life. That's why C++ has so many "features" in it. They pretty much added anything that came along to appease the various companies throwing money behind code monkeys. It's only "OO" for the same reason. It's all about getting that sweet Government contract money and selling the books. They've been trying to make it so any idiot working at Burger King can churn out code that doesn't crash since the 1970s.

LillieNB said:
I do not really know how to interpret this, but if C++ really dies, does C also die ?
Click to expand...

C++ has nothing to do with C really beyond the fact that C++ is an abomination intended to mix with existing C code.

LillieNB said:
The American government, cybersecurity experts, etc claim that C/C++ is the source of many memory corruptions, exploits, etc, due to their unsafe memory handling, and everyone should move to memory-safe alternatives like python, C#, Rust, etc ?
Click to expand...

The translation; "We need more tax money so we're going to manufacture a problem and offer a solution to the problem at the same time. Instead of hiring competent people we're going to try to engineer a way for 1,000 monkeys banging on keyboards to shit out working code that can't be "hacked". We also new brand new hardware and we need to replace all the old hardware to run our new engineered solution. Please send money"

LillieNB said:
Sure, there can be memory errors, but is the source not to 99% always the user ?
Click to expand...

Errors in code are human caused problems 100% of the time.

LillieNB said:
What does everyone think about it ?
Click to expand...

I think a lot of people are going to line their pockets with money with no benefit for the tax payers. Same thing that happens every time the Government gets involved with anything.

LillieNB said:
I mean, if everyone ditches C/C++ no one will make new standards, upgrades, etc, right ?
Click to expand...

20 years from now they'll be saying Rust isn't good enough and we need to move on to the new hotness. It's a scam. It's the same scam they've been running since the 1960s. When I was going to college they were doing the same thing with Java and various other programming languages that came and went.

Edit: The only way you'll ever get memory safety is not allowing the user (e.g. you) from writing anything to it. The long term plan is to not have anyone but approved vendors being able to write and run software at all. Along with verifying every end user to a Government ID so everything they do on the locked down software can be watched and the data harvested and picked through for use patterns.

Never forget: The same people crying about how we need <x> for safety in software are the same people that call you a lunatic if you point out the backdoors built into the CPUs at the factory. You shouldn't trust organizations that make the majority of their money spying on end users. Which includes the Government. In fact, the Government requires it now if you want to be in business with them.
 
astyle said:
We all can complain about how Rust has shortcomings - but is there a good, academic article that actually compares the two languages side-by-side, and have some solid benchmarks?

Otherwise, it sounds like pro-Rust and anti-Rust camps are full of people who are rather uninformed about the other camp, and draw conclusions based on very superficial/second-hand info, without considering how correct it really is.
Click to expand...

Benchmarks. LOL. Programming language benchmarks are incredibly difficult and rarely even attempted since they always get torn to shreds right after publication. They are also bogus since you can unfold all kinds of things in the source code that you would keep abstract in a non-benchmarking situation for later changebility. That's actually the biggest issue here.

C and C++ are very hard to beat in an unfolded competition since you can abuse the stack in any unsafe manner you choose, you can have arrays with no bounds checking, there's no integer overflow checking and you can have full or partially uninitialized data.
 
Beastie7 said:
The CHERI Project doesn't get enough mention around here or in the greater open source world. They're doing a lot of really game changing stuff there. Since they're addressing the problem at the lowest level; it really makes this whole debate regarding memory safety and Rust moot IMO.

Brought to you by us FreeBSD folk too. I might add.
Click to expand...

CHERI is more about mitigations than primary defense against exploits, no?
 
Usagi said:
Bjarne and friends have spent more time on politics than coding for most of my adult life.
Click to expand...
This is pretty much how languages gain popularity since C became established. Amusingly Bjarne was kind of called out for this:

Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used
- Ken Thompson
Click to expand...

The Rust people know this and thus lobby it everywhere. They even likely pay the US government to write opinion posts from the whitehouse (example). NSA and CISA (example). They are playing a good game. But that is all it is; its technical merit is OK but certainly not worthy of a religion seen by some redditors, twitter, etc. As a reminder memory safe native languages have existed for decades, ADA, Pascal, as examples.

(There also is a small element of youngsters thinking they can skip some of the career ladder by exploring Rust rather than established standards. Whilst they will have an unfortunate surprise once they hit the industry, it does contribute to Rust's "virality" on social media).
 
cracauer@ said:
Benchmarks. LOL. Programming language benchmarks are incredibly difficult and rarely even attempted since they always get torn to shreds right after publication. They are also bogus since you can unfold all kinds of things in the source code that you would keep abstract in a non-benchmarking situation for later changebility. That's actually the biggest issue here.
Click to expand...
When I talk about benchmarking a language, my assumption is taking a specific codebase, like a library, and seeing if a given implementation performs faster, has fewer bugs, is easier to maintain... We even have an example right here in ports: devel/re2c. It's got 3 implementations: in C, Golang and Rust. You can even take several projects that have implementations in different languages, and see if a given language is a persistent winner in terms of say, performance or bugs.

When a language is picked for a given project, its suitabiity for the project is usually a consideration.There are embedded Java projects out there, but when it comes down to metal, C is still needed. Even Android was at one point touted as a huge use case of Java (Remember how Oracle sued Google over that?), but even Android has parts written in C, because C was shown to be faster than Java... even with Java having specific advantages over C.
 
astyle said:
When a language is picked for a given project, its suitabiity for the project is usually a consideration.There are embedded Java projects out there, but when it comes down to metal, C is still needed. Even Android was at one point touted as a huge use case of Java (Remember how Oracle sued Google over that?), but even Android has parts written in C, because C was shown to be faster than Java... even with Java having specific advantages over C.
Click to expand...
Android is based on the Linux kernel and OpenBSD's libc. Then on top it has Kotlin & Java.
 
Not following lots of debate about this but I personally have the suspicion that the "memory-unsafe" problem actually means "not sandboxed", which is commercially motivated. It's about control of computers by end-users.
 
LillieNB said:
Kind of a silly topic, eventually, but it is still interesting to see how far Rust has come.
I am a big C fan, and C++ was my go-to language for 9 years so, I would not be happy if Rust just overtakes C++ position.
As I searched the web today, I found that Bjarne Stroustrup called for assistance/help, for making the language more memory-safe ?
I do not really know how to interpret this, but if C++ really dies, does C also die ?
The American government, cybersecurity experts, etc claim that C/C++ is the source of many memory corruptions, exploits, etc, due to their unsafe memory handling, and everyone should move to memory-safe alternatives like python, C#, Rust, etc ?
Sure, there can be memory errors, but is the source not to 99% always the user ?

What does everyone think about it ?
I mean, if everyone ditches C/C++ no one will make new standards, upgrades, etc, right ?
Click to expand...
These technical writings of Rust are taken from somewhere on the internet...

Rust is a modern, secure and fast programming language. It offers a simple syntax, a wealth of development tools and a committed developer community. This makes it ideal for developing high-performance and secure applications. For these reasons, Rust has become one of the most popular programming languages today.

Advantages:

1. Rust provides excellent memory safety, which means that common memory errors such as buffer overflows and pointer errors are virtually impossible. This makes Rust an ideal language for safety-critical applications.

2. Rust is a high-performance language. This means that programs written in Rust run much faster than programs written in other languages. This makes it ideal for applications that require high performance.

3. Rust is a general purpose language, which means it can be used for almost anything. This makes it ideal for projects of all sizes, from small personal projects to large corporate projects.

4. Rust is a modern programming language, which means it is designed to be easy to learn and use. This makes it ideal for beginners and experienced programmers alike.

Disadvantages:

1. Rust is a relatively new programming language, which means that there is a learning curve for programmers. This can be a disadvantage for those who are used to older languages.

2. Rust is a general-purpose programming language, which means that it is not specially designed for any particular purpose.
This can be a disadvantage for those who are looking for a language specifically designed for a particular purpose.

3. Rust is a high-level programming language, which means that programs written in Rust may be more difficult to debug than programs written in low-level languages. This can be a disadvantage for those looking for a programming language that is easy
to debug.
Click to expand...
 
kpedersen said:
This one?

Still not seeing what part you quoted. Besides, there are some incorrect facts in your above quote. I would be surprised if the Rust book would have made those mistakes.

You sure you didn't just plug it into ChatGPT?
Click to expand...
Don't be surprised nobody is perfect, I don't know if there are mistakes or not in that publication, however publication on the internet this tituled in the image of the book Rust Programming Language, and as a surfer to open link I made to take the publication by putting it here, and I immediately closed the web page.
 
MG said:
Not following lots of debate about this but I personally have the suspicion that the "memory-unsafe" problem actually means "not sandboxed", which is commercially motivated. It's about control of computers by end-users.
Click to expand...
Rust isn't sandboxed either, so I doubt that's what they're referring to. There's a clear preference from both the programmer and the commercial sides for the relative ease of writing sound code without having to worry about accidentally pushing your pointers off the valid memory behind them and into ACE territory.

Plenty commercial, government, and programmer pet projects aren't in Rust and won't be either. And that's fine, everyone has their preferences. And even I, devout Rust lover, know that Rust isn't always the answer. Some folks turn it into the next religious war, I just enjoy my fearlessly concurrent popcorn and watch
 
Riven Skaye said:
Rust isn't sandboxed either, so I doubt that's what they're referring to. There's a clear preference from both the programmer and the commercial sides for the relative ease of writing sound code without having to worry about accidentally pushing your pointers off the valid memory behind them and into ACE territory.

Plenty commercial, government, and programmer pet projects aren't in Rust and won't be either. And that's fine, everyone has their preferences. And even I, devout Rust lover, know that Rust isn't always the answer. Some folks turn it into the next religious war, I just enjoy my fearlessly concurrent popcorn and watch
Click to expand...
Don't overindulge in popcorn of corn, it's fattening, and overweight is bad for your health, it attracts diseases.
 
You must log in or register to reply here.
Back
Top