Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turning off Rust's borrow checker completely (2022)

iter.ca

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Turning off Rust's borrow checker completely (2022)

#41

Post by Klonoar »

josephg wrote: post #18
Klonoar wrote: post #9

Earlier quoted context omitted.

You can’t really hate something that you profess to not deeply understand.

Of course you can. In fact, I think it’s often much easier to hate something when you don’t understand it fully. But in this case, the GP was describing their experience programming with the borrow checker as a new rust programmer. Hatred is an emotion. It’s not up to you or me to decide if that feeling is present in someone else’s brain.

I would classify that emotion as anger or frustration. Hatred is something deeper, and I don't think you can be there without deep understanding of what you're hating.

But it's ultimately whatever.

Re: Turning off Rust's borrow checker completely (2022)

#42

Post by [deleted] »

matesz wrote: post #30
YetAnotherNick wrote: post #20

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc >.

I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware. However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies. [1] https://github.com/makepad/makepad/

[deleted]

Re: Turning off Rust's borrow checker completely (2022)

#43

Post by YetAnotherNick »

Fiahil wrote: post #24
dvt wrote: post #23

Earlier quoted context omitted.

> ... What are you doing ? It's definitively unusual. No it's not, it's extremely common. `Arc >` or `Arc >>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely…

> No it's not, it's extremely common. Arc-Mutex yes, Arc-Box no. It's like "I want a shared, immutable reference to something recursive, or unsized". The heap part makes no sense because it's already allocated there if you use an Arc : https://doc.rust-lang.org/std/sync/struct.Arc.html > The type Arc provides shared ownership of a value of type T, allocated in the heap. Moreover, you don't even need the box for a dyn…

I don't exactly remember the exact thing I used that's why I said "I resorted to things like.. ". Also, I used actix web, which could be the reason of slow compiling code.

Re: Turning off Rust's borrow checker completely (2022)

#44

Post by YetAnotherNick »

matesz wrote: post #30
YetAnotherNick wrote: post #20

I have limited experience with Rust and the combination of slow compile time and borrow checker is irritating. My rust code was less than a thousand lines and it takes like 10-20 seconds to compile. Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc >.

I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware. However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies. [1] https://github.com/makepad/makepad/

I used actix web, could it be the reason for slow compile?

Re: Turning off Rust's borrow checker completely (2022)

#45

Post by olvy0 »

needlesslygrim wrote: post #40
olvy0 wrote: post #35

It's been a while since I've programmed in Rust, and I was initially surprised that the get() call returned garbage. Could anyone explain why that is? I mostly program in C++ and C#. After thinking about it, my intuition is that: - the Vec was passed by value to the function, which in Rust means something different than passing a std::vector in c++ to a function, due to... - Due to the language semantics, its referen…

You're mostly correct, it is moved into the function (pass by value), and then, at the end of the function's scope, the destructor is called automatically (as the compiler inserts a call to `drop()` at the end of the function) which de-allocates the vec, causing the reference obtained in `main()` become a dangling pointer.

Thank you!

Re: Turning off Rust's borrow checker completely (2022)

#46

Post by miki123211 »

I wonder if you could actually write a compiler that does this for compilation speed. Have one mode where the compiler is super fast, has no error checking and can compile some malformed programs, and another mode where the compiler does all the checks.

This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes that check for them are just pure and unnecessary overhead.

I don't know how practical this is, I don't have much experience in compiler design (beyond very small and toy compilers).

Re: Turning off Rust's borrow checker completely (2022)

#47

Post by eropple »

miki123211 wrote: post #46

I wonder if you could actually write a compiler that does this for compilation speed. Have one mode where the compiler is super fast, has no error checking and can compile some malformed programs, and another mode where the compiler does all the checks. This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes…

> This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes that check for them are just pure and unnecessary overhead.

It's not an identical case, but TypeScript offers this with `skipLibCheck`. Most people use it. It's generally good--until it's really not good and you eat half a day unwinding a deceptively broken dependency.

Re: Turning off Rust's borrow checker completely (2022)

#48

Post by gkbrk »

timschmidt wrote: post #33
flohofwoe wrote: post #32

Earlier quoted context omitted.

IMHO Makepad also has an exceptionally readable Rust code style, which is a very rare thing (maybe that simple Rust style even contributes to the good build times, dunno) - but also: from the pov of a C programmer, 200 kloc in 10..15 seconds is still quite bad ;)

How quickly can you verify the memory safety of that C program in addition to compiling it though? When comparing like to like, C no longer looks so fast.

Rust code with unsafe still compiles slowly. And safe subsets of C still compile quickly.

Re: Turning off Rust's borrow checker completely (2022)

#49

Post by dtn »

piaste wrote: post #36
withinboredom wrote: post #27

Earlier quoted context omitted.

It isn’t about the “after” it’s about the “before”. For example, if I insert some code that divides by zero “later” but causes some new behavior I’m interested in, that’s what I’m interested in. The divide by zero is annoying, but can be addressed later. If the compiler forced me to check ever integer division wasn’t a divide by zero, that would be annoying in this case. The borrow checker is like this. It forces you…

The parent's point is that there is no separation between "before" or "after", it all ends up in the same artifact. And when you write invalid code, you have no guarantees about the compiled artifact anymore. There is an example of C code (fairly sure I saw it on HN) where violating a UB rule caused an entirely dead piece of code to suddenly be executed, which even made sense after explanation. In the linked article,…

I think you're referring to this one: https://blog.tchatzigiannakis.com/undefined-behavior-can-lit...

Bonus read: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...

Re: Turning off Rust's borrow checker completely (2022)

#50

Post by matesz »

YetAnotherNick wrote: post #44
matesz wrote: post #30

Earlier quoted context omitted.

I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware. However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies. [1] https://github.com/makepad/makepad/

I used actix web, could it be the reason for slow compile?

I am not completely sure, but I think pretty much all frameworks in Rust have complex dependencies and codebase not optimized for fast compile times. You could check out Axum [1], at the first glance seems similar to actix [2]. Both use tokio which is by itself pretty big I think.

Folks at makepad poured enormous effort in keeping dependency graph minimal.

[1] https://github.com/tokio-rs/axum/

[2] https://github.com/actix/actix-web/

Post reply on HN