How to speed up the Rust compiler in 2018

Re:How to speed up the Rust compiler in 2018 by danieldk on Monday April 30, 2018 @06:03AM (#16957237)

Couldn't you achieve the same thing in C++ by using message passing between threads instead of shared memory?

I know that the parent post used multi-threading as an argument in favor of Rust. But there are many ways to blow of your foot in single threaded C++. For example, consider this single-threaded code:

    std::vector<size_t> v;
    v.push_back(1);
    size_t *first = &v[0];

    std::cout << *first << std::endl;

    // The STL vector implementation will probably
    // reallocate the backing array at least once.
    for (size_t i = 2; i < 1000; i++)
      v.push_back(i);

    std::cout << *first << std::endl;

You wouldn't be able to introduce the same error in Rust. Once you borrow the an element of a Vec immutably, you cannot create mutable borrows during the lifetime of any immutable borrows. So the compiler would reject pushing new elements.

However, the mental cost a Rust programmer pays for that trade (due to borrow checker) seems too high for me

The thing is that most of the errors that the borrow checker will point out are potential programming errors in C or C++ as well. However, current C/C++ compilers will put most of the responsibility completely on you (plus tools like Valgrind). So, to me C++ has at least the same cognitive load if you want to program responsibly.

[ Parent | on HN ]

Re:How to speed up the Rust compiler in 2018 by rtpg on Monday April 30, 2018 @08:11AM (#16957858)

I agree with the general principle, but programming in Rust is not "program in C++, then fix errors". You really need to lay your code in away that will satisfy the checkers. That or jump into unsafe mode.

A good example of the challenge is that there's unsafe inner code in rusts own container code. If you try to build your own custom containers (or things like arenas) you'll likely work with unsafe code... Or rely on rusts container code (not a bad thing of course).

My feeling is that "C to Rust" is close to "Java to Haskell" more than anything else. The extra layers are important enough that they need a new thought process. (I say this as a proponent of rust)

[ Parent | on HN ]

Re:How to speed up the Rust compiler in 2018 by xfer on Monday April 30, 2018 @10:13AM (#16958701)

Same thing is also true in C++, the stdlib also uses "unsafe" pointers inside, but you can use unique, shared etc.

> You really need to lay your code in away that will satisfy the checkers.

There are some patterns that are common but problematic but are being addressed by non-lexical lifetimes. Other than that it's almost "program in C++, then fix errors".

[ Parent | on HN ]

Re:How to speed up the Rust compiler in 2018 by danieldk on Monday April 30, 2018 @11:08AM (#16959169)

You really need to lay your code in away that will satisfy the checkers.

But that becomes a second nature after a while. I think all the edge cases that still exist make it more problematic. E.g. I was writing some SIMD code yesterday with a loop somewhat like this (simplified):

    let mut v = vec![1.0, 2.0, 3.0, 4.0, 5.0, 6.0];
    let mut s: &mut [f32] = &mut v;
    
    while s.len() >= 2 {
        println!("{:?}", s);
        s = &mut s[2..];
    }

Playground: https://play.rust-lang.org/?gist=104348b0edb96ca0f68d701373e...

It makes you scratch your head for a bit.

A good example of the challenge is that there's unsafe inner code in rusts own container code.

I am pretty proud that one of my first small Rust projects was a randomized ternary trie. Apparently, it does not use unsafe anywhere.

https://github.com/danieldk/rtrie/blob/master/src/ternary.rs

Not that I am proud of the code ;).

But in all seriousness, unsafe in container code is somewhat expected, because at some point you need to wrap raw memory (as e.g. in Vec). I think quite a bit of, but probably not all, unsafe use in containers such as Vec comes from that.

[ Parent | on HN ]