Should GNOME Begin Replacing More C Code With Rust?

[mmstick]

In a certain way it's already being done through WebAssembly which is experimentally supported by Rust.
https://hacks.mozilla.org/2016/10/we...owser-preview/

I don't see WebAssembly replacing Javascript, but merely being an extension to it.

[mmstick]

Too early. Rust both the language and very important libraries providing basic functionality are still undergoing too much change.
There are still important bugs to fix like this one: https://github.com/rust-lang/rfcs/issues/811

There hasn't been much change since the 1.0 release, and that was more than a year ago. The only changes since then have been either invisible to the developer (MIR), or new additions to the language for added convenience (? operator is more convenient than try macro). The issue report you linked doesn't hinder anyone from writing anything in Rust today, and even when the issue is resolved via MIR, no existing code will be broken. Fixing the issue would simply make writing some portions of Rust more convenient than it is right now. It is trivial to avoid the borrowing issue mentioned.

[GrayShade]

In a certain way it's already being done through WebAssembly which is experimentally supported by Rust.
https://hacks.mozilla.org/2016/10/we...owser-preview/

Well, I meant replacing the usage of JavaScript in GNOME. Mutter runs JavaScript on the compositor thread leading to issues like this: https://bugzilla.gnome.org/show_bug.cgi?id=745032 . I've also had a lot of trouble with extensions that crash, as they take down the entire session, which hardly seems reasonable.

[Delgarde]

I would rather they replaced JavaScript with Rust.

That would be stupid. The use of Javascript in Gnome is mostly in places where you want a scripting language - glue code, shell extensions, etc. Rust would be a terrible choice for that - a far more complex language that requires compiling to native binaries. Rust is an excellent choice for library code,, but completely unsuited to the role for which Gnome uses Javascript.

[Delgarde]

2. Many of the core GNOME contributors are already world class C developers, and the code they know best is the existing GNOME C code. It's not sexy, but maintaining production tested code is often a better investment of time than throwing aside thousands of hours of work for the joy of a clean start with the hottest tool.

Just because they're great C developers, doesn't mean they're happy to do all their coding in C - they do so merely because until relatively recently, that was the obvious choice for the work they were doing.

But pretty much anyone who's done much work in C can appreciate the advantages of Rust, because it's a language designed for C developers... people who need a powerful language for writing low-level code, but would prefer one them that helps protect them from their own mistakes (instead of handing them a loaded gun with a broken safety).

[Delgarde]

There are still important bugs to fix like this one: https://github.com/rust-lang/rfcs/issues/811

Why do you regard that as a important bug, indicating a lack of production-readiness? Bug reports starting with the phrase "it would be useful if..." aren't typically something I'd regard as being especially critical...

[GrayShade]

That would be stupid. The use of Javascript in Gnome is mostly in places where you want a scripting language - glue code, shell extensions, etc. Rust would be a terrible choice for that - a far more complex language that requires compiling to native binaries. Rust is an excellent choice for library code,, but completely unsuited to the role for which Gnome uses Javascript.

See my post from above. It's hard to defend the usage of JavaScript when it's in performance-critical paths and if it crashing brings down the compositor and user session. It's not the nice Chrome experience of "a tab has crashed, do you want to reload it?".

Yet I agree, it would be hard to move away from JavaScript without losing compatibility with the current extensions.

[Marc Driftmeyer]

Too early. Rust both the language and very important libraries providing basic functionality are still undergoing too much change.
There are still important bugs to fix like this one: https://github.com/rust-lang/rfcs/issues/811

They'd be better off using Swift 4.0 when Apple releases it under the LLVM Community than Rust.

[plonoma]

Why do you regard that as a important bug, indicating a lack of production-readiness? Bug reports starting with the phrase "it would be useful if..." aren't typically something I'd regard as being especially critical...

This would heavily impact code structure and the borrow checker.

[plonoma]

There hasn't been much change since the 1.0 release, and that was more than a year ago. The only changes since then have been either invisible to the developer (MIR), or new additions to the language for added convenience (? operator is more convenient than try macro). The issue report you linked doesn't hinder anyone from writing anything in Rust today, and even when the issue is resolved via MIR, no existing code will be broken. Fixing the issue would simply make writing some portions of Rust more convenient than it is right now. It is trivial to avoid the borrowing issue mentioned.

The language features being added would still quite heavily impact code structure.
Rust is still too immature as a language and software ecosystem to start writing frameworks in.