Experimenting Is Underway For Rust Code Within Mesa

[ssokolow]

GNU Guix actually does build everything from source! Or it does very nearly... It's pretty rad!

https://guix.gnu.org/en/blog/2020/gu...ap-seed-to-25/

Ooh! Nice!

...and here I thought I was being courteous with the DOS retro-hobby project I'm (very) slowly finding time to work on by going the extra mile to make the tools in a standard Open Watcom C/C++ 1.9 install the only mandatory dependencies for a from-source binary build and Doxygen as the only dependency for a documentation build and making it buildable on Linux, Win32, or DPMI installs of the toolchain.

(e.g. If I need anything beyond what Open Watcom Make 1.9 is expressive enough to do, I'll write a helper in C and let wmake build that first.)

Open Watcom is self-hosting, but supports all targets from a single build and doesn't yet target 64-bit platforms, so an easy bootstrap through the officially supported path is GCC or MSVC → 64-bit Open Watcom 2.0 and then use it to build whatever 32-bit Open Watcom release you want for whatever host you want. (OW 1.9 is the last version from before a lack of new releases caused a friendly fork, so that's why I ensure I maintain support for it.)

[jbranso]

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

That is a weird name for a debugger.

[jbranso]

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.

Sorry for getting so long to respond to you...

GNU Guix actually does build everything from source! Or it does very nearly... It's pretty rad!

https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/

And you are correct! mrustc is how they bootstrap rust!

[mmstick]

Mozilla is pitching this CSS case for years already, I was citing this case to others when I was a Rust fanboy, did Rust allow them something else since then that they couldn't do in C++?

The former Mozilla engineers pioneered a lot of areas. Most importantly being the development of Rust itself. For Firefox specifically, besides CSS parsing, we got WebRender out of it. We also got the creation of a cross-platform graphics API supporting the WebGPU API (wgpu). Which is used by Firefox, and more recently will be used by Deno. Speaking of Deno, it should also be known that the most popular WebAssembly runtimes are written in Rust, and Deno itself is created by the same person who create Node.JS. Deno is the next generation of a much better TypeScript-based platform running on top of a Deno VM written in Rust.

But Mozilla's just a small part of the overall Rust ecosystem. Not sure why people are bringing their name up now that the majority of development is done by other organizations. Much of the big achievements happening right now are in a wide range of areas from a wide number of businesses. Take GNOME for instance, where they've chosen Rust to be the future of their platform, with many of their applications now being written in Rust instead of C. Or how we now have some former Trolltech employees that were also KDE contributors that are responsible for giving us QML and Qt, which are now working on a next generation GUI toolkit in Rust called SixtyFPS.

[cl333r]

BTW I ended up having a look brief look at this code and I this is what I would class as trivial, more precisely you are using threads for concurrency on file-systems operations

Actually a lot of it is about loading stuff in parallel and allow the GUI to wait at startup until the necessary data is loaded, plus for other stuff.

[cl333r]

like servo which has, for example, multi core CSS rendering https://github.com/servo/servo.

Mozilla is pitching this CSS case for years already, I was citing this case to others when I was a Rust fanboy, did Rust allow them something else since then that they couldn't do in C++?

[mdedetrich]

Flawed logic, you can't prove something (bugs) doesn't exist, you can only prove it exists.
If you feel like searching for concurrency bugs you're welcome: https://github.com/f35f22fan/Cornus

BTW I ended up having a look brief look at this code and I this is what I would class as trivial, more precisely you are using threads for concurrency on file-systems operations which is what i would classify as low hanging fruit.

You have a point that its subjective defining what is trivial and what is not, but as a contrast have a look at something like servo which has, for example, multi core CSS rendering https://github.com/servo/servo.

[arQon]

i.e. people were claiming ridiculously that the borrow checker runs at runtime, there is a world of difference between that and making a surface level argument

Yeah, but you're missing the upside here: running into a comment like that early in their post means you can just skip ahead to the next one, AND ignore any other posts they've made too. It helps a lot when you haven't read the site for a couple of weeks and are trying to catch up on the backlog.

[ssokolow]

there's an implementation of liftime profile for c++, it also comes eventually. it's not enough for rust to get c++ features in distant future, because then c++ will get rust features too. in future you'll have to be better than future c++

1. The Rust approach is "Let C++ handle those use-cases until we're ready. Better to do it right once we're comfortable with the design than to rush a bad design now and have to support that baggage forever". (Or, as Shigeru Miyamoto said about... Mario 64, I think it was: "A late game is only late until it ships. A bad game is bad until the end of time.")
2. There's a limit to how much of Rust's secret sauce C++ can acquire without breaking compatibility with existing C++ code or fracturing it into "legacy C++" and "Rust but with much uglier syntax". It'll be very difficult for Rust to not be better than future C++ in the ways that matter.

[oleid]

there's an implementation of liftime profile for c++,

Yeah, you can already use that in clang and it is a joke.