Hacker News Reader

Comment by Klonoar | Hacker News Reader

>Zigs solution is hands down better for actually getting work done

Rust has seen significant usage in large companies; they wouldn't be using it unless it was usable for "real work".

>Full disclaimer, I'm pretty bad at systems programming. Zig is the only one I've used where I didn't feel like memory management was a massive headache.

I'd say this about Rust, though. Rust's mental model is very straightforward if you accept the borrow-checker and stop fighting it. Can you list any examples of what you think is a headache...?

>In practice it rejects too many valid programs, over-complicates the language, and makes me feel like a circus animal being trained to jump through hoops.

I've found that jumping through those hoops leads to things running in production that don't make me get up in the middle of the night. Can you show me a "valid program" that Rust rejects?

View on HN

Rust has seen significant usage in large companies; they wouldn't be using it unless it was usable for "real work".

I didn't say it wasn't usable. I said I found Zig more usable.

I'd say this about Rust, though. Rust's mental model is very straightforward if you accept the borrow-checker and stop fighting it. Can you list any examples of what you think is a headache...?

Mate, I didn't start learning rust in order to wage war against the borrow checker. I had no idea what the hell it wanted a lot of the time. Each time I fixed an error I thought I got it, and each time I was wrong. The grind got boring.

As for specific examples no, I've tried to put rust out of my mind. I certainly can't remember specific issues from 3 months ago.

I've found that jumping through those hoops leads to things running in production that don't make me get up in the middle of the night. Can you show me a "valid program" that Rust rejects?

Yeah that's how rust as sold, the compiler is your friend and stuff will compile and it will never fail.

In reality the compiler was so irritating I hardly got anything done at all. The output wasn't super reliable software, it was no software.

Sounds like you got annoyed trying to learn something new, quit, and decided it's not worth your time. When people tell you it takes a few weeks to get the hang of rust they aren't kidding. Most people aren't the exception to that, but once you do get it, it's really great... Not kidding about that either...

I think I spent about two months. You're right, I do resent the time I spent on it. In a way I'd like to warn others.

The turning point came for me when talking to someone using rust pretty much since it first came out. He basically said "yeah, I still don't know why it doesn't compile either sometimes". He's smarter than me, and all he's managed to do in years of learning it is have a knack for fixing errors without understanding them.

I need some brain capacity left over for actually solving a problem.

I agree with the parent. Rust is hard because it fundamentally inverts the semantics of pretty much every other programming language on earth by making move semantics the default instead of copying.

Yet there’s no syntax to indicate this. Worse, actual copies are hidden behind a trait that you have no way of knowing whether a particular external lay defined type implements it or not outside of reading documentation. A lot of Rust’s important mechanics are underrepresented syntactically, which makes the language harder to get used to imo. I agree with the parent that in general it’s better for things to be obvious as you’re writing them—if rust had syntax that screamed “you’re moving this thing” or “you’re copying this thing because it implements copy” that’d be a lot easier to get used to than what beginners are currently stuck with which is a cycle of “get used to the invisible semantics by having the compiler yell at you at build time until you’ve drilled it into your head past the years of accumulated contrary models” and oh, as soon as you have to use another language this model becomes useless, so expertise in it does not translate to other domains (though that will hopefully change in the future)

> they wouldn't be using it unless it was usable for "real work".

We had to introduce Rust at work because we really needed some WASM functionality in one of our mostly JS frontends... anyway, I was excited about Rust and all and pushed the idea, implemented the whole thing and made presentations for other developers about Rust. I was thinking everyone would be as excited as I was and would jump at the chance of maintaining the Rust module.

In reality , only one of the 20+ devs even tried to ever touch the Rust code. Everyone else thought the code looked like Greek (no offence to my greek friends!) ... today when the code needs change, I am pretty much the only one who can do it, or the other guy (who is more novice than me in Rust so takes a lot longer to do anything, but at least there's someone else).

For reference: we write code in Java/Kotlin/Groovy/Erlang. So, we're not a system programming shop in any way, so I can't speak for places where C and C++ were previously being used.

I would be curious how your shop fares with Swift then, considering it may also look "like greek" to them.

(Legit point, no snark)

Everyone seems alright with Kotlin, and Swift seems close enough to Kotlin that I think they would do fine (we do have a few frontend devs that do Swift BTW).

> Can you show me a "valid program" that Rust rejects?

    #[derive(Debug)]
    struct Foo {
        a: i32
    }
    
    fn thing(foo: &mut Foo) {
        match foo {
            f @ Foo { a } if *a > 5 => {
                println!("{:?}", f)
            }
            _ => {}
        }
    }

There's no reason it should reject that, as the use of the `a` reference doesn't interleave with the use of `f`.

By creating `f` you're in essence trying to borrow something that's mutably borrowed already, which the borrow checker doesn't allow. I guess I could see some logic for this being possible, but in practice I've never encountered this in any Rust codebase I've gone through.

The trivial example fix is just to... ensure it can copy, and tweak the match line:

    #[derive(Copy, Clone, Debug)]
    struct Foo {
        a: i32
    }
    
    fn thing(foo: &mut Foo) {
        match *foo {
            f @ Foo { a } if a > 5 => {
                println!("{:?}", f)
            }
        
            _ => {}
        }
    }
      

    fn main() {
        let mut x = Foo { a: 1 };
        thing(&mut x);
    }

If the struct was bigger and/or had types that couldn't copy, I'd refrain from trying to shoehorn matching like that entirely.

The borrow checker does allow that, though, as long the uses don't interleave and the references created correctly. As long as `f` is not used between `a`'s creation and last use, and `a` comes from `f`, it's valid for that alias to exist. You can see that with this code example, which is accepted:

    #[derive(Debug)]
    pub struct Foo {
        a: i32
    }
    
    impl Foo {
        fn get_a(&mut self) -> &mut i32 {
            &mut self.a
        }
    }
    
    pub fn thing(mut foo: &mut Foo) {
        let f = &mut foo;
        let a = f.get_a();
        if *a > 5 {
            println!("{:?}", f);
        }
    }

That's why I was so surprised the compiler rejected it.

Reply on news.ycombinator.com