Librsvg wasn't maintained for years. We've received a huge amount of security bugs related to librsvg. Easily 10+ within a short timeframe. These weren't fixed because nobody was interested. The code itself is old and far from nice (from what I heard).
Federico volunteered to fix a few of these security bugs. This only resulted in people sending us even more security bugs. That required more time than Federico had. So again politely requesting for more assistance. Etc etc
Eventually Federico starts blogging about Rust, fixing super old but very visible bugs, etc. If you look at the announcement you'll notice how big just this one release is. He did way more.
Wikipedia relies on librsvg. The bugs were really hurting them. At one point it really seemed like maybe we'd better have a developer paid somehow to work on it.
Re:Librsvg now requires Rust
by stshine on Wednesday January 04, 2017 @05:07PM
(#13322558)
My initial motivation of following Rust is because it is the only language that can integrate into and extend the traditional Linux C world seamlessly except C++, which is generally hated by the open source culture. Glad to see the initial attempt goes well, and hope the gnome people will no longer need to construct GUI with C in the second decade of twenty-first century.
Re:Librsvg now requires Rust
by snuxoll on Wednesday January 04, 2017 @05:20PM
(#13322646)
> hope the gnome people will no longer need to construct GUI with C in the second decade of twenty-first century.
It may 'compile' to C, but we've had Vala for quite a while now. Honestly, my biggest complaints are the syntax is so close to C# that I always find myself trying to do stupid things like `using System.Collections.Generic;` instead of Gee, etc. Oh, and it would be REALLY NICE if the compiler had support for custom attributes without needing to patch the compiler itself (even just for storing metadata would be hugely beneficial, but I don't see any reason why there can't be a plugin api for the codegen side of things either).
Rust is great and all, but every time I play with it I just don't see how it would work well with the complex inheritance tree that is a widget toolkit (meanwhile GObject works just fine, even if it's a little verbose at the C-level).
Re:Librsvg now requires Rust
by flukus on Wednesday January 04, 2017 @06:32PM
(#13323179)
> Rust is great and all, but every time I play with it I just don't see how it would work well with the complex inheritance tree that is a widget toolkit (meanwhile GObject works just fine, even if it's a little verbose at the C-level).
I'm not convinced that this is the best way to build widget toolkits rather than just how it's always been done. I'd like to see one built more on traits like IClickable instead of subclassing button.
HTML/CSS is already like this (for styling only), attributes can be mixed and matched.
Re:Librsvg now requires Rust
by eridius on Wednesday January 04, 2017 @05:31PM
(#13322730)
> Rust is great and all, but every time I play with it I just don't see how it would work well with the complex inheritance tree that is a widget toolkit
I haven't actually done anything along this route myself, but I think the most promising approach is to model all the widgets as traits (and traits can depend on other traits, which lets you model the inheritance tree).
Re:Librsvg now requires Rust
by the_duke on Wednesday January 04, 2017 @06:27PM
(#13323135)
The problems lie both in the lack of field inheritance (something talked about in Rust as "virtual structs") and the difficulties with modeling a bi-directional tree structure with the borrow checker.
> Vala has been a great tool for prototyping, I love it myself, but debugging it is a nightmare, it’s filled with security issues and even if we fixed those really difficult problems, we’d be maintaining our own language on top of everything else. I would like to see us maintaining less stuff other than a desktop and the application development framework, not more.
Re:Librsvg now requires Rust
by stshine on Wednesday January 04, 2017 @05:30PM
(#13322727)
Sadly Vala is not safe, which is an essential defect for a high-level language, and It seems to be impossible to get wide adoption outside gnome world.
Lack of inheritance is a shortage of Rust, but maybe we can have a kind of React-like GUI library for it.
Re:Librsvg now requires Rust
by the_duke on Wednesday January 04, 2017 @06:24PM
(#13323105)
" Apologies in advance to distros who will have to
adjust their build systems for Rust - it's like taking a one-time vaccine; you'll be better off in the end for it."
Re:Librsvg now requires Rust
by matthewmacleod on Wednesday January 04, 2017 @05:23PM
(#13322668)
Well that's excellent! I just coincidentally started using librsvg from some Rust code, to rasterize some SVGs. Being relatively unfamiliar with Rust, it was still kind of straightforward to get that working. Pretty impressed overall, though I still find it quite an intellectually challenging language to write.
Re:Librsvg now requires Rust
by db48x on Thursday January 05, 2017 @04:51AM
(#13325956)
The only sure way to beat that type of attack is to write your own compiler on your own hardware, not to rely on a different compiler that someone else wrote.
Librsvg wasn't maintained for years. We've received a huge amount of security bugs related to librsvg. Easily 10+ within a short timeframe. These weren't fixed because nobody was interested. The code itself is old and far from nice (from what I heard).
Federico volunteered to fix a few of these security bugs. This only resulted in people sending us even more security bugs. That required more time than Federico had. So again politely requesting for more assistance. Etc etc
Eventually Federico starts blogging about Rust, fixing super old but very visible bugs, etc. If you look at the announcement you'll notice how big just this one release is. He did way more.
Wikipedia relies on librsvg. The bugs were really hurting them. At one point it really seemed like maybe we'd better have a developer paid somehow to work on it.
tldr: great effort by Federico.
It may 'compile' to C, but we've had Vala for quite a while now. Honestly, my biggest complaints are the syntax is so close to C# that I always find myself trying to do stupid things like `using System.Collections.Generic;` instead of Gee, etc. Oh, and it would be REALLY NICE if the compiler had support for custom attributes without needing to patch the compiler itself (even just for storing metadata would be hugely beneficial, but I don't see any reason why there can't be a plugin api for the codegen side of things either).
Rust is great and all, but every time I play with it I just don't see how it would work well with the complex inheritance tree that is a widget toolkit (meanwhile GObject works just fine, even if it's a little verbose at the C-level).
I'm not convinced that this is the best way to build widget toolkits rather than just how it's always been done. I'd like to see one built more on traits like IClickable instead of subclassing button.
HTML/CSS is already like this (for styling only), attributes can be mixed and matched.
I haven't actually done anything along this route myself, but I think the most promising approach is to model all the widgets as traits (and traits can depend on other traits, which lets you model the inheritance tree).
> Vala has been a great tool for prototyping, I love it myself, but debugging it is a nightmare, it’s filled with security issues and even if we fixed those really difficult problems, we’d be maintaining our own language on top of everything else. I would like to see us maintaining less stuff other than a desktop and the application development framework, not more.
Lack of inheritance is a shortage of Rust, but maybe we can have a kind of React-like GUI library for it.