3 ms·

Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you

by brabel 3y ago

Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you're screwed.

baq 3y ago
Observation: Lifetimes are Rust’s checked exceptions in that regard. Changes propagate in the wrong direction - from leafs of the import tree down to the root. Solutions though… can’t really imagine one that makes sense.
peterfirefly 3y ago
I haven't really had to use lifetime annotations yet, but again, they are just a formalization of the way I already think. I forgot that I had also written a small cycle-by-cycle emulator of a simple CPU (8-bit data bus, 16-bit addr bus, 8 16-bit GPRs + a 16-bit PC + a single condition flag + an interrupt flag, timer interrupts, conditional jumps, call, ret, iret, mov, add, terminal I/O). That was also surprisingly easy. I would like to use generators or something similar for a more realistic cycle-by-cycle emulator but I haven't gotten around to playing with that yet. Generators and various kinds of coroutines are, yet again, just formalizations of the way I have been thinking for years. Maybe other domains would be more challenging but I seriously doubt it. I do know that it will take me a couple more months before I'm really proficient in Rust -- including multi-threading -- and no longer fear macros.
thumbuddy 3y ago
You probably shouldn't deal with lifetimes outside of first order use cases in 9/10 cases when a project is in its early stages. A clone or wrapper type isn't all that expensive in many applications. Just because something can be optimized doesn't mean it should be, especially early on in a project.
- ssokolow 3y ago
  *nod* Rust's "make costs explicit" design does have a bit of a problem with encouraging premature optimization where something like Python would encourage sloppiness.
  - thumbuddy 3y ago
    I'll take obvious jank over hidden jank any day personally.
    - ssokolow 3y ago
      I agree... you need discipline either way. It's just easier to wind up not realizing that you don't need to spend so much time on up-front optimization with Rust to produce a perfectly serviceable program. (Especially if you haven't internalized the whole "fearless refactoring" angle.)
      - thumbuddy 3y ago
        We'd probably be good on a team together. Nice to see like like-minded people in here.

by brabel 3y ago

Now try that on some domain you're not familiar with... If you ever have to change lifetimes of existing functions/structs on a non-trivial Rust code base, you're screwed.

baq 3y ago

Observation: Lifetimes are Rust’s checked exceptions in that regard. Changes propagate in the wrong direction - from leafs of the import tree down to the root. Solutions though… can’t really imagine one that makes sense.

peterfirefly 3y ago

I haven't really had to use lifetime annotations yet, but again, they are just a formalization of the way I already think. I forgot that I had also written a small cycle-by-cycle emulator of a simple CPU (8-bit data bus, 16-bit addr bus, 8 16-bit GPRs + a 16-bit PC + a single condition flag + an interrupt flag, timer interrupts, conditional jumps, call, ret, iret, mov, add, terminal I/O). That was also surprisingly easy. I would like to use generators or something similar for a more realistic cycle-by-cycle emulator but I haven't gotten around to playing with that yet. Generators and various kinds of coroutines are, yet again, just formalizations of the way I have been thinking for years. Maybe other domains would be more challenging but I seriously doubt it. I do know that it will take me a couple more months before I'm really proficient in Rust -- including multi-threading -- and no longer fear macros.

thumbuddy 3y ago

You probably shouldn't deal with lifetimes outside of first order use cases in 9/10 cases when a project is in its early stages. A clone or wrapper type isn't all that expensive in many applications. Just because something can be optimized doesn't mean it should be, especially early on in a project.

ssokolow 3y ago
*nod* Rust's "make costs explicit" design does have a bit of a problem with encouraging premature optimization where something like Python would encourage sloppiness.
- thumbuddy 3y ago
  I'll take obvious jank over hidden jank any day personally.
  - ssokolow 3y ago
    I agree... you need discipline either way. It's just easier to wind up not realizing that you don't need to spend so much time on up-front optimization with Rust to produce a perfectly serviceable program. (Especially if you haven't internalized the whole "fearless refactoring" angle.)
    - thumbuddy 3y ago
      We'd probably be good on a team together. Nice to see like like-minded people in here.