Experimenting Is Underway For Rust Code Within Mesa

[cl333r]

It takes like 20 years for languages to displace what is already existing, especially if you take into account massive game engines that have been written in C++. Also C++, unlike C, has a frequently breaking ABI which makes it hard to incrementally use Rust in such projects (which is why you see Rust disrupting C more than C++).

The biggest issue with game engines is a lot of them is WYSIWYG and a huge amount of that tooling is built ontop of their C++ engines, its not just pure code and so recreating this with Rust is a huge effort.

No, it takes 500 years for languages to displace what is already existing and another 120 years for devs to learn about it.
Here's the delight of dealing with Rust of the dev who wrote ESbuild [1]:

I actually originally wrote esbuild in Rust and Go, and Go was the clear winner.
The parser written in Go was both faster to compile and faster to execute than the parser in Rust. The Go version compiled something like 100x faster than Rust and ran at something around 10% faster (I forget the exact numbers, sorry). Based on a profile, it looked like the Go version was faster because GC happened on another thread while Rust had to run destructors on the same thread.

The Rust version also had other problems. Many places in my code had switch statements that branched over all AST nodes and in Rust that compiles to code which uses stack space proportional to the total stack space used by all branches instead of just the maximum stack space used by any one branch: https://github.com/rust-lang/rust/issues/34283. I believe the issue still isn't fixed. That meant that the Rust version quickly overflowed the stack if you had many nested JavaScript syntax constructs, which was easy to hit in large JavaScript files. There were also random other issues such as Rust's floating-point number parser not actually working in all cases: https://github.com/rust-lang/rust/issues/31407. I also had to spend a lot of time getting multi-threading to work in Rust with all of the lifetime stuff. Go had none of these issues.

The Rust version probably could be made to work at an equivalent speed with enough effort. But at a high-level, Go was much more enjoyable to work with. This is a side project and it has to be fun for me to work on it. The Rust version was actively un-fun for me, both because of all of the workarounds that got in the way and because of the extremely slow compile times. Obviously you can tell from the nature of this project that I value fast build times

As one can see Rust multi-threading is better than Go.

[1]

https://news.ycombinator.com/item?id=22336284

[kpedersen]

Do those have 3D drivers?

You do have a good point. Though I was mainly referring to Rust on i386 on OpenBSD which seems to consistently cause problems. Either the build takes too much RAM or something else.

"For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space."

https://news.ycombinator.com/item?id=15843711

(I did have a better source for this quote but I can't find it now).

[jbranso]

Rust is much more mature and has much wider usage than Zig.

Ontop of this, Zig doesn't have as many guarantees that Rust's borrow checker can prove and picking another another language to use is a very expensive decision and taking this into account Rust brings the most value on the table.

Unfortunately making a new programming language successful is brutal, you need to hit a niche that hasn't been served and you need to hit it really hard. Rust has managed to do this, its core design tenets is to have the same low level zero cost abstraction as C/C++ but use a type system to prove as much as possible about memory safety at compile time. Languages like D or Zig which claim to be a better C++ or better C respectively just don't bring enough to the table to cut it for most cases.

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.

[jbranso]

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

What name? and Zig has a debugger?

[mdedetrich]

Here's the delight of dealing with Rust of the dev who wrote ESbuild [1]:

As one can see Rust multi-threading is better than Go.

Go has much worse runtime performance than C/C++ and it has a GC which means it isn't the right tool for a lot of cases (including the one you brought up with games). Haskell/Scala/Erlang is also much easier to do multi-threading than Rust and Go as well, but since they have GC's its not suitable for mesa or for games.

And please stop linking random articles from the internet, it just shows you are trying to find random stuff to prove your "point". Go is easier at multithreading then Rust because Go is a simpler language, Rust multithreading is difficult only because Rust itself is not trivial to learn due to its borrow checker (which is actually what the guy said in the article you mentioned, what was difficult to learn was the borrow checker itself not specifically concurrency). What makes Rust multithreading much better than C/C++ is that in almost all cases the Rust compiler will tell you when you have a concurrency bug.

So if you want zero cost abstraction with no runtime and not shoot yourself in the foot 1000 times when doing concurrency, your only real choice is Rust. If you don't care about having a runtime or GC, then there are plenty of languages that have abstractions that make multi-threading easier, that includes Go/Scala/Haskell/Erlang etc etc

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.

Yes, Rust is indeed bootstrapped (which means to compile Rust you need Rust). This is generally a good thing for languages because bootstrapping is often the first time a new language has a non trivial implementation that they can use to test the language (in this case the language's compiler)

I am not familiar with GNU Guix but I imagine you need a gcc binary to compile your C programs (including gcc as well) right? In this case its not that different to Rust.

[cl333r]

And please stop linking random articles from the internet, it just shows you are trying to find random stuff to prove your "point". Go is easier at multithreading then Rust because Go is a simpler language, Rust multithreading is difficult only because Rust itself is not trivial to learn due to its borrow checker (which is actually what the guy said in the article you mentioned, what was difficult to learn was the borrow checker itself not specifically concurrency).

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.

What makes Rust multithreading much better than C/C++ is that in almost all cases the Rust compiler will tell you when you have a concurrency bug.

So if you want zero cost abstraction with no runtime and not shoot yourself in the foot 1000 times when doing concurrency, your only real choice is Rust.

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

[mdedetrich]

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

Probably because it was a trivial example or maybe you had a bug and didn't actually realize (some concurrency bugs can be incredibly hard to track down). Mozilla engineers tried to make Firefox multithreaded and it was close to impossible without introducing regressions/bugs/security issues and thats actually why they created Rust.

[cl333r]

Probably because it was a trivial example

"Trivial" in this case is meaningless because what's the objective boundary between trivial and non-trivial in this case that at least 99% would agree with?
And no, it was average: it was/is creation of threads and synchronization and broadcasting when needed.

or maybe you had a bug and didn't actually realize (some concurrency bugs can be incredibly hard to track down).

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

[pmorph]

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

But what is your point?
That concurrency is generally not a problem in sw development, and that there is no need to try and do anything about it?

[cl333r]

But what is your point?
That concurrency is generally not a problem in sw development, and that there is no need to try and do anything about it?

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. In rare cases it's indeed hard and you'd need Rust for it.
IMHO one hard example is when you have to turn existing single threaded code into multi-threaded when many structures and dependencies are involved, that's the type of task I hate the most because you'll change structures and whatnot and you'll get tons of errors and it won't compile for a long time.