The Latest Progress On Rust For The Linux Kernel

[mdedetrich]

Okay, I'm using rust for at least four years now and never come across any runtime borrow checking that was not opt-in, such as refcell. Do you have anything do back-up your claim?

Also, wasn't oxide designed after-the-fact and is not used within the compiler?

I would also like to see some evidence for this claim. So far the only examples of runtime checks are abstractions that you have to opt into, like RefCell, Mutex, ReadWriteLock etc etc

The reality is that Rust borrow checker was not design as compile time only.

Uh no.... It was designed to be purely compile time. Abstractions like RefCell are implemented differently, i.e. RefCell is implemented in a similar to how a reference counter is implemented in Python (see https://www.reddit.com/r/rust/commen...l_and_refcell/).

The only real interaction RefCel (and other similar abstractions) has with the compile time borrow checker is it casts the type so that it passes the compile time check, (i.e. similar to type casting in Java) otherwise your Rust code wouldn't even compile.

[mastermind]

You know what I spent HOURS learning the language and trying to write on it. I was exploding at the window by the time I got off my machine.
I don't feel like this when writing code in other languages (even C which is extremely simple but hard to master!!!).

Your personal emotional issues do not make Rust a bad language. (get a therapist for that) It is a fine language, which lets programmers offload more work to the compiler in comparison to C/C++ and the like.

[mastermind]

I've spent months learning Rust and the start was similar. Especially since this was before v1.0 I had to use try! macro and other old style uglyness. But now, when I write in ANY other imperative language, I feel dirty. It feels like going from a Tesla car to some ancient black cloud spewing diesel car from the eastern block.

LOL. Try using Haskell or even Idris for a while and you will feel the same (or worse) about even Rust.

Even "safe" languages like Go have this, at minimum nulls at worst race conditions. As soon as you get into something more serious it shows up really quick.

I wouldn't call Go safe at all. The only reasons this hackish poorly designed language is so popular is that: 1. It makes it very easy for programmers to deal with some pain points common in languages such as C/C++ (e.g. concurrency) 2. Developed, supported and promoted by one of the largest corps in the world.

[mdedetrich]

LOL. Try using Haskell or even Idris for a while and you will feel the same (or worse) about even Rust.

I wouldn't call Go safe at all. The only reasons this hackish poorly designed language is so popular is that: 1. It makes it very easy for programmers to deal with some pain points common in languages such as C/C++ (e.g. concurrency) 2. Developed, supported and promoted by one of the largest corps in the world.

True, but until those languages have zero cost abstractions you can kinda forget about them being used in the same space as Rust. Purely functional languages rely a lot on GC's in order to have good ergonomics. You can see this whenever Rust tries to implement some nice feature (typically borrowed from Haskell/Scala/Idris etc) and then they hit some wall.

Higher Kinded Types is the most obvious example of a feature that people try to get into Rust but doing so often involves creating a lot of silent boxing which is against one of the core design principles of Rust.

Agree with your points about Go, I would also add that Go makes package management trivial since its just reference to git repos.

[quaz0r]

all your ESL are belong to this comment section

[mastermind]

True, but until those languages have zero cost abstractions you can kinda forget about them being used in the same space as Rust.

Indeed, I was not implying that those languages (as they are implemented now) are appropriate for the whole scope of applications where Rust is usable, only that they are far superior to Rust in terms allowing for better management of complexity.

This is largely a matter of implementation though, the fact that Haskell et al rely on GC a lot does not mean that this is the only way to make use of such approaches. There is a lot of interesting research in the direction of making the approach less costly. (e.g. GRIN compiler) There are even some practical examples, e.g. Ur - here is its desctription:

Ur is a programming language in the tradition of ML and Haskell, but featuring a significantly richer type system. Ur is functional, pure, statically typed, and strict. Ur supports a powerful kind of metaprogramming based on row types.

Ur/Web is Ur plus a special standard library and associated rules for parsing and optimization. Ur/Web supports construction of dynamic web applications backed by SQL databases. The signature of the standard library is such that well-typed Ur/Web programs "don't go wrong" in a very broad sense. Not only do they not crash during particular page generations, but they also may not:

• Suffer from any kinds of code-injection attacks
• Return invalid HTML
• Contain dead intra-application links
• Have mismatches between HTML forms and the fields expected by their handlers
• Include client-side code that makes incorrect assumptions about the "AJAX"-style services that the remote web server provides
• Attempt invalid SQL queries
• Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers

This type safety is just the foundation of the Ur/Web methodology. It is also possible to use metaprogramming to build significant application pieces by analysis of type structure. For instance, the demo includes an ML-style functor for building an admin interface for an arbitrary SQL table. The type system guarantees that the admin interface sub-application that comes out will always be free of the above-listed bugs, no matter which well-typed table description is given as input.

The Ur/Web compiler also produces very efficient object code that does not use garbage collection. These compiled programs will often be even more efficient than what most programmers would bother to write in C. For example, the standalone web server generated for the demo uses less RAM than the bash shell. The compiler also generates JavaScript versions of client-side code, with no need to write those parts of applications in a different language.

The implementation of all this is open source.

[cl333r]

Why did this comment even get 1 "like"?
Was it the author himself perhaps? It's completely nonsense. That is not how the Rust borrow checker works. A 5 minute tutorial in Rust would have shown that. Hint: the Rust borrow checker is run at *compile time* not *run time*.

Here's the clueless Rust fanboy, angry and stupid.

This will in fact panic, at runtime. This is what RefCell does: it enforces Rust’s borrowing rules at runtime, and panic!s if they’re violated. This allows us to get around another aspect of Rust’s mutability rules.

https://doc.rust-lang.org/1.8.0/book/mutability.html

[cl333r]

You should try Rust one day instead of talking BS. The borrow checker is static and works at compile time, it doesn't do anything at runtime (and is not linked into the binary)

Another stupid Rust fanboy.

This will in fact panic, at runtime. This is what RefCell does: it enforces Rust’s borrowing rules at runtime, and panic!s if they’re violated. This allows us to get around another aspect of Rust’s mutability rules.

https://doc.rust-lang.org/1.8.0/book/mutability.html

[cl333r]

That would be bad indeed. Luckily, that's not even close to how the borrow checker works.

And the 3rd stupid Rust fanboy.

This will in fact panic, at runtime. This is what RefCell does: it enforces Rust’s borrowing rules at runtime, and panic!s if they’re violated. This allows us to get around another aspect of Rust’s mutability rules.

https://doc.rust-lang.org/1.8.0/book/mutability.html

[bachchain]

And the 3rd stupid Rust fanboy.

https://doc.rust-lang.org/1.8.0/book/mutability.html

My apologies. I assumed you would be able to understand the difference between a language construct and a type in the standard library. I'm also not entirely sure why you're linking to a 5 year old version of the book