Michael Murphy (S76)

I’m a System76 engineer / Pop!_OS maintainer. I’ve been a Linux user since 2007; and Rust since 2015. I’m currently working on COSMIC-related projects.

  • 4 Posts
  • 13 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle




  • I don’t need Google to tell me what I already know since writing software in Rust for the last 8 years. It was your argument that Rust is not suitable for newbies. So if you want to change the topic to what language a person should learn, then Rust is most definitely at the every top. It’s a life-changing experience that significantly boosts your programming skill once learned. There’s a reason why it’s been the most loved programming language on Stack Overflow for seven consecutive years. Not because it’s hard, but because it’s enjoyable to learn and use. The patterns and techniques that Rust teaches are useful in every language.


  • The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language. I’ve known plenty of people who started their careers with Rust. I started my career with Rust, too. The complaint with difficulty adapting to the borrow checker has been irrelevant since the 2021 edition of Rust. The borrow checker has become smarter about rearranging borrows and automatically tagging lifetimes in most cases. The remaining constraints that the compiler enforces are also hard requirements to learn when developing software in any other language. The same practices equally apply to all software. For example, mutating an array while iterating it in Python or JavaScript will lead to unexpected behavior. Python and JavaScript’s lack of a proper type system causes a lot of software to explode at runtime when you think inputs are always X but suddenly in one case it happens to be Y.


  • I believe you’re mistakenly assuming it’s more difficult to work with than it really is. For example, imagine telling someone that pattern matching in Rust is more difficult than constructing unions and casting pointers in C. Even something as simple as string manipulation is a lot easier to do with Rust than in C or C++. I’ve worked with a number of people over the years that had little experience in programming outside Rust. It’s not that difficult.

    You’re not making the strong case that you think you are. Quite the opposite. The ease of “shooting yourself in the foot” is precisely what makes it so difficult to learn. Segmentation faults and random memory corruption make it incredibly hard to get started with programming. The compiler typically providing no help at all for diagnosing where the memory handling flaws are. You need to learn how to use a debugger to get anywhere with fixing them. Many people give up when it gets too difficult to diagnose them

    Rust’s constraints are very clear and concise in comparison, with a helpful compiler that will teach you how to handle memory correctly by pointing out the precise location where a borrow error occurs, and provides a suggestion for how to change your code to fix it. There’s never a question about whether a value will be passed or cloned. Cargo’s API documentation is also extensive in comparison to typical C or C++ documentation. It is a major boon for beginning programmers that the language ships a tool which automatically generates high quality documentation for every library you will ever use.


  • This is very over-exaggerated. A lot of people started with C or C++ as their first language. Both of which are significantly harder than learning Rust. In fact, I had a much easier time learning Rust than I had with Python and Java because the Rust compiler’s always had great error messages and documentation. Which then significantly boosted my ability to write C and C++. If, in an alternate reality, I had started learning programming today, I would recommend to my alternate self to start with Rust. Especially now that it’s gotten so much easier than when I had learned Rust when it was still in alpha. Error messages have gotten very detailed lately, to the point where many of them show the precise code to write to fix the error. The compiler’s also much less strict with borrowing and lifetimes.





  • The application crashes when I start it, perhaps due to wgpu. After switching to iced = { git = "https://github.com/pop-os/iced" }, I’m able to run it and see 7.7 MB memory consumption. We use a software-based renderer by default. Keep in mind though that Windows also doesn’t accurately report memory usage, and in Rust we have everything statically-linked into the binary. And there’s a lot of stuff being embedded and cached in memory at the moment as these libraries are being developed.


  • I’m mainly referring to how GTK is a very high level toolkit with many layers of abstractions and a number of complex functionalities built-in by default. Whereas iced in comparison is a low level library where you have to bring your own toolkit, or do it raw.

    You might be surprised by how heavy some of the more established GUI toolkits are, which you don’t see because the abstractions are hidden from view in dozens of event loops running asynchronously in the background on the same local thread.

    Iced widgets are collectively compiled down to a single state machine that pushes messages to a streamlined singular event loop. Commands and subscriptions are spawned on background thread(s). So the API by design keeps the UI thread free to focus on the UI.

    The Elm model gives you freedom to manage all of your memory in a central location efficiently. So you can easily render a complex responsive UI at 240 FPS even if you’re using software rendering. How fast it renders is going to depend on how you cache and reuse your data.

    You can pass data by reference to widgets so they’re drawn without allocating. You can load images on a background thread and cache them in your app struct so they only need to be decoded once. You can use lazy widgets, and even watch window dimensions to render most things in a single pass. Allocations are unfortunately required when you’re attaching multiple elements to a container, but that can change once Rust’s allocator API is stabilized.

    iced does also internally cache some things itself between frames so they don’t have to be re-drawn. And it’ll surely get more sophisticated in this over time. Especially once damage-tracking is fully implemented.

    And if you want a higher level abstraction with platform integrations built in, libcosmic is coming around the corner as a high level platform toolkit for making COSMIC applications with iced that’s tightly integrated with the COSMIC ecosystem. So you don’t have to worry about how you’re going to render client-side decorations, integrate with window manager protocols, implement theme support, configuration APIs, accessibility, etc.