3 ms·

One forgets how hard it was to climb the mountain once one has climbed the mountain.

• retrac 5y ago
  You're right, in fairness. It's gruelling sometimes. Five years of on-off hobby programming with Rust and I still fight the borrow checker with every other function. How to implement things in a way that makes Rust happy is often not at all obvious. But the idea does seem useful enough to keep persisting at it.
  • Measter 5y ago
    I'm really curious why some people have such a hard time picking it up. My experience has been the complete opposite, everything just clicked and it all made sense (at least, until you get to the gnarly stuff). What was the difference in our mental models that caused this?
    • retrac 5y ago
      The basic idea clicked pretty quickly with me. A restricted memory model that sort-of guarantees a number of awful things can't happen. Makes sense. But how do I express working things in it? The obvious approaches conflict with the rules. A simple emulator in a C-style might consist of a UI thread and a compute thread. The UI thread sends messages to the compute thread. You can have some timing though not usually safety/crash issues if you do this without locks. So maybe you do or don't lock that. But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. Simple, fast, almost-safe. How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? It's hard to get that right.
      • zozbot234 5y ago
        > But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. ... How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? You can use atomic types with custom memory ordering, just like you would in C.