Should GNOME Begin Replacing More C Code With Rust?

[Jumbotron]

ABSOLUTELY ! Start a parallel track swapping out C code along the way and testing the hell out of it. Dole it out on a beta channel with VERY EXPLICIT wording that this is strictly for testing and should not be used for serious use until otherwise told. Then have an additional parallel track of official release where both exist for a period of 1 year and then close the C based GNOME down forever after that year. If folks want to continue to develop a C based GNOME then fork all you want. I could see the MATE and CINNAMON guys doing this for a while until they were convinced that the Rust based GNOME was stable enough.

[Brane215]

One must-have tool for Rust-based projects:

https://www.youtube.com/watch?v=Q8q3DZB_l6M

[liam]

I would be surprised if they did, but ecstatic at the same time. As it is, GNOME, or even any major GNOME component, scarcely makes a release that doesn't include memory leaks, OOB access, use after free... basically any pointer related errors, for a start. The even bigger win, imho, is the very rich type system which they can use to better capture behaviors without resorting to oo. If c had good, or any, generics support ebassi would've had less work to do with his scene graph.
Frankly, it's even practical because it has such a nice ffi (which is one of the things that they've said will get better next year since their c++ interop story isn't very good) it can be gradually introduced.
The syntax is pretty damn rough though (yes, functional languages, I get it) but still not as bad, imho, as GNOME C.

[liam]

Is it possible to call a functions from a Rust library from C? Because that's pretty much my only issue with this.

Yes. If also works with dynamic languages like ruby and Python (at least, but probably others). For some reason there being a surprising amount of buzz in the Ruby community with regards to rust. This post (https://m50d.github.io/2015/09/28/wh...kes-sense.html) acknowledges it but doesn't provide a satisfactory answer, imho.

[keivan]

Porting some already working code aside just because does not seem vise to me, considering limited resources and time. Isn't it possible to add new functionalities using the rust code and keep using the older code?

[ssokolow]

Porting some already working code aside just because does not seem vise to me, considering limited resources and time. Isn't it possible to add new functionalities using the rust code and keep using the older code?

Nothing technical prevents it, but new features tend to mean building on existing code and you get a much better return on investment if you put the boundaries between your C and Rust code at the abstraction boundaries, so you can get good, solid compile-time verification that they're being used properly. (eg. It's hard to leverage Rust's greatest strengths if half your Rust code is "unsafe" (manually audited code) blocks and your data is constantly zig-zagging in and out of the bits rustc can verify.)

[Delgarde]

Nothing technical prevents it, but new features tend to mean building on existing code and you get a much better return on investment if you put the boundaries between your C and Rust code at the abstraction boundaries, so you can get good, solid compile-time verification that they're being used properly. (eg. It's hard to leverage Rust's greatest strengths if half your Rust code is "unsafe" (manually audited code) blocks and your data is constantly zig-zagging in and out of the bits rustc can verify.)

Yep. Certainly, if you're doing completely new modules, it's simple enough to write those in Rust, and leave existing stuff in C. But most of the time, developers aren't adding completely new modules - they're modifying existing ones. So under the circumstances, it's more productive to take a more methodical approach, e.g to take a single C file, and re-implement the entire contents in Rust so that you've got a drop-in replacement for that file... preferably, you also have enough automated tests to prove that it really is a drop-in replacement.

[eigenlambda]

<i>Additionally, we release ourselves from the burden of maintaining core libraries for everything so we can focus on producing a great desktop and application development story</i>

In other words, this person doesn't want to be working on the GNOME core, but wants to be working on applications. Applications have been written in whatever language for some time, a decade ago, everyone was talking up C# and RhythmBox was written in C#, as was Tomboy Notes. This guy wants to write applications in Rust? The great thing about gobject is that you can use it in any language, because it's a carefully crafted object system for desktop use.

gobject is gobject. It is not Rust's object system. Porting it from C doesn't make sense.

But this guy doesn't want the burden of maintaining core libraries, which is fine, and he should keep his mouth shut about things he doesn't understand.

[mmstick]

Rust is not something you can pick up in 2 days. For some reason even the syntax is not C-like but some weird shit. Yes you can have more Rust code in Gnome or KDE or whatever but where are you going to get the programmers from ?
Maybe if Red Hat or some company will train their programmers to learn Rust and then those will write Rust code in Gnome then yes. I for one as C++ programmer see no reason so use Rust right now because it's of no real use to me in my carer.

Why does a language have to be something that you can pick up in two days to be viable for use in a high profile, or any profile, project? Can you pick up C or C++ in two days? Certainly not. Whether it takes two days or two weeks, the reason to choose a language isn't based on the time it takes to master that language. The time spent mastering a language is a drop in the bucket compared to the development time to complete a project overall. Experience in one language easily transfers to another language, so it's not as if you have to relearn the logic of programming. You can easily learn Rust within two weeks, but you can work with Rust as soon as day one and learn as you go along.

All that matters is your skill at designing efficient algorithms to solve problems with as little memory and CPU as possible. Rust frees the developer so that they can spend more time worrying about designing efficient algorithms instead of spending time worrying about and fixing critical, hard to discover bugs in your algorithms with debuggers. The need for debuggers is practically eliminated with Rust, with only a need for Rust's built-in test-driven development methodology. As someone with a minimal background in programming, Rust has allowed me to rapidly master the art of programming and develop efficient solutions that would be otherwise incredibly difficult to accomplish in a language like C++. It shouldn't be arguable that the need for software which cannot break and is rapidly developed is more important than continuing to use deprecated languages like C++ and C. The time to integrate and evolve is now.

If you're asking what Rust offers that you can't already do in C++, then take what you can do with C++ and augment that. Anything you can do in C++, you can do with Rust more efficiently, with more time to implement features, and less time fixing bugs. All the software I've developed with Rust has been rock solid upon release. The only bugs that you will happen upon are simple logic errors, but these logic errors quickly diminish as you improve your test units to cover every possible scenario for every piece of code. You can also add on the fact that you can take advantage of the sheer number of high quality, well-tested, brute force optimized crates from the Cargo community. Community-driven, and thoroughly tested by test units and all the software projects that use these crates, you have an unlimited number of features that you can quickly obtain in your projects without having to reinvent the wheel, and you are able to split up functionality of your own projects and upload them as individual crates for others to use and test as well. Rust has adopted all that is good about Node, and fixed all is wrong with Node (Cargo utilizes an immutable repository).

The next generation of programmers are picking up Rust, and you have entire swaths of programmers learning Rust that have no prior experience in systems level programming. These are Pythoners, Rubyists, Javascripters, and even people with no prior experience in programming. Rust is making it viable to achieve a mastery of systems programming rapidly, even if you aren't experienced. The compiler is a great teacher in itself, especially when coupled with the Clippy linter. You can't go wrong when writing Rust software as a beginner, because the compiler has you covered.

[Delgarde]

But this guy doesn't want the burden of maintaining core libraries, which is fine, and he should keep his mouth shut about things he doesn't understand.

And what makes you think you have a better understanding than long-term Gnome developers like Alberto, or *project founders* like Federico?