Hacker News Comments on
Writing a Wayland Compositor in Zig - Isaac Freund
Zig SHOWTIME
·
Youtube
·
5
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.Rust does not bind well with C for this reason it can not become a system level programming https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-... However, there is another programming language that does not need bindings. It is called Zig and here it explains how it solves the same problem https://youtube.com/watch?v=mwrA5IRGpfU&feature=share
⬐ erk__But that it does not bind well with the memory model of a certain wayland implementation does not mean that it cannot bind well with C generally. It also does not mean you cannot use it for Wayland since there is a native Wayland implementation. [0]And for the systems level programming there is stuff like the current work to make use of Rust and the guarantees it gives in large C based systems like the Linux kernel.
That said that Zig is not a worthy endeavour, it does just not give as strong guarantees about memory safety as Rust works to give. (at least if this article is up to date [1])
[0]: https://github.com/Smithay/smithay
[1]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/
Congratulations! And welcome Isaac, I loved his Zig+Wayland screencast [1], where he explained very engagingly how Zig is able to embrace and extend a pretty hairy C library and make it more memory safe, without forcing the implementor to rewrite or painfully try to bend it to the strict or idiosyncratic rules of the language, as it may happen with Rust or even Go.I can't wait for 1.0! Or at least until the docs are a bit more accessible... :)
The author of River has also done some fantastic talks, on Zig ShowTime [1] and at FOSDEM '21 [2].[1] "Writing a Wayland Compositor in Zig" - https://youtu.be/mwrA5IRGpfU
[2] "Zig: the perfect language for a Wayland Compositor?" - https://fosdem.org/2021/schedule/event/zig_wayland
Another Wayland compositor written in Zig is ifreund/river [1].Isaac, the author, gave a talk on choosing C vs Rust vs Zig on Zig SHOWTIME a while back [2] and also has an upcoming talk at FOSDEM 21 [3]
[1] https://github.com/ifreund/river [2] https://www.youtube.com/watch?v=mwrA5IRGpfU [3] https://fosdem.org/2021/schedule/event/zig_wayland/
⬐ DyslexicAtheistthis talk is phenomenal thank you. he explains (timestamp: https://youtu.be/mwrA5IRGpfU?t=330) why he didn't go with Rust and it's quite puzzling what he says. I don't know enough about Rust if that's the case. To rephrase:"Rust was an obvious contender but it lacked good support for wlroots. there was a project which attempted to address this but they gave up after 12 months of work and 1000 commits. Rust's strong safety guarantees and memory management conflict with wlroots which assumes a longer lifetime of pointers. If you unplug your monitor with wlroots this pointer receives an event that means the output has disappeared and needs to be validated (see here https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-...).*
This is strange because Rust positions itself as a system language so I'd have imagined these scenarios are all over the place and unsafe Rust would be the way most of this is solved?
⬐ boudinWhat he mentions is wlroot-rs. If you're interested, here's the post from its author about the difficulties faced which lead to stopping development. http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...It was discussed here back then https://news.ycombinator.com/item?id=19778738
⬐ steveklabnik> I'd have imagined these scenarios are all over the placeNot as many as you'd imagine, really.
The core issue here is that lifetimes are a static validation mechanism. But wlroots has pointers that have a dynamic invalidation mechanism. There have been a few big attempts in systems like this to try and validate everything as statically as possible, and just like you'd imagine, the mis-match leads to pain. Rust absolutely has ways of doing dynamic validation, some including unsafe, as you've noticed. But some folks will try to push the boundaries. And that can often be really good! That's how progress is made. But like any experiment, sometimes it doesn't work out well.