Rust and its ways
-
Good morning CodeProject! I’ve decided to teach myself something new - apparently it’s important for older people to do that to stop them going mental. So behind the back of my loving, dependable and reliable C# I’ve been having a risqué affair with Rust. Turns out that developing in Rust is about 30% expressing your intention in code and 70% arguing with a bad-tempered bureaucratic compiler for who simply nothing seems good enough. I decided my first project would be a Suduko solver, which is done and it works, but there was an interesting point in the development where different runs would dish out differing results. I was using a HashSet internally, and like in .NET you shouldn’t make any assumptions about the order of the items if you iterate over it. Fair enough, but I would expect it to be consistent in that ordering between say releases of the .NET framework. Not so in Rust. Here’s a Rust program:
use std::collections::HashSet;
fn main() {
let mut set = HashSet::new(); for n in 0..5 { set.insert(n); } for n in set { println!("{}", n); }}
And here’s the output from running it twice: 0 3 2 1 4 and 0 2 1 3 4 Interesting huh? Something non-deterministic is going on. I haven’t debugged the HashSet yet to find out, but I’m presuming it’s using some random number or aspect of time somehow. I spoke with 'Gemini' about it yesterday and it agreed it's interesting, so thought I'd share it. :)
Regards, Rob Philpott.
-
Good morning CodeProject! I’ve decided to teach myself something new - apparently it’s important for older people to do that to stop them going mental. So behind the back of my loving, dependable and reliable C# I’ve been having a risqué affair with Rust. Turns out that developing in Rust is about 30% expressing your intention in code and 70% arguing with a bad-tempered bureaucratic compiler for who simply nothing seems good enough. I decided my first project would be a Suduko solver, which is done and it works, but there was an interesting point in the development where different runs would dish out differing results. I was using a HashSet internally, and like in .NET you shouldn’t make any assumptions about the order of the items if you iterate over it. Fair enough, but I would expect it to be consistent in that ordering between say releases of the .NET framework. Not so in Rust. Here’s a Rust program:
use std::collections::HashSet;
fn main() {
let mut set = HashSet::new(); for n in 0..5 { set.insert(n); } for n in set { println!("{}", n); }}
And here’s the output from running it twice: 0 3 2 1 4 and 0 2 1 3 4 Interesting huh? Something non-deterministic is going on. I haven’t debugged the HashSet yet to find out, but I’m presuming it’s using some random number or aspect of time somehow. I spoke with 'Gemini' about it yesterday and it agreed it's interesting, so thought I'd share it. :)
Regards, Rob Philpott.
Interesting indeed. My guess is that the Rust folks will say that that behaviour is by design, to stop you relying on assumptions about implementation details. In other words to encourage (probably can't go as far as 'enforce') robust algorithms.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Interesting indeed. My guess is that the Rust folks will say that that behaviour is by design, to stop you relying on assumptions about implementation details. In other words to encourage (probably can't go as far as 'enforce') robust algorithms.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
You know, I hadn't thought of that. By design, so that weirdness comes out early rather than later. Sounds like something the Rust brigade would do - good thinking!
Regards, Rob Philpott.
-
Good morning CodeProject! I’ve decided to teach myself something new - apparently it’s important for older people to do that to stop them going mental. So behind the back of my loving, dependable and reliable C# I’ve been having a risqué affair with Rust. Turns out that developing in Rust is about 30% expressing your intention in code and 70% arguing with a bad-tempered bureaucratic compiler for who simply nothing seems good enough. I decided my first project would be a Suduko solver, which is done and it works, but there was an interesting point in the development where different runs would dish out differing results. I was using a HashSet internally, and like in .NET you shouldn’t make any assumptions about the order of the items if you iterate over it. Fair enough, but I would expect it to be consistent in that ordering between say releases of the .NET framework. Not so in Rust. Here’s a Rust program:
use std::collections::HashSet;
fn main() {
let mut set = HashSet::new(); for n in 0..5 { set.insert(n); } for n in set { println!("{}", n); }}
And here’s the output from running it twice: 0 3 2 1 4 and 0 2 1 3 4 Interesting huh? Something non-deterministic is going on. I haven’t debugged the HashSet yet to find out, but I’m presuming it’s using some random number or aspect of time somehow. I spoke with 'Gemini' about it yesterday and it agreed it's interesting, so thought I'd share it. :)
Regards, Rob Philpott.
Rob Philpott wrote:
apparently it’s important for older people to do that to stop them going mental
Using Rust to de-rust your mind.
-
Good morning CodeProject! I’ve decided to teach myself something new - apparently it’s important for older people to do that to stop them going mental. So behind the back of my loving, dependable and reliable C# I’ve been having a risqué affair with Rust. Turns out that developing in Rust is about 30% expressing your intention in code and 70% arguing with a bad-tempered bureaucratic compiler for who simply nothing seems good enough. I decided my first project would be a Suduko solver, which is done and it works, but there was an interesting point in the development where different runs would dish out differing results. I was using a HashSet internally, and like in .NET you shouldn’t make any assumptions about the order of the items if you iterate over it. Fair enough, but I would expect it to be consistent in that ordering between say releases of the .NET framework. Not so in Rust. Here’s a Rust program:
use std::collections::HashSet;
fn main() {
let mut set = HashSet::new(); for n in 0..5 { set.insert(n); } for n in set { println!("{}", n); }}
And here’s the output from running it twice: 0 3 2 1 4 and 0 2 1 3 4 Interesting huh? Something non-deterministic is going on. I haven’t debugged the HashSet yet to find out, but I’m presuming it’s using some random number or aspect of time somehow. I spoke with 'Gemini' about it yesterday and it agreed it's interesting, so thought I'd share it. :)
Regards, Rob Philpott.
-
Aha! I should, perhaps, read the documentation sometimes, what with it being the first sentence and that. The crazy lengths we are forced to go to stop mitigate people attacking our software...
Regards, Rob Philpott.