Avatar
ben
dde900f94e3494e2c334ea94bc29fdfb034f8e10e682f53843a524d45c3b7d41
Software engineer, socialist. London, but from up north. Learning Finnish. Anti-AI, pro-human. (nb. I hate to do this but if you’re going to follow me please have a bio and/or posts etc. — it feels weird to be followed by someone when I can’t tell anything about them.)

nostr:npub1jx3dzll682rmfgzla5wwyjjsk5f05eml4845nrxvww3ulnt3shxqq0m6x6 Rust offers both, channels and locking with a Mutex or RwLock. There also more flexible channels in crossbeam:

https://github.com/crossbeam-rs/crossbeam

It doesn't force you to use the easier and less error prone channels, but it also makes sharing memory much easier. It is proven that data races are not possible in Rust. On the other hand, Go knows about the problem and tell you to run a program with an optin tool as long until a data race is detected (if it was reached):

https://go.dev/doc/articles/race_detector

nostr:npub129gvast08lj986yftn7q5qlnj8yfqufxx0m33s9u5xssjm8c64rsve4kwg yes, I don’t mean to suggest that Rust can only do things one way. That wasn’t really the point I was making. As I said, the Rust book’s explanation of how Rust makes mutexes safer improved my understanding of Go’s concurrency and the tradeoffs involved.

Finished both “Learning Go” and “The Rust Programming Language” today (latter of which has taken over a year, admittedly). Not sure I’m likely to be doing much Rust in the foreseeable future, but it’s been an interesting perspective — some things in Go have made more sense through learning how Rust does it too. (Like concurrency: “use message passing not shared memory” versus “here’s how rust makes shared memory safer”.)

#GoLang #RustLang