GNOME's SVG Rendering Library Migrating To Rust

[starshipeleven]

Say what you will but Visual Studio C++ is the only thing I use. That is a fact. There is no dispute. If you don't think I can only think Visual Studio with Resharper is the best IDE for C++, you don't know me or don't know that I'm a MS shill.

fixed.

[Guest]

Why??? Why is everything moving to Rust?

To appease the Phoronix readers :P

[Holograph]

Rust enables programmers to reason about concurrency more easily than C/C++/Java/etc. In the long term (20+ years), such programming languages are basically predetermined to take over the current languages, although the language that will emerge as the most widely used one might not be Rust.

This is the precise reason not to use it in my opinion. Not because it's particularly worse, but many of us have seen programming languages and other technologies come and go. Lots of languages over the years have tried to replace C. Even if a language is better it is no good to me as a programmer if I have to port it in a few years. A language is no better to me as a user if it ever causes any sort of dependency problems - though admittedly I have that issue far more often with scripting languages than I do with compiled languages.

A programming language is just a tool. A program is not good or bad specifically because of it. It's good because it's either got a useful purpose and works reasonably well, or bad if it fails either of those points. Thinking your program is great because you used some specific tool to program it is like owning a 4-wheel-drive truck that has to be dug out of the snow bank because you thought your safety in driving was only about the tool (the truck with 4WD) and not the other tool (the user) doing the driving.

Those of us who have to deal with these kinds of technologies at our jobs and end up supporting applications written in dead languages that were once "fads" find the people who push for using these technologies arrogant, and we don't think those people know better, even though they claim to. We've been there.

[mmstick]

This is the precise reason not to use it in my opinion. Not because it's particularly worse, but many of us have seen programming languages and other technologies come and go. Lots of languages over the years have tried to replace C. Even if a language is better it is no good to me as a programmer if I have to port it in a few years.

This argument has never been a valid argument when discussing a programming language. It fails to realize that the proponents pushing for the adoption of the language already know about the numerous languages that have existed before. It is an absolute necessity for mankind to push away from C and aim for a better future. If there's a better language, use it. Up until now, no language has ever come along as a serious contender against C. I've seen the history of languages, and I can tell you that no, no language has seriously attempted to replace C.

Every programming language that has come out has been too afraid to approach C. C++ chose to be a superset, and a poorly-written one at that. Since then, languages have been running away into their little virtual machine and garbage collection corners, hiding from resource management as much as possible. Rust has changed that, aiming for low level resource management and merging it with a powerful type system featuring zero cost higher level abstractions, functional programming concepts, generics, and even more importantly and unrelated to the language design itself: Cargo. It has a serious following behind it with more momentum than any other language. Rust has more signs of success than any language to ever have existed.

The argument about needing to port your software in a few years is completely and entirely invalid. List one programming language as extensive and ambitious as Rust that is aiming for the same thing: Zero. Name one programming language currently in development that could be ready to contend against Rust in the next five years: None. The amount of work that would be required to create a programming language to replace Rust at this point would be monumental, with no benefits.

Rust is backed by an extensive degree of research and community contributions. There's a large language RFC GitHub project littered with intense discussions on various aspects of language design. There are many in the Rust team that have PhDs in computer science and have enacted many bleeding edge programming language technologies and come up with killer features of their own (borrowing+ownership+move semantics+lifetimes). There is still much work being done to improve the language with evolutions to existing concepts, like this. There is serious infrastructure in place: there's a dedicated documentation team generating the best language documentation, a series of official website resources and services (Crates.io, Docs.rs, etc.), a global community software repository that expanded upon NPM's idea, a powerful toolchain manager that enables cross-compiling and convenient installation on any platform, a team that's reachable on IRC by any organization wanting to collaborate (GNOME's team has been in private discussions with Rust's team on shifting to Rust), and more importantly, a large community backing the project.

A language is no better to me as a user if it ever causes any sort of dependency problems - though admittedly I have that issue far more often with scripting languages than I do with compiled languages.

Dependency problems will never happen with Rust. Each version of a library that is uploaded to Crates.io will stay on Crates.io, permanently. Yanking a version of a library from Crates.io merely disallows new projects from using that version, but does not disable projects that still use that library. Cargo.lock files in binary projects will also ensure that Cargo downloads the exact version of each dependency required to build the project as it was built by you, the developer, upon release. Cargo and Crates.io performs hash checking to ensure that each downloaded dependency is valid. The only dependencies you need worry about are when you are importing non-Rust system libraries dynamically. If you're using MUSL to build your projects, then you're also going to be free of dependencies altogether.

A programming language is just a tool. A program is not good or bad specifically because of it. It's good because it's either got a useful purpose and works reasonably well, or bad if it fails either of those points. Thinking your program is great because you used some specific tool to program it is like owning a 4-wheel-drive truck that has to be dug out of the snow bank because you thought your safety in driving was only about the tool (the truck with 4WD) and not the other tool (the user) doing the driving.

There are many reasons to rewrite software in Rust.

Do you have any software that interacts with the Internet or are critical system libraries? Can you guarantee that your software is free of fatal security issues and exploits as a result thereof? Rust provides a number of interesting technologies that are of high interest to security-minded engineers. There's a new Rust-written memory allocator that's quite a bit more flexible than existing memory allocators. It provides some optional security features that are pretty interesting. There's also a concept going around to add the ability to shuffle fields in structs randomly in order to further protect against exploits that require data to be at specific offsets within a structure. This is in addition to the existing features that eliminate an entire class of security issues. The type system, lifetimes, borrowing and ownership -- it's been wonderful at preventing a large degree of software design fatalities.

Do you have software that is really slow? Mainly speaking of software that is not C/C++, Rust is the best option. You have all the low level resource management of C, but better features than C++. Even comparing a Rust project to a C/C++ project, often times the Rust project will come out on top in benchmarks. Why? Because Rust enables the programmer to reason about more complex optimizations that would otherwise be particularly incredibly dangerous to do within C and C++. While a C++ programmer might opt for a shared_ptr because that's the safe thing to do, a Rust programmer would go farther in optimizations because they do not need to fear the same safety concerns.

Those of us who have to deal with these kinds of technologies at our jobs and end up supporting applications written in dead languages that were once "fads" find the people who push for using these technologies arrogant, and we don't think those people know better, even though they claim to. We've been there.

Here's the thing about Rust: Rust requires that you write your software in a way that makes it incredibly stupid simple to refactor. I would rather rewrite a Rust project than rewrite a C/C++ project. If a better language comes out 20 years from now (doubtful considering Rust is an agile and rapidly-responding moving target), then it will be stupid simple to rewrite. Whatever languages that come out after Rust, they will either aim for competing against Rust's feature set and implementing them all the same -- hence becoming Rust -- or they will just add on to the army of JIT-compiled scripting languages.

[devius]

Oxygen is paramagnetic (attracted by magnetic fields), did you know? Yet it is not a metal, nor can it rust.

Interesting. I wasn't implying that only metal can be magnetic, but rather that only those types of metal among all other metals can be magnetic.

I like how some people are discussing actual rust instead of the programming language

[ssokolow]

You still didn't answer. Why should hundreds of millions of lines of code be rewritten in your toy fad language? Instead of, you know, progressing by contributing code to existing codebases instead of going back to the 70's and restarting history. Admit it. Rust is fucked.

Rust's success or failure does not depend on "hundreds of millions of lines of code be[ing] rewritten in [Rust]". It can be perfectly successful just seeing new projects written in it... and various companies are already quite happy with the results they've been getting.

(Dependencies being rewritten in Rust certainly does simplify reliable setup build environments and ease fully static compilation, but things like Go's native TLS library have already proven that people will rewrite the most important pieces if it really matters enough.)

Hell, if that were a requirement, C would be considered a failure because of all the FORTRAN code still chugging away in places like the BLAS implementation various applications in your Linux distro may depend on.

What it's trying to do is impossible. You're asking to stop progress in order to recreate everything. Nobody will do that.

Various people are already working on rewriting various things because it's their time and effort to waste as they see fit and they believe it is worth it.

Who knows whether it will ever become "hundreds of millions of lines of code", but it's clearly not "nobody".

[CrystalGamma]

Basically, undefined behavior is considered a bug in Rust. Rust is designed so as to not allow for undefined behavior, not even in unsafe code.


https://doc.rust-lang.org/nightly/re...ered-undefined

You're misunderstanding this. As said in the paragraph at the beginning, it is not allowed anywhere.
BUT: the compiler will only check for safe code (which is most of it) that these kinds of behavior do not exist in your program.

For code in 'unsafe {…}' blocks, it will blindly assume (just as a C compiler would for the entire program) that it does not allow such behaviour to be triggered, even indirectly through instructions outside of the blocks (do note however that the typesystem is still active in unsafe blocks, it's just relaxed far enough that it doesn't disallow certain instructions which can lead to undefined behavior). It is upon yourself as an author of such 'unsafe' blocks to make sure that the code is in fact not unsafe.

This is why there have been discussion among developers of the language/compiler (i. e. before stabilization in 1.0) to rename the keyword to 'trustme' or similar.

I, too, like the language, but don't promise things the compiler cannot deliver.

[mmstick]

You still didn't answer. Why should hundreds of millions of lines of code be rewritten in your toy fad language? Instead of, you know, progressing by contributing code to existing codebases instead of going back to the 70's and restarting history. Admit it. Rust is fucked. What it's trying to do is impossible. You're asking to stop progress in order to recreate everything. Nobody will do that.

At no point during this discussion has it ever been brought up that millions of lines of code are to be rewritten in Rust. In addition, most software in existence today was written relatively recently in the last 10-20 years. There's pretty much nothing that goes back to the 70's, not even Linux which began in 1993. When there is interest, it does not take much time to rewrite a large project in a new language -- just look at the progress that has been made by Servo and Redox.

Additionally, if you are saying that nobody is interested in rewriting software, then the very article that you are posting on is proof that you are wrong. I, myself, have even recreated most of the functionality of GNU Parallel with a Rust implementation by myself in no time at all.

[ⲣⲂaggins]

On the contrary, moving to Rust has decreased the amount of memory that librsvg consumes and reduced required CPU cycles.

As for reduced memory usage and cpu cycles, since librsvg uses glib internally, it seems you'd actually be comparing rust containers vs glib containers, not rust vs C/C++. Glib is not exactly renowned for its efficiency - it uses its own hand-rolled C version of everything, including reference-counting. A legitimate comparison target would be idiomatic modern C++.

The argument about needing to port your software in a few years is completely and entirely invalid. List one programming language as extensive and ambitious as Rust that is aiming for the same thing: Zero. Name one programming language currently in development that could be ready to contend against Rust in the next five years: None. The amount of work that would be required to create a programming language to replace Rust at this point would be monumental, with no benefits.

Err... one? Doesn't D count anymore

It also allows one to conveniently perform mass refactoring on a whim with zero issues, which is something that C and C++ codebases cannot do.

Qt creator provides highly convenient mass refactoring tools for C++, though its code model doesn't properly handle templates. If you really want perfect refactoring, there are several refactoring tools (github) using clang's astmatchers library, which being integrated directly with the compiler, guarantee zero issues. So that claim is untrue.

You have all the low level resource management of C, but better features than C++.

O rly? On stack overflow this would undoubtedly be met with cries of "Better features?! Define better.". It certainly has more features than C, but to say the same for C++ would be ridiculous. If anything it has fewer features, for example rust is sorely lacking an equivalent of subclasses and overriding. Its only substitute to C++'s polymorphism seems to be traits and recursive types, which are a rather less powerful substitute. And of course, the rust features C++ didn't already have, C++1z has totally stolen - optional/any/variant, string_view, structured bindings, etc.

Don't get me wrong though, I think rust is a great language, just some of your claims go a bit too far.

[mmstick]

As for reduced memory usage and cpu cycles, since librsvg uses glib internally, it seems you'd actually be comparing rust containers vs glib containers, not rust vs C/C++. Glib is not exactly renowned for its efficiency - it uses its own hand-rolled C version of everything, including reference-counting. A legitimate comparison target would be idiomatic modern C++.

C++ was evaluated as being unsuitable for use with GNOME. It doesn't integrate as nicely as Rust in C codebases. Additionally, Rust is able to optimize much farther than C++, for a variety of reasons I've outlined in prior posts.

Err... one? Doesn't D count anymore

D uses garbage collection and it is not feasible to remove it. It also has the same issues as C++ in regards to integration with C codebases. There's also a whole sleuth of other D-related issues that make it infeasible for inclusion in Linux distributions. So no, D never has counted, and still does not count. Rust has already eclipsed D.

Qt creator provides highly convenient mass refactoring tools for C++, though its code model doesn't properly handle templates. If you really want perfect refactoring, there are several refactoring tools (github) using clang's astmatchers library, which being integrated directly with the compiler, guarantee zero issues. So that claim is untrue.

Not particularly related to the kind of mass refactoring that I'm referring to.

O rly? On stack overflow this would undoubtedly be met with cries of "Better features?! Define better.". It certainly has more features than C, but to say the same for C++ would be ridiculous. If anything it has fewer features, for example rust is sorely lacking an equivalent of subclasses and overriding. Its only substitute to C++'s polymorphism seems to be traits and recursive types, which are a rather less powerful substitute.

Rust features lifetimes, a borrowing and ownership model, ad-hoc polymorphism and generics powered by traits, lazy functional programming, a powerful procedural macro system, significantly superior error handling strategy, proper pattern matching, channels-based concurrency, an Internet-powered modular build system, and a cross-platform toolchain manager, and more.

Aside from technical superiority, there are huge benefits to choosing Rust over C++. Namely, whereas C++ programmers must always be stuck in defensive programming practices and avoid optimizations that are particularly dangerous by standing 10 feet away from the line (ie: using shared_ptr when not needed), Rust programmers are able to comfortably toe the line and perform more excessive optimizations, safely.

And of course, the rust features C++ didn't already have, C++1z has totally stolen - optional/any/variant, string_view, structured bindings, etc.

The thing about C++ is that every feature it attempts to steal is always inferior from the original concept that it attempted to steal.

Don't get me wrong though, I think rust is a great language, just some of your claims go a bit too far.

I've been programming with Rust for two years. My claims are not going too far. In fact, I could go a lot farther. These points are all the result of countless hours of discussions within the community on topics just like this.