Besides interacting with the C FFI, all problems in Rust are solvable without the involvement of unsafe. Mastery of Rust requires learning how to handle borrowing conflicts, and all borrowing conflicts can be resolved without unsafe. To think otherwise would only mean you aren't skilled enough to write Rust code professionally yet.

All borrowing conflicts can be resolved either by restructuring code to avoid incompatible borrows, through the use of a cell type, temporarily taking ownership with a mem::replace, a mutex, a slab or arena, or by spawning an event loop that handles messages from channels.

Anyone needlessly using unsafe will be harshly criticized should they happen to release a crate that a lot of people depend on and are unable to produce a reasonable justification for that use. I most often see it used either for performance reasons, or because is a novel algorithm accompanied by a research paper that is validated with miri.

I'm the author of system76-scheduler. Before you accuse projects of Rust propaganda, try reading the README of the project you're accusing. There's no mention of Rust in the README outside of the fact that I detailed the format of its configuration files as "Rusty Object Notation". It's completely reasonable for me to declare the formatting of its configuration file. Regardless, it would also be perfectly normal for a project's own README to mention what language it is written in. C++, Java, and Python projects do the same thing.

I don't get to choose what random people across the Internet decide to write in their headlines and articles. I know many of them place Rust in the headlines precisely because it generates from clicks from people who have knee-jerk reactions about it, like yours. The fact is that Rust is a very popular programming language topic to talk about right now, and so when journalists see the opportunity to mention that a project is written in Rust, they will.

Next time, take some time to read about the project before claiming it fraud. I wouldn't have developed it if I did not think that it could improve desktop responsiveness. QA would not have approved it if it did not prove itself in lab testing. It wouldn't make sense to develop software solely for the sake of promoting a programming language. It does what it was written to do, and that's all that really matters to the end user at the end of the day.

Finally, every company chooses programming languages based on what they believe to be the best choice for their needs. If a company has a team of C++ developers writing software in C++, they are writing software in C++ because they believe that to be in their best interest at that place and point in time. System76 believes that Rust is in our best interest as opposed to C and C++, and hire talent accordingly. If you are going to make judgements, make judgements on the results, not on the tools that were used to produce those results.

Nice is just a command that applies a priority to a process. This is a system service that systematically applies priorities to processes across the entire OS based on inputs from the window manager informing it about the foreground process, and pre-defined priorities assigned by configuration file(s). When coupled with some supporting software for that specific window manager, such as pop-shell in Pop, it sets the focused window and its sub-processes to a higher priority than background processes.

I'm the author of the project. The format that I chose for system76-scheduler shouldn't matter to anyone. system76-scheduler is the only consumer of its own configuration files. The whole point of choosing RON is because it can succinctly express maps with arrays better than TOML and JSON. Implementation-wise it's just importing serde, adding attributes to your config struct, and typing `ron::from_str(&buffer)` to deserialize the buffered file.

{ -5: [ "high-priority-task" ], 5: [ "low-priority-task"] }