Rust-Written Redox OS Now Supports GDB Debugging

[lyamc]

Why does every single Rust-related article have to include the phrase "Rust-written" [sic]. Is being written in Rust a feature in itself now?

The same applies to project blurbs on GitHub too. You surely know your project is irrelevant, when the only way to attract interest is by using language hype.

When Rust was first being hyped, people said that it will never replace C and it's a neat little pet project.

Then people create things that normally would be written in C, and now you think it's some sort of conspiracy. Do you buy new computers to attract interest to yourself or because it is improved?

[kpedersen]

Probably because Rust eliminates the biggest weakness of C/C++, manual memory management along with all of the associated security issues.

This is a big deal, Microsoft did an internal survey and figured out that 70% of their security issues are due to this weakness in C/C++

I am sure Microsoft will find a way to write Rust in a completely unsafe way too. They are the biggest offender :/

My interest in Rust is mainly because companies like Microsoft are consistently unable to write C++ in a remotely safe manner. C++ does provide automatic memory management but Microsoft are sticking with an ancient (pre C++98 even) dialect, seemingly avoiding all RAII. The MSSQL APIs are a good example of this.

So at least Rust might force them to do a good job even when using a "big boy" systems language XD.

[jrch2k8]

r


Probably because Rust eliminates the biggest weakness of C/C++, manual memory management along with all of the associated security issues.

This is a big deal, Microsoft did an internal survey and figured out that 70% of their security issues are due to this weakness in C/C++

A kernel written in Rust will have much fewer security issues without sacrificing performance (Rust actually comes ahead of typical C code when it comes to performance if you compare apples with apples)

1.) Allegedly, more intense security audits are needed here, i get the design in theory is nice and seems valid but in practice need more testing (Remember Intel saying hardware is safer because is not hackeable? good in theory turned out differently in practice)

2.) Weakness is not C/C++ but in the developer misusing functionality for several reasons and this have been true since since C started gaining ground to Cobol and Pascal decades ago. Microsoft is not really a good example of good coding practices in any language to be honest(anyone remember the horrors of Visual J??).

3.) Rust can be as fast as mediocre C/C++ code safely but so far i haven't seen Rust beating proper High Performance C++ code without having to throw all security through the window(please don't start linking random C++/Rust code benchmarks from github since 99% of those are not even in the HPC category) and honestly most benchmarks around i found claiming HPC speed comparison are from developers that seriously have never seen HPC code in their life.

Now, all that said i think Rust is nice to help those developers that don't understand how memory, Numa, Paging, ALU, Cache, etc. works properly(hardware level) and keep bastardizing C/C++ to move on to something close in performance with more safety protections but C/C++ will stay king in HPC for a long while still.

For any developer out there if you think std::vector is fast, the compiler should align code LOL not me? AVX should be a GPU thing, What is page? the OS should handle it!!! please use Rust/GO/etc. because C/C++ is way too low level for you.

[wswartzendruber]

This thread has people commenting who don't understand Rust, but are content to promote C and C++.

The reason we like this language is simple. The compiler enforces a simple set of rules that eliminate memory access bugs. We can disable these rules for C interop, but we are still explicitly acknowledging that we are doing so. In other words, it is theoretically impossible in Rust to have an inadvertent memory access error.

And those of you bringing up the skill of the developer in question may yourselves be excellent C++ developers, but how about the people writing C++ on a deadline and minimal budget? Are they as good as you? See, I don't care about how good you are, it's how good they are because their shitty C++ code is all over my stuff.

[mdedetrich]

The single biggest determining factor of bugginess is the expertise and level of care exercised by the authors. No kind of language or magical thinking can solve logic bugs.

If your definition of "magical thinking" is maths then sure.

Maybe you should educate yourself instead of doing idiotic smartass replies.

BTW no one is saying that Rust solves 100% of bugs, thats obviously impossible. Rust however does make a certain set of bugs impossible (which also happen to be the most common bugs and security issues seen in C/C++).

And those of you bringing up the skill of the developer in question may yourselves be excellent C++ developers, but how about the people writing C++ on a deadline and minimal budget? Are they as good as you? See, I don't care about how good you are, it's how good they are because their shitty C++ code is all over my stuff.

This line of thinking about "just get better in C/C++" makes no sense because even experts do mistakes in those languages.

[wswartzendruber]

How many people are going to spam this thread with yet another boring paraphrasing of Rust's #1 selling point...?

That depends on how many more people challenge the merit of RedoxOS.

[mdedetrich]

3.) Rust can be as fast as mediocre C/C++ code safely but so far i haven't seen Rust beating proper High Performance C++ code without having to throw all security through the window(please don't start linking random C++/Rust code benchmarks from github since 99% of those are not even in the HPC category) and honestly most benchmarks around i found claiming HPC speed comparison are from developers that seriously have never seen HPC code in their life.

This is wrong. A lot of unix/Posix tools have been rewritten in Rust (these tools have been hand optimized for decades) and the Rust version is faster (albeit marginally) or equal wrt performance in a like for like comparison (i.e. Rust has bounds checking enabled by default so you often have to disable such checks when doing comparisons with C/C++).

Rust guarantees a lot of things that C/C++ can't and so the compiler produces better code because it has more knowledge. When LLVM fixes their strict aliasing checking Rust will become even faster.

Also I don't know what your point about HPC is, both Rust and C/C++ have LLVM as a backend and LLVM does the heavy optimizing for HPC code (I assume you are talking about SSE/AVX).

In other words there isn't any difference between Rust and C/C++ here.

Deliberate misreading of my statements doesn't prove anything, except how little substance there is to your argument.

You would have a point if your statements made any sense.

Anyways as I said, learn some Rust and then come back when you educate yourself

[jrch2k8]

BTW no one is saying that Rust solves 100% of bugs, thats obviously impossible. Rust however does make a certain set of bugs impossible (which also happen to be the most common bugs and security issues seen in C/C++).
This line of thinking about "just get better in C/C++" makes no sense because even experts do mistakes in those languages.

Well, i think this is an overstatement "most common bugs and security issues", sure a memory leak because a dev forgot a free somewhere maybe an security issue but maybe is not exploitable. In my experience most security vulnerabilities come from faulty logic and lack of understanding on the bases of the algorithm/hardware you are using not leaking memory but leaks open a whole other can of worms.

Also note modern C++ language and tooling make lots and lots easier (maybe close to Rust easy) to have safe allocations on HEAP, so the main issue here is not that C++ is impossible to write safely but that it have a problem of too much history, so your random "I do c+++++" developer is taking code and examples from a bunch of different versions with random degrees of safety, compile, release.

If you learn C++ properly and educate yourself on the proper tooling(at least ASAN for god sake) the "just get better in C/C++" will apply and the code should be at least as safe as Rust.

I do agree with you that most current mid level C++ devs should go to Go/Rust/etc. since C/C++ require hardware knowledge to be used to its potential and most developers you found around throwing C++ code obviously have no freaking idea on how hardware works and in C++ that is a recipe for disaster.

[mdedetrich]

Well, i think this is an overstatement "most common bugs and security issues", sure a memory leak because a dev forgot a free somewhere maybe an security issue but maybe is not exploitable. In my experience most security vulnerabilities come from faulty logic and lack of understanding on the bases of the algorithm/hardware you are using not leaking memory but leaks open a whole other can of worms.

Except that these memory related issues (bounds checking, use after free, double free etc etc) are the most common cause of security exploits. This is what Microsoft study concluded, 70% of security exploits are directly due to these things which are not possible in Rust.

I mean you can even research these security issues yourself, vast majority of them are preventable in Rust.

Also note modern C++ language and tooling make lots and lots easier (maybe close to Rust easy) to have safe allocations on HEAP, so the main issue here is not that C++ is impossible to write safely but that it have a problem of too much history, so your random "I do c+++++" developer is taking code and examples from a bunch of different versions with random degrees of safety, compile, release.

It is true that C++ in the latest standard has added some features that Rust has, but they pale in comparison when it comes to capability. The biggest point is that in Rust, the borrow checker is on by default and in order to bypass it you have to do `unsafe` which means its easy to verify what code could potentially be unsafe (and this also applies to tools that read Rust code).

If you learn C++ properly and educate yourself on the proper tooling(at least ASAN for god sake) the "just get better in C/C++" will apply and the code should be at least as safe as Rust.

I do agree with you that most current mid level C++ devs should go to Go/Rust/etc. since C/C++ require hardware knowledge to be used to its potential and most developers you found around throwing C++ code obviously have no freaking idea on how hardware works and in C++ that is a recipe for disaster.

The point is that Rust basically enforces good designed C++/C code at compile time, so as a learning tool Rust is infinitely better. C/C++ let you do whatever you want and hence shoot yourselves so many ways. In Rust those programs just don';t compile, so you immediately know something is wrong.

Source: "trust me, bro".



Source: "trust me, bro".



Also phrased as:

Or you could just go to https://godbolt.org/ and view the difference in assembler between C/C++/Rust. But I assume you haven't done that because you are a keyboard warrior that actually doesn't know what they are talking about.

[jrch2k8]

This is wrong. A lot of unix/Posix tools have been rewritten in Rust (these tools have been hand optimized for decades) and the Rust version is faster (albeit marginally) or equal wrt performance in a like for like comparison (i.e. Rust has bounds checking enabled by default so you often have to disable such checks when doing comparisons with C/C++).

Rust guarantees a lot of things that C/C++ can't and so the compiler produces better code because it has more knowledge. When LLVM fixes their strict aliasing checking Rust will become even faster.

Also I don't know what your point about HPC is, both Rust and C/C++ have LLVM as a backend and LLVM does the heavy optimizing for HPC code (I assume you are talking about SSE/AVX).

In other words there isn't any difference between Rust and C/C++ here.



You would have a point if your statements made any sense.

Anyways as I said, learn some Rust and then come back when you educate yourself

1.) Posix/Gnu tools were never designed to be high performance but highly maintainable / multi platform and both cannot be achieved together, so this qualify as not HPC code. in the same sense std(C/C++) libraries are not HPC ready but highly maintainable / multi platform but can be expanded for HPC use which is why most C++ library standard are so template intense.

2.) C/C++ is lower level, so i'm sure Rust can do automatically many things that in C/C++ require developers action but are not impossible to replicate, also LLVM/CLANG are very far in reality from you claims(at least compared to ICC/GCC) but for what Rust need it produce good ASM for most cases.

3.) SSE/AVX is one of the many many HPC tools and no compiler in existence does "heavy optimizing for HPC code" because that would be holy grail of computing

As stated you made a good decision learning Rust instead of C/C++