Comment by bsder | Hacker News Reader

Comment by bsder | Hacker News Reader

Parent Full thread

Wayland needs a restart. I get (and applaud) the aggressive "not in scope" as the developers don't want to be maintaining the universe and dealing with nVidia, AMD, and Intel is difficult enough. I really wonder if implementing this stuff in something other than C/C++ (Go, Nim, D, Ada, Zig, Rust, etc.) would be an improvement as it would force developers to come to grips with "No, you DON'T own that memory and you can't bash on it and people who want to use your system won't either. Figure out how to abstract that."

It's become pretty clear that their abstractions aren't correct. If I have to link against a gigantic C library just to get window decorations, we have a deeper problem.

(see: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i... for how big it is)

> Currently there is 11 THOUSAND lines of Rust in wlroots-rs. All of this code is just wrapper code, it doesn’t do anything but memory management. This isn’t just repeated code either, I defined a very complicated and ugly macro to try to make it easier.

> This wrapper code doesn’t cover even half of the API surface of wlroots. It’s exhausting writing wlroots-rs code, memory management is constantly on my mind because that’s the whole purpose of the library. It’s a very boring problem and it’s always at odds with usability - see the motivation for the escape from callback hell described above.

> (see: http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i... for how big it is)

Disclaimer: I don't know Rust beyond println!("Hello World"); C is my preferred language for decades now.

The example Rust code in that linked post is just an absolute unreadable horror show. If that's representative of what it's really like to interop C with Rust or just write real Rust code in general, I'm strongly discouraged from bothering to put more effort into the language.

Can anyone skilled and experienced enough with Rust to judge what's going on there comment? Is the author just a noob making a mess of things as anyone can do in any language, or is this limited to C interop? Or is Rust normally such an inscrutably verbose disaster?

I've written a bit of Rust/C interop. It doesn't look like that; most of the time it's... not pleasant, since it's interop, but certainly not this terrible.

On the other hand, I can't think of a way to do it better either. wlroots might just be uniquely horrible here.

Author here. Certainly part of the ugliness of wlroots-rs is my fault (unsafe code + macros is not a fun combination).

However, I tried quite a few ways to make this safe and ergonomic. Perhaps some better way exists that I missed, but even if a solution exists the work needed to implement it is very, very boring.

wlroots is very much a C API, but I admit I was expecting it to be easier to use from Rust and is my current biggest criticism with the language.

Normal Rust is normally not this inscrutable - however it does have a lot of features that could make it as hard to read. It requires a certain amount of discipline that you don't see in simpler languages like Go. I for one never write macros if I can help it anymore.

> It's become pretty clear that their abstractions aren't correct. If I have to link against a gigantic C library just to get window decorations, we have a deeper problem.

Is there a write-up of the critique of this issue?

I read the Waycooler blog posts but they didn't go into details.

Lack of server side decorations in the core spec, and limitations of wlroots, are unrelated so I'm not sure what they're getting at (except to support the larger idea that Wayland is poorly designed, which I disagree with. However, I think I'm a little too attached because of my involvement)

Wayland and the surrounding ecosystem is written with the fundamental assumption that you will be coding in C/C++. Abstractions and architectures were written assuming that.

In the last 15 years, that assumption has broken. People want to write applications specifically avoiding C/C++ and even Gnome/KDE.

Wayland has not adjusted to this new reality. It is not clear that it may even be able to.

The problem is that this kind of graphics system programming is a gigantic pile of work while being very fiddly with non-obvious details that you have to get correct. Very little of it is "fun" and the people qualified to be doing it are capable of earning a lot more money doing basically anything else. The fact that almost exactly the same people doing Wayland were the ones doing X11 previously shows that nobody is jumping up and down for the chance to attack this.

You can link against libdecor to get window decorations. It is a young project and there are certainly lots of issues with it, but at least it is not one of the big GUI toolkits.

Reply on news.ycombinator.com