GNOME's SVG Rendering Library Migrating To Rust

[ssokolow]

I'm a hardcore C programmer and have a lot of Rest envy. I wish I were able to use Rust on practically all my projects. It would allow me to work faster and have fewer bugs, and basically have almost all of the advantages that C gives me.

Unfortunately, the design decision in Rust was that interfacing with the C ABI would require some work in most cases (wrapper code). This is reasonable all in all, considering that Rust really represents a necessary fresh start on low-level programming. But the costs right now are such that it's just non-trivial to have some of your code in Rust and some in C. It makes the most sense when you have a completely isolated bunch of code that could fit in its own "library," as is the case with SVG rendering. GNOME made a good decision here: it will improve the quality of the product and make it easier (and faster) to fix bugs when they appear.

Bottom line: Rust is awesome, but C is definitely here to stay.

Exploring ways to ease Rust integration with everything from C to JavaScript is a bullet point on their 2017 roadmap.

Remember, 1.0 just meant "we've stabilized the stuff we can't improve later without breaking people's code." In fact, so far, one of the big things they've been spending time on instead of easier integration is getting incremental compilation support to speed up the edit-compile-test cycle... and that's coming along very nicely.

[ssokolow]

Look! I've see people hyping VALA (or Vala) a couple of years ago and they came up with all the good pro's why everyone has to use Vala. VALA was claimed to do things better than C. And where is it now ? Does anyone still use it ? Ever programming language inventor claims that his (or her) programming language is the best and that it solves so many issues better than any other language.

Vala was essentially GNOME's attempt at a cross between QML and Rust... an attempt to provide a high-level API around GObject that compiles to C-compatible native code.

I was interested in it as an alternative to PyGTK, but here are a few things that really hurt it:

1. It's very GNOME-specific. (Support for building without glib and sacrificing support for object-orientedness came later, it's quite limiting, and the overall effect is to discourage anyone who doesn't spend a significant chunk of their time writing GNOME apps.)

2. The documentation has a lot of holes, it gave me a "libgd in PHP" sort of feel when it came to simple things like string manipulation (with PHP+GD, you can't get the raw bytes from a decoded image because GD's solution is "dereference the pointer" and PHP's API wrapper is too thin to provide an alternative.), and, as a result, it's really demoralizing to actually try to write something in it. (Rust doesn't have either of those problems.)

3. There is limited manpower interested in working on it and, as I remember, this has resulted in some soundness footguns laying un-fixed for a long time. (And a general lack of confidence in the product)

Bottom line: Given Rust's feature set, providing solid, comfortable GObject Introspection support for Rust will kill off every reason Vala has to exist. (That's one of the reasons it's so interesting to them. They get something superior to what they were trying to create and the maintenance burden can be shared.)

[M@yeulC]

This is blatant BS! No programming language will cover you from making any kind of bugs. And I really doubt that you will work faster because you switched to RUST. The speed gains you believe to have, will be paid with other stuff, related to your RUST work, in other corners during your work day.

Wow, I suggest you to re-read what you wrote here. Maybe just take it as a comment saying that C (or Rust or whatever) doesn't allow you to work faster than Assembly.

Even if I am not convinced that Rust is our Messiah, there have been some examples of programming languages (but also OSS, etc) that, while not completely revolutionary, allowed for a whole new level of complexity in software by suppressing common mistakes, and adding some safeguards against undefined behaviour.

If Rust can allow this, I am all for it. I started learning it, and will see by myself.

I do not however *completely* disagree with your other post (and yes, other programming languages will be around for a long time, just look at COBOL, Fortran, Pascal, Assembly, C... Anything with a decent code base). But I can't predict the future, and only time will tell if Rust was overrated or not. And I would be surprised if it wasn't here to stay.

[starshipeleven]

Because i'm retarded and I think it's cool to say Rust is something esoteric instead of the common plebs who see it as better than C++ and C?

fixed.

[starshipeleven]

An answer for a question that no one asked. The real question is: Do you know C or C++? Good, you're hired! We have a trillion lines of code written in those languages, no one is going to be bothered to rewrite them in anything else.

You probably meant Java and C#.

[starshipeleven]

This is blatant BS! No programming language will cover you from making any kind of bugs. And I really doubt that you will work faster because you switched to RUST. The speed gains you believe to have, will be paid with other stuff, related to your RUST work, in other corners during your work day.

It's very nice how you fail to mention any Rust-specific issue, are you perhaps trolling the same as master5000 that poses as C/C++ developer just to shit on things that don't come from MS's ass?

[Candy]

It's very nice how you fail to mention any Rust-specific issue, are you perhaps trolling the same as master5000 that poses as C/C++ developer just to shit on things that don't come from MS's ass?

Ah you again!

Your ass must be really jealous about the amount of shit comming out of your mouth.

I wasn't arguing about Rust or Rust specific issues. Please read my comments!

[starshipeleven]

I wasn't arguing about Rust or Rust specific issues. Please read my comments!

You make very strong claims, if those aren't backed up by some facts it's going to be seen as yet another mindless trollpost, not unlike Master5000's that is full of fail as usual.

But considering your posting history...

[emblemparade]

Too many people here feeding the trollls. Sometimes it's better not to reply! The universe will continue to dance even if someone was wrong somewhere on the Internet.

[emblemparade]

In fact, so far, one of the big things they've been spending time on instead of easier integration is getting incremental compilation support to speed up the edit-compile-test cycle... and that's coming along very nicely.

Yes, but that's something that still has a way to go. It's not just the speed of compilation, but it's that Cargo is hard to integrate into other build systems (I'm speaking from experience: I integrated it into Rōnin). If I have a big project with a bunch of C/C++ code and some build system for that, the Rust code lives in its own little universe, with hard-coded directory structures and in its own of doing things. My dream here is to have .c and .rs files live together and have a build system that would be able to work with either. Again, I totally understand the need for a fresh start on all the old thinking (Cargo is a joy to use if all you're doing is Rust programming), but the time has come for Rust and Cargo to come back into the real world.