yatta VS too-many-lists

I used Rust to prototype a new window manager in public and I found it very productive, easy to iterate on and make large changes without worrying about breaking anything.

Thanks! I had a look through the latest commit that you pushed to grist, and I noticed you handling errors from windows-rs in a similar way as I was doing in a previous project (yatta.

In general, I feel a lot better about this code base, the choice of data structures, and particularly the added safety around how I am calling unsafe Windows APIs in cleaner ways that allow me to propagate and handle errors when responding to WinEvents or socket commands (compare this mishmash to this much cleaner module!)

I wrote my very first window manager for Windows 10 in Rust earlier this here, I built it from the ground up using the new windows-rs crate. It was my first time developing anything for Windows and I was pleasantly surprised with the quality of the MS documentation ecosystem, and I also had a lot of great example code to learn from thanks to other projects like nog.

I am using this crate for a relatively non-trivial project (tiling window manager) and it has been pretty painless to use so far. From time to time, there will be an API or a type that is marked as not yet implemented, or an instance where the metadata it is generated from is incorrect, but the maintainer is helpful and responsive in my experience.

https://github.com/LGUG2Z/yatta/commit/87bc73eaa4f6ba7d00dbab2a6fb100f060b88ed8 Creating window floating rules based on partial title matching is added with this commit

I started working on yatta for Windows 10 because I was missing yabai and bspwm after I started working from a Windows 10 desktop last year.

I made a post about it on the Rust subreddit yesterday looking for more contributors: https://old.reddit.com/r/rust/comments/lh4uyq/yatta_bsp_tili...

It's still early days, but it has automatic tiling, gap control, focus switching, directional moving and tree orientation toggling and you can use AHK or any other hotkey daemon to manage your keybindings.

You still have to build it from source at the moment, but I'm hoping to have it installable via the Scoop package manager in a month or two.

https://github.com/LGUG2Z/yatta

I spent a couple of days hacking away to get something that works on Windows 10 with the bare minimum TWM functionality that my hands are used to, and I've managed to throw together Yatta: https://github.com/LGUG2Z/yatta (there is a demo gif on the readme).

You seem to have a preset opinion, and I'm not sure you are interested in re-evaluating it. So this is not written to change your mind.

I've developed production code in C, C++, Rust, and several other languages. And while like pretty much everything, there are situations where it's not a good fit, I find that the solutions tend to be the most robust and require the least post release debugging in Rust. That's my personal experience. It's not hard data. And yes occasionally it's annoying to please the compiler, and if there were no trait constraints or borrow rules, those instances would be easier. But way more often in my experience the compiler complained because my initial solution had problems I didn't realize before. So for me, these situations have been about going from building it the way I wanted to -> compiler tells me I didn't consider an edge case -> changing the implementation and or design to account for that edge case. Also using one example, where is Rust is notoriously hard and or un-ergonomic to use, and dismissing the entire language seems premature to me. For those that insist on learning Rust by implementing a linked list there is https://rust-unofficial.github.io/too-many-lists/.

Advent of Code was okay until I encounterd a problem that required a graph, tree or linked list to solve, where I hit a wall. Most coding exercises are similar--those requiring arrays and hashmaps and sets are okay, but complex data structures are a PITA. (There is an online course dedicated to linked lists in Rust but I couldn't grok it either). IMO you should simply skip problems that you can't solve with your current knowledge level and move on.

I feel obligated to point to the original cannon literature: https://rust-unofficial.github.io/too-many-lists/

I started learning Rust and like how the compiler is fussy about things. My plan was to implement the data structures I knew, but I got stuck at the singly linked list's remove() method. I've read the book as well, but I have no clue how to simplify this further:

My impression from the article is that Zig provides several different hashtables and not all of them are broken in this way.

This reminds me of Aria's comment in her Rust tutorial https://rust-unofficial.github.io/too-many-lists/ about failing to kill LinkedList. One philosophy (and the one Rust chose) for a stdlib is that this is only where things should live when they're so commonly needed that essentially everybody needs them either directly or to talk about. So, HashTable is needed by so much otherwise unrelated software that qualifies, BloomFilter, while it's real useful for some people, not so much. Aria cleaned out Rust's set of standard library containers before Rust 1.0, trying to keep only those most people would need. LinkedList isn't a good general purpose data structure, but, it was too popular and Aria was not able to remove it.

Having multiple hash tables feels like a win (they're optimized for different purposes) but may cost too much in terms of the necessary testing to ensure they all hit the quality you want.

> Cyclic references can be dealt with runtime safety checks too - like Rc and Weak.

Indeed. Starting out with code sprinkled with Rc, Weak, RefCell, etc is perfectly fine and performance will probably not be worse than in any other safe languages. And if you do this, Rust is pretty close to those languages in ease of use for what are otherwise complex topics in Rust.

A good reference for different approaches is Learn Rust With Entirely Too Many Linked Lists https://rust-unofficial.github.io/too-many-lists/

Second, once you've finished something introductory like The Book, read Learning Rust With Entirely Too Many Linked Lists. It really helped me to understand what ownership and borrowing actually mean in practical terms. If you don't mind paying for learning materials, a lot of people recommend Programming Rust, Second Edition by Blandy, Orendorff, and Tindall as either a complement, follow-up, or alternative to The Book.

Learning Rust With Entirely Too Many Linked Lists which highlights a lot of the differences with how you need to structure your code in Rust compared to other languages.