Two Years of Rust
borretti.me
Two Years of Rust
1–10 of 69 posts
Re: Two Years of Rust
#2> with cargo you praise the absences: there’s no gotchas, no footguns, no lore you have to learn in anger, no weirdness, no environment variables
Suppose the author doesn't use build.rs, which appears to have been composed of the listed things almost entirely.
Re: Two Years of Rust
#3My biggest issue with rust after two years is just as you highlight: the mod/crate divide is bad!
I want it to be easier to have more crates. The overhead of converting a module tree into a new crate is high. Modules get to have hierarchy, but crates end up being flat. Some of this is a direct result of the flat crate namespace.
A lot of the toil ends up coming from the need to muck with toml files and the fact that rust-analyzer can’t do it for me. I want to have refactoring tools to turn module trees into crates easily.
I feel like when I want to do that, I have to play this game of copying files then playing whack-a-mole until I get all the dependencies right. I wish dependencies were expressed in the code files themselves a la go. I think go did a really nice job with the packaging and dependency structure. It’s what I miss most.
Re: Two Years of Rust
#4Gripes about the borrow checker I think would be cured with the following surprising fact, and interesting "problem solving" approach to the language's design:
In Rust there's at least 5 types of everything, in order of strength:
- Value / unqualified / "owned"
- Generically, T
- Optionally mutable
- &mut T
- you can only have one of these for a given value
- &T
- you can have arbitrarily many for a given value
- *const T
- you can have arbitrarily many, and they're not liveness checked
- *mut T
- you can have arbitrarily many, and they're not liveness checked
They also can 'fan out' like a multiple-dereference pointer, but the tricky part is how the APIs for Types conform to these, for example;
Since there are 3 different types of things in a collection, then there are 3 different ways to iterate over them `iter()`, `iter_mut()`, `into_iter()` in increasing order of strength. Most of the breadth or early complexity arises from the urge to treat these as a distraction, rather than a fundamental aspect of systems code.
Crates / modules are a bit of a meme: https://www.reddit.com/r/rust/comments/ujry0b/media_how_to_c...
Bevy has done some work investigating build performance: https://bevyengine.org/learn/quick-start/getting-started/set...
Re: Two Years of Rust
#5> Personally I didn’t have borrow checker problems, but that’s because before I started using Rust at work I’d designed and built my own borrow checker. I don’t know if that’s a scalable pedagogy.
Yeah... maybe not, but I can see this being a project in an undergraduate course.
Re: Two Years of Rust
#6Please don't take this the wrong way, it's just the editor in me.
There's a typo at the end of the Error Handling section:
When you need to explicitly handle an error, you omit the question mark operator and use thw Result value directly.
Re: Two Years of Rust
#7> with cargo you praise the absences: there’s no gotchas, no footguns, no lore you have to learn in anger, no weirdness, no environment variables Suppose the author doesn't use build.rs, which appears to have been composed of the listed things almost entirely.
build.rs is a useful escape hatch for if you need to do something more complicated, but the nice thing about cargo is that for the most part the defaults work. Generally build.rs only comes in if you have to deal with C, C++ or some other external ecosystem. A pure rust crate basically never needs to touch it, across multiple platforms and build configurations.
Re: Two Years of Rust
#8My biggest issue with rust after two years is just as you highlight: the mod/crate divide is bad! I want it to be easier to have more crates. The overhead of converting a module tree into a new crate is high. Modules get to have hierarchy, but crates end up being flat. Some of this is a direct result of the flat crate namespace. A lot of the toil ends up coming from the need to muck with toml files and the fact that…
It's a surprising choice that Rust made to have the unit of compilation and unit of distribution coincide. I say surprising, because one of the tacit design principles I've seen and really appreciated in Rust is the disaggregation of orthogonal features.
For example, classical object-oriented programming uses classes both as an encapsulation boundary (where invariants are maintained and information is hidden) and a data boundary, whereas in Rust these are separated into the module system and structs separately. This allows for complex invariants cutting across types, whereas a private member of a class can only ever be accessed within that class, including by its siblings within a module.
Another example is the trait object (dyn Trait), which allows the client of a trait to decide whether dynamic dispatch is necessary, instead of baking it into the specification of the type with virtual functions.
Notice also the compositionality: if you do want to mandate dynamic dispatch, you can use the module system to either only ever issue trait objects, or opaquely hide one in a struct. So there is no loss of expressivity.
Re: Two Years of Rust
#9> with cargo you praise the absences: there’s no gotchas, no footguns, no lore you have to learn in anger, no weirdness, no environment variables Suppose the author doesn't use build.rs, which appears to have been composed of the listed things almost entirely.
Nice to have when you still refuse to make learn
Re: Two Years of Rust
#10Gripes about the borrow checker I think would be cured with the following surprising fact, and interesting "problem solving" approach to the language's design: In Rust there's at least 5 types of everything, in order of strength: - Value / unqualified / "owned" - Generically, T - Optionally mutable - Mutable Reference - &mut T - you can only have one of these for a given value - Reference / Shared reference - &T - yo…
I feel like it's intuitive for me to think about this stuff as just a second type system rather than to think about the details of how the compiler works or how it'll function at runtime. A given value exists in a kind of superposition, and I pick the form I want it to collapse into (value, reference, mutable reference, etc) based on the tradeoffs I need at that moment. I don't know exactly why this is helpful, or if it's helpful (or even coherent) to anyone but me. It might also be damning me to some conceptual outer darkness where I'll hear the pounding of accursed drums and the wailing of hideous flutes forevermore.