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

Riven Skaye said:
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.
Click to expand...
Well, I would agree in every use case scenario, except Ryujinx, because the Horizon OS is partly rewritten in C# already so, C# was a good choice if you do not want to reinvent the wheel.
 
LillieNB said:
Well, I would agree in every use case scenario, except Ryujinx, because the Horizon OS is partly rewritten in C# already so, C# was a good choice if you do not want to reinvent the wheel.
Click to expand...
C++ and C# come from back decades ago and are obsolete in the face of today's high-level performance demands, and since we are in other modern times, we must step into the present, and Rust is the hope for the high-level performance that today demands.
 
teo said:
C++ and C# come from back decades ago and are obsolete in the face of today's high-level performance demands, and since we are in other modern times, we must step into the present, and Rust is the hope for the high-level performance that today demands.
Click to expand...
This source claims something different, though.
It is from 2025, and seems pretty modern to me.
This source states that C++ has slightly better runtime performance than rust.
 
Unreal Engine, Unity, and Godot is written in C++.
Vulkan is written in C.
C is used in embedded programming.
Game hardware emulators are mainly written in C++
Wine is written in C.

I do not really think either of them will be ditching their large code base in favor of some hype with inferior runtime performance.
 
Performance of C/C++ executables. CPUs now have all kinds of speculative execution, lots of optimizations. Modern compilers have a lot of switches for optimization (space vs speed, loop unrolling, etc) and linkers do a lot to rearrange code. C/C++ compilers/linkers have been moving that way for a long time (I remember early C++ with templates from STL would expand the code every time something was included, then linkers got smarter).
So could a newer language maybe make it easier to do these kinds of optimizations? Sure.
Can a newer language maybe make it easier to write things "safely"? Sure, but the work to do that has to be done somewhere (compiler or linker).
Heck everyone that has done large projects in C/C++ learned there is a difference between running something compiled with -O0 and -O2.

If a new language actually solves problems, that's good. But there needs to be enough mileage to make old guys feel comfortable.
 
mer said:
If a new language actually solves problems, that's good. But there needs to be enough mileage to make old guys feel comfortable.
Click to expand...
If rust adds an option to disable memory-safety checks during runtime, I am all in, and willing to learn the language.
 
Actually...
It would be really interesting to take Ryujinx as reference, and write an entirely new nintendo switch emulator in rust, and compare it with yuzu (C++).
But it would be my second project, after Ryujinx gets all my love it deserves...
Rust has also a Vulkan wrapper, too ... 😂
 
astyle said:
Well, GNU's coreutils (basic userland utils like ls, dmesg, and others) getting re-written in Rust, and actually accepted into Linux kernel, that probably counts for something. And there's apparently less test case failures, too: https://www.phoronix.com/news/uutils-Coreutils-0.0.30
Click to expand...
And that is the way I think it should be. Start with applications, even if they are small but essential (although I think a lot of shells have ls and a few others actually built in), prove them, give them a long term chance.
 
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...
Removing hardware-function with the software that runs on it is sandboxing. Limiting the user for various theoretical reasons. A Rust compiler is blocked from accessing particular memory while that capablity exists and should be accessible because it's how the hardware is designed.
Nothing religious about it.
People claiming that a particular compiler is more safe actually claim that the computer design is inconsistent and the compiler is implementing a fix for it which is a artificial boundary. Compilers should be derived from, not designed for. They have no business with programming methodology.

How to spot the flaw: what can be wrong with a program that takes care of its own memory management anyway, regardless of the used compiler? If you can set any bit, that's a natural abiility.
 
astyle said:
Well, GNU's coreutils (basic userland utils like ls, dmesg, and others) getting re-written in Rust, and actually accepted into Linux kernel, that probably counts for something. And there's apparently less test case failures, too: https://www.phoronix.com/news/uutils-Coreutils-0.0.30
Click to expand...
uutils won't replace GNU utils on any mainstream distro for multiple reasons:
1. MIT license.
2. GNU utils are battle tested on multiple architectures & other operating systems.
3. The code is mostly a hobbyist project for people learning Rust. Passing the GNU testsuite is not enough.

Not even sudo-rs is default, though sudo-rs has cleaned up their act:
www.memorysafety.org

Sudo-rs dependencies: when less is better

The sudo utility represents a critical privilege boundary, so it should be memory safe. We rewrote it in Rust with partners at Tweede golf and Ferrous Systems. Ruben Nijveld from the Tweede golf team offers his perspective here on one of the greatest challenges we faced when developing software...
www.memorysafety.org www.memorysafety.org
 
rbranco said:
uutils won't replace GNU utils on any mainstream distro for multiple reasons:
1. MIT license.
2. GNU utils are battle tested on multiple architectures & other operating systems.
3. The code is mostly a hobbyist project for people learning Rust. Passing the GNU testsuite is not enough.

Not even sudo-rs is default, though sudo-rs has cleaned up their act:
www.memorysafety.org

Sudo-rs dependencies: when less is better

The sudo utility represents a critical privilege boundary, so it should be memory safe. We rewrote it in Rust with partners at Tweede golf and Ferrous Systems. Ruben Nijveld from the Tweede golf team offers his perspective here on one of the greatest challenges we faced when developing software...
www.memorysafety.org www.memorysafety.org
Click to expand...
hmmm... have you heard of sysutils/rust-coreutils ?
 
mer said:
Performance of C/C++ executables. CPUs now have all kinds of speculative execution, lots of optimizations. Modern compilers have a lot of switches for optimization (space vs speed, loop unrolling, etc) and linkers do a lot to rearrange code. C/C++ compilers/linkers have been moving that way for a long time (I remember early C++ with templates from STL would expand the code every time something was included, then linkers got smarter).
So could a newer language maybe make it easier to do these kinds of optimizations? Sure.
Click to expand...

The compiler's compile-time optimizations are pretty much the same for all statically typed Algol like languages. Don't expect any substantial differences.

C++ will be faster than Rust if you like to live dangerously. I listed a couple of areas.
 
LillieNB said:
Unreal Engine, Unity, and Godot is written in C++.
Vulkan is written in C.
C is used in embedded programming.
Game hardware emulators are mainly written in C++
Wine is written in C.

I do not really think either of them will be ditching their large code base in favor of some hype with inferior runtime performance.
Click to expand...
How relevant is gaming performance to the overall computer industry?
 
ralphbsz said:
How relevant is gaming performance to the overall computer industry?
Click to expand...
If sales of gaming hardware, esp. high-performance stuff are anything to go by, gaming performance can be pretty relevant. Besides, even gaming hardware can be put to work for non-gaming purposes. How about the military research project that Al Gore paid for 50-plus years ago? it's powering quite a few online games. Gaming performance does demand a ton of bandwidth on the Internet, so ISPs have a ready-made excuse to keep upgrading their infrastructure and charged customers more. Those GPU's running at 600 FPS at 8k resolution - that's a LOT of data to move for an online game... not to mention a secondary market for data management services.

I know I sound like a damn marketer, and there's probably bettet ways to frame that... 😅
 
cracauer@ said:
Unity the engine might itself be written in C++. But it pretty much only supports games written in C#.
Click to expand...
C# in this case acts as a layer which under the hood still translates to C++ commands.
You can of course go the adventurous way and get to the bare metal, and use C++, but it will not be so easy.
I took back then at my university a Unity course, and the teacher told me something among the lines, I described above.
 
cracauer@ said:
Unity the engine might itself be written in C++. But it pretty much only supports games written in C#.
Click to expand...
It uses .NET as the scripting layer (in place of Python/Lua/etc).

In theory you could use C++.NET (cl /clr:safe) to write those "scripts".

rbranco said:
Not even sudo-rs is default, though sudo-rs has cleaned up their act:
https://www.memorysafety.org/blog/reducing-dependencies-in-sudo/
Click to expand...
That's a really good example of the Rust community actually acknowledging the dependency-first approach is not good and trying to solve things (usually their approach is trying to confuse the argument by explaining that the cargo lock file lists unneeded dependencies and is not a reliable way to evaluate their sloppy work).
 
You must log in or register to reply here.
Back
Top