[deleted]
Two Years of Rust
21–30 of 69 posts
Re: Two Years of Rust
#22> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…
Python requires less lines of code (much less?). Comparing Ruby with Python wouldn't shock me.
Re: Two Years of Rust
#23My 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 d…
How would you compare that to, say, go? I think the unit of distribution in go is a module, and the unit of compilation is a package. That being said, by using `internal` packages and interfaces you can similarly create the same sort of opaque encapsulation.
Re: Two Years of Rust
#24> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…
> I agree Rust is easy to learn. I've done it 4 or 5 times now.
https://www.lurklurk.org/effective-rust/ could be for you; while it starts from the very basics—for a person that knows how to program—it does seem to cover a lot and in a structured manner.
I expect one to learn something new at least something by page 70 :).
Re: Two Years of Rust
#25> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…
I really wish there was more of a discussion on Nim.
Re: Two Years of Rust
#26On mocking your database transaction: I was there, and on behalf of an LLM I reasoned with, I refactored that bit out to be an actor that carries the transaction, and passing messages (alongside a oneshot channel for return value). The benefit isn’t just that you’re not managing a transaction, but also that you don’t need to coordinate the transaction between multiple async paths where lifetimes and ownership really blow up!
I didn’t use an actor framework, for better or worse, but rolled my own.
Great write up!
Re: Two Years of Rust
#27>Rather than mentally implementing something in C/C++, and then thinking, “how do I translate this to Rust in a way that satisfies the borrow-checker?”, it’s better to think, “how can I accomplish the goal within the semantics of Rust, thinking in terms of linearity and lifetimes?”.
I still do think about it all in C++ terms. Borrowing and ownership are just specific terminology for things that you must know to create a correct C++ program of any useful complexity and performance. Two common anti-Rust arguments are:
- It's hard to learn
- You should just git gud at C++
But the Euler diagram of people who struggle with the borrow checker and people who are gud enough at C++ has no overlap. Likewise String and &str.
I also think it means the performance user story is, somehow, underappreciated, especially for naive users. Immutable borrows and moves are just part of the development experience, and copying is the unobvious path. And if you still struggle you can often just toss in `rayon` in ways that you never could with `std::execution::par`
Re: Two Years of Rust
#28Use dependency injection and mock behaviors. This technique works in several programming languages, including Rust. Rust has modules, crates and workspaces. To optimize builds, you'll eventually move shared resources to their own crate(s).
I feel in rust you want to be a lot more judicious in where you introduce and deal with traits than in other languages with interfaces. Author blames lifetimes for this but I think the truth is that it is because there is no garbage collector so not everything is a fat pointer and fat pointers cannot have generic methods anyways because generic methods are monomorphized so they feel a bit lame even if you would reach for them.
Thus you almost certainly need parametric polymorphism whereas other languages described would use implementation/interface/inheritance/duck polymorphism. Parametric polymorphism explodes rapidly if you aren't judicious and it doesn't feel very agile.
Once you are dealing in traits, does that trait have a copy bound or am I going to need to take a borrow and also grab a lifetime next to my trait parameter? Or should I just hide it all by slapping my mock with an `impl Trait for Arc>` or equivalent?
Re: Two Years of Rust
#29> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…
I really wish there was more of a discussion on Nim.
I've never looked closely at Nim because I think I don't need another fast GC language in addition to Go. What's your pitch for someone like me?
Re: Two Years of Rust
#30> The way I would summarize Rust is: it’s a better Go, or a faster Python That's an interesting take. I feel like all three of these languages fit into pretty discrete lanes that the others don't. Python for quick hacking or scientific stuff, Go for web services and self-contained programs, Rust for portability (specifically sharing code as C ABI or WASM) and safety. > It’s not hard to learn I agree Rust is easy to l…
> I agree Rust is easy to learn. I've done it 4 or 5 times now
No joke, is true.
When I see Rust first time I agree to everything, agree is the way, is correct and is nice (it hurt me a lot that have used around 10+ langs before professionally, and I come just right from F# so need so little to be converted!).
And obviously that is how I should have done the stuff if the other langs have the proper features!
Then, I need to actually program correctly and bam! Is so hard!
I need to relearn it many times. And yes, the hard part is to stop doing all the things that I have done in all the other langs implicitly.
BTW, the hard part with Rust is that a)It syntax is too familiar and b) Is a totally different programming model. Until it not get the second part and truly pay attention to `moves, borrow, share, lock, clone, copy` instead of `loops, iter, conditional, read, write, etc` then is very hard to progress.