Learning Rust and Lemmy

387 readers

1 users here now

Welcome

A collaborative space for people to work together on learning Rust, learning about the Lemmy code base, discussing whatever confusions or difficulties we're having in these endeavours, and solving problems, including, hopefully, some contributions back to the Lemmy code base.

Rules TL;DR: Be nice, constructive, and focus on learning and working together on understanding Rust and Lemmy.

Running Projects

Rust for Lemmings Reading Club (portal)
Rust beginners challenges (portal)
Heroically Helpful Comments

Policies and Purposes

This is a place to learn and work together.
Questions and curiosity is welcome and encouraged.
This isn't a technical support community. Those with technical knowledge and experienced aren't obliged to help, though such is very welcome. This is closer to a library of study groups than stackoverflow. Though, forming a repository of useful information would be a good side effect.
This isn't an issue tracker for Lemmy (or Rust) or a place for suggestions. Instead, it's where the nature of an issue, what possible solutions might exist and how they could be or were implemented can be discussed, or, where the means by which a particular suggestion could be implemented is discussed.

Rules

Lemmy.ml rule 2 applies strongly: "Be respectful, even when disagreeing. Everyone should feel welcome" (see Dessalines's post). This is a constructive space.
Don't demean, intimidate or do anything that isn't constructive and encouraging to anyone trying to learn or understand. People should feel free to ask questions, be curious, and fill their gaps knowledge and understanding.
Posts and comments should be (more or less) within scope (on which see Policies and Purposes above).
See the Lemmy Code of Conduct
Where applicable, rules should be interpreted in light of the Policies and Purposes.

Relevant links and Related Communities

Thumbnail and banner generated by ChatGPT.

founded 9 months ago

MODERATORS

[email protected]

References are like jumps (general blog post on ownership and references in rust) (without.boats)

submitted 5 months ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 5 months ago* (last edited 5 months ago) (1 children)

unsuited to Rust's current state

for me this mostly comes down to the state of the ecosystem (game dev with godot, websites in js are 2 cases where I'm not really interested in using rust) but for example when I want to just solve a problem and the input size won't cause a naive approach to run very slow, I'll probably grab python instead or if the solution is something hyper dynamic (a la dynamic programming), it would probably be simpler in ocaml or haskell or f# - ie something more "truly" immutable so that you don't have to worry about data lifetimes or manual memory management (and it's generally very cheap and elegant to push & pop from stacks and queues in such languages)

re: causality and "spooky action at a difference"

It's more:

mutable vs immutable references mean any mutable access must happen before or after all other accesses [to the same data]
any access to a moved value must happen before the move itself

So ownership effectively imposes a certain causal order on your code, that emerges from which behavior uses/accesses which data. In many aspects it's way too hazy to act as a "proper" causal order, but I often find it easier to write code that passes the borrow checker on the first try when I try to organize my code according to this notion.

I would almost describe my mental image as if there were compiler-enforced RWLocks on all mutable references, and as if all moves are somehow telling the os to change which virtual memory address is mapped onto the (moved) data (without actually copying the data into a different part of memory).

[–] [email protected] 1 points 5 months ago

Yea nice.

I'd kinda developed the same attitude but never really thought about it in terms of "causality" as you put it. Instead I had more of a "clean code" or "efficiency" framing, but I like yours much better.