Experimenting Is Underway For Rust Code Within Mesa

[linner]

Lets just hope they do careful and objective testing. There are a lot of Rust apologists due to excitement for the platform and rose colored glasses. You need to test both the "normal" approach and the Rust alternative side-by-side. This is very time consuming and most projects don't do it. They should also consider and test on non-ideal platforms like older hardware where things like rustc can have issues.

The main reason I'm an advocate for this approach is because in my own testing I haven't found Rust to be all that great. It used more memory, ran slower, caused maintenance issues with people not familiar with Rust, still contains bugs and security issues, and the compiler (which is written in Rust) is a resource hog. That's just my experience with it.

[oleid]

Concurrency is not rocket science, it's relatively easy 90-99% of the time, you just have to be careful and understand what you're doing.

Yes, if you design stuff from the ground up and implement it correctly, you're usually fine. Refactoring existing multithreaded code you didn't write, however, often is troublesome. Even worse if multithreaded code is changed by on-off free-time contributors, which don't have all the nasty details in mind.

[Mordrag]

I agree, we shouldn't bring legit issues of real devs using Rust because it spoils your fantasies, we should only stick to facts - the ones that praise Rust of course, because that's what objective non-fanboys do.


Right, I did multithreading with C++/pthreads and I didn't shoot myself in the foot 1000 times, I wonder why?

Well you will find individuals who support youre opinion for literally every argument you take. If you find a decent amount of benchmarks which suggest that Rust's mutlithreading is awful compared to gos ( you were talking about 10x to 100x times faster right ???), then i am sold. Aside from that gos mutlithreading implementation greatly differs from Rusts, its far higher up in the abstraction. And while it has all that nice stuff with channels you can still shoot youreself in the foot witch shared state. I like both languages, but what is even youre point here ? Go is in no way a target for such low level code. You are arguing on a whole other level on abstraction which does not relate to the given use case.

[mdedetrich]

Yes, if you design stuff from the ground up and implement it correctly, you're usually fine. Refactoring existing multithreaded code you didn't write, however, often is troublesome. Even worse if multithreaded code is changed by on-off free-time contributors, which don't have all the nasty details in mind.

And to be frank, the majority of existing C code out there was written with single core in mind (apart from algorithms/encoders/decoders that can be trivially parallelized with divide and conquer and similar strategies).

This puts you in the position where you kind if you want to add non trivial multithreading to an existing C codebase that wasn't designed for it, you usually end up rewriting a huge portion (which often means creating regressions/bugs) and because of this in most cases the C codebases stay largely single threaded with only low hanging fruit parallelism implemented.

[ssokolow]

No flame-war, people have an issue with this name and with it's debugger called Heil.

I don't find much of anything when I search 'ziglang "Heil"` on DuckDuckGo. Was that supposed to be a joke?

I've assumed it was pronounced as in "Zig-Zag" and I've seen people making Take off every Zig jokes much more than "Zig Heil" jokes.

[ssokolow]

Thanks for your thoughts! I guess it's is fairly true that Rust currently brings more to the table. Just to share my thoughts, I'm a GNU Guix fan boy, which is the GNU distribution that tries very hard to build everything from source. From what I gather Rust can be problematic for the Guix people to build from source, because how do you build rust? You compile it with rust of course! This can make porting complex Rust applications designed for x86 to Arm rather difficult from what I gather.

How does Guix build GCC from source without already having a copy of GCC? ...or is this just another case of treating GCC specially?

I'm having trouble searching it up, but I ran across a blog post back around the beginning of this year (when there was the hullabaloo about the Python cryptography library adding a Rust dependency) which made that point very well.

A lot of platforms have really learned to take it for granted that GCC is the only compiler which has earned the privilege of being self-hosted and that they are somehow entitled to an upstream that's never heard of them remaining compatible with their "just happens to work" compilation solution, no matter how esoteric it is.

For verifying trustworthiness, mrustc is a compiler written in C++ which can build a relatively recent rustc version from source, which you can then use to re-bootstrap it to prove that the results are identical.

Once that's done once to verify correctness, the recommended way to reach new platforms is to implement support for targeting the relevant ISA in LLVM, write a platform definition, and then cross-compile rustc to it.

[ssokolow]

Flawed logic, you can't prove something (bugs) doesn't exist, you can only prove it exists.

A type system can be used to prove that a class of bugs doesn't exist.

As Edsger Dijkstra said, "Program testing can be used to show the presence of bugs, but never to show their absence", but he was using it to argue in favour of going further in the direction of formally proving programs.

Rust disallowing data races at compile time is an example a step in that direction, as opposed to Go's runtime data race detector which is more like LLVM's sanitizers.

[xeekei]

Haha says the Rust fanboy who didn't know that RefCell doesn't do reference counting.


Indeed, Rust 1.0 has been around for 6 years already and here's the full list of AAA games that dumped C++ in favor of Rust thanks to its awesome concurrency:

These days, AAA games often take more than 6 years to develop. Especially including pre- and post-production.

[pal666]

It might very well be, Rust was really designed as a C++ alternative

just as go was designed as a c++ alternative. but designers weren't c++ programmers and didn't know what c++ programmers need. in reality there's only one c++ alternative: next c++ version

[pal666]

Go has much worse runtime performance than C/C++

which puts it in same league with rust