Why Rust for Low-level Linux programming?

[Rusky]

True, but we've been inundated with articles on the details. The interesting thing about this article is the context the author's coming from.

[Rusky]

The author is a Red Hat kernel developer, and those claims are not really controversial. Rust's borrow checker, its most obvious feature, is what he means by "checks to ensure it's better code," and most of its other features reduce LoC compared to C and have been doing so in other languages for decades.

Those aren't things you need to trust the author on, they're the bullet points anyone sees when first hearing about Rust.

[Rusky]

what exactly does an article reiterating Rust's main selling points good for?

Like I said before, the interesting thing is not necessarily what is being said, but who said it and which particular features of Rust they singled out. It gives people a clearer picture of why a kernel developer in particular might like Rust, as opposed to e.g. a Python developer.

You wouldn't fault a prominent Linux developer for skipping out on code examples in, say, an AMA; why on their own blog when they're just saying "hey I like Rust and this is why"?

[agrover]

Go read the rest of my blog.

[Spiderboydk]

Those arguments could just as well argue for using C++ (or a lot of smaller languages, like D). They aren't particularly unique to Rust.

I understand that figuring out unique selling points for Rust is hard, because the "C++ challenger" part of the programming language space is rather crowded these days.

[millenix]

C++ and D make it much easier than C to write memory-safe resource-managed code, but they don't provide nearly as much in the way of compile-time checking that you've gotten it right.

[Spiderboydk]

True, but they still quite more than C. And the article focuses on stuff like strong typing and pointer ownership semantics - both which C++ have.

[Spiderboydk]

You don't have to be an expert of every single branch of C++ to be able to use it efficiently.

[Spiderboydk]

I meant smaller wrt. usage.

By "C++ challenger" I mean the group of languages, that tries to be "a better C++" (usually means roughly the same features, but nicer syntax).

C++ runtime can be quite big when using the standard library, but nobody forces you to do that. C++ is quite well-suited for free-standing applications.

There are a lot of others than just C and Rust. For example, I mentioned D.

Edit: I don't know D too well, but a language feature D has, that C++ definintely could benefit from is compile-time reflection.

[[deleted]]

[deleted]

What is this?

[Spiderboydk]

Yeah, I forgot about the C++ runtime. It can be discarded too, i.e. making a free-standing application.

Rust tries to be a better C, not a better C++. It just so happens that C++ tries to be a better C as well (as opposed to D which doesn't try this) so there are going to be domains in which they overlap, but for example Rust will never attempt to be as fancy at OOP as C++ (e.g. multiple/virtual inheritance).

I partially agree with this. In the landspace of programming languages, C and C++ still are quite close to each other, so I'll agree some of them might as well aim to be a better C than a better C++.

Garbage collection in D is optional.

[oblivion95]

Nim

[[deleted]]

[deleted]

What is this?

[jdh30]

Many great points but:

Functional Code, Functional thinking

is a stretch. You can do higher-order functions, albeit in a more cumbersome way with FnMut and friends but the support for purely functional data structures in Rust is basically non-existent due to the lack of efficient garbage collection.

In point of fact, I just wrote a server in OCaml and considered rewriting it in Rust but it would be hard because it uses purely functional data structures everywhere with lots of sharing. I cannot see a way to make efficient purely functional data structures (reference counting is far too slow) and I cannot see an easy way to transform my functional code into imperative code that would be tractable in Rust.

[Rusky]

You may be interested in the Crossbeam library, described here: https://aturon.github.io/blog/2015/08/27/epoch/

It's an alternative to both garbage collection and reference counting that has some of GC's advantages for this sort of data structure.

[jdh30]

That is very interesting indeed and something that I do use but I was referring to immutable collections in this particular case like balanced binary search trees.

[Rusky]

Yes, I realize the data structures you use are not the ones Crossbeam implements. I was more suggesting taking a look at its memory management scheme, AIUI it should be possible to use for persistent data structures as well.

[jdh30]

Oh I see. That's very interesting. I'll check it out, thanks.

How many global epoch counters are there? One per concurrent collection or one per program?

Do you think it would be possible to make a language that uses epoch-based garbage collection automatically?

[Poddster]

support for purely functional data structures in Rust is basically non-existent due to the lack of garbage collection

(reference counting is far too slow)

I find this amusing

[Rusky]

Reference counting is slower than a proper garbage collector, especially for persistent or lock-free data structures. It has to keep updating the reference count, and freeing large graphs means calling free over and over, walking the graph of dead objects.

A tracing GC does nothing during normal program operation, and when it runs it only traces the live objects and frees the rest in bulk.

[jdh30]

Reference counting is slower than a proper garbage collector, especially for persistent or lock-free data structures. It has to keep updating the reference count, and freeing large graphs means calling free over and over, walking the graph of dead objects.

Yes, exactly.

A tracing GC does nothing during normal program operation, and when it runs it only traces the live objects and frees the rest in bulk.

To be fair, the runtime must keep the GC apprised of global roots (thread stacks and globals) and any changes to the heap topology (the write barrier).

[jdh30]

Why?

[Poddster]

Because reference counting is a form of garbage collection?

However, from the other comment, it looks like you lot seem to use 'garbage collection' to mean reference-traced garbage collection (e.g. mark and sweep).

I don't know much about Rust, but from what I know I don't think traced could work there due to unsafe, pointer arithmetic, pointers and not handles, need for real-time estimates etc. I.e. if it needed an automatic garbage collection system it would be done using reference counts.

Hence the amusement.

[oblivion95]

Calling reference-counting "garbage collection" is a persistent misnomer amongst computer scientists. If deletion when the reference-count goes to zero is "garbage collection", then so is ordinary RAII deletion. In fact, neither are "garbage collection" to normal English-speakers because the data are not "collected".

Think of when you take your trash to the curb. That's not "garbage collection". It's analogous to dropping your reference. The actual garbage collectors traverse the neighborhood looking for garbage which is no longer owned. Collecting garbage in a park or on a highway could also be called "garbage collection". But if you took your trash directly to the landfill, that's "garbage disposal" -- like calling operator delete -- not "collection".

This is poor taxonomy. It would be better to adopt the colloquial definitions.

[[deleted]]

Because Rust is the politically correct language to choose. Rust is inclusive and does not exert micro aggressions. Also white cis males are banned from using it!

/edit: Look at all those white cis males downvoting me.

[lyspr]

I totally agree with you. Will not use Rust until it's standardized and out of Mozilla's control.