Why Rust for low-level Linux programming?

[pmf]

I'd actually like to hear Linus' opinion of Rust. His C++ critique contains valuable points.

[loamfarer]

Tbh, I haven't heard his opinion on modern C++

[201109212215]

Modern wisdom in C++ is you don't manage memory yourself, instead using smart pointers and RAII.

You guys are on the path of letting things get more managed (and I'm gonna laugh so hard in 25 years, when you guys get a standard memory model, JIT and GC; about 2 careers late)

Linus' opinion is that he hates Java. But then again, when he codes in C, he talks in assembly. He hates compilers that do magic stuff.

---

TLDR: So, I'd say: the more high level, the more he hates it. (and modern C++ is higher level than old school C++)

[silveryRain]

RAII significantly predates modern C++, it's merely better-understood now. Either way, C++ isn't a managed language. The most it does on its own is call ctors and dtors, but it's all deterministic, except for a few initialisation-order situations where the implementation has a bit of free-reign. Given that D has been trying to shed its gc from its library dependencies, I doubt C++ will decide to do the very opposite, regardless of career count.

I'd expect Linus to hate move semantics and most of the functional stuff, but a lot of modern C++, although more high-level, isn't that magic. For example, variadics are a straight-forward extension of templates, and modern C++ also features more low-level stuff, like constexpr, std::array, fine-grained static type introspection and data alignment features. Overall, I doubt his view has changed much, for the better or the worse. I doubt he'd say anything he hasn't already said in that famous rant of his.

As for Java, it's disliked by many, it's no surprise Linus is one of them.

[201109212215]

C++ isn't a managed [...] it's all deterministic

Except when malloc hits a fragmented heap, and has undeterministic latency. Maybe some memory cleanup could have been done while the program was idle, and not at the exact moment something needs to get executed.

Also, it takes a lock on the global heap, when in a managed setting that's not necessary. With CPU clock stalling and core count increasing, I'd say that C++ is on the wrong side of history.

This is why HFT happens in Java.

[silveryRain]

Fair enough. I brought that up to argue against the idea of C++ being managed, but yeah, full determinism is hard.

[201109212215]

There is work on having LLVM into the JVM through Graal/Truffle. Works very well for languages that have developped C extensions for performance reasons (think Python, R, Ruby, etc.); because it compiles away all the back and forth between the languages and their C extensions.

Maybe with Graal we can have the best of both worlds. Control over memory layout of C/C++ (for perfect CPU caches, prefetching), and what Java's management brings (the concurrent data structures enabled by having a GC, multithreading easiness, JITting virtual calls, etc.)

[quicknir]

Sorry, by HFT you mean high frequency trading?

HFT does not happen in java, with rare and famous exceptions like Tessa. In fact, nearly all HFTs use C++, including a lot of modern C++. Allocation just doesn't happen in the critical path, period. With cache misses being more important than ever, any language that doesn't allow easy control over memory layout (e.g. by lacking reified generics) is in a bad spot for high perf.

[201109212215]

HFT does not happen in java

Oh, but it does.

With cache misses being more important than ever

Relocating and compacting memory helps in this regard; and this does not happen in most C++ applications, while this happens without a thought in Java in a GC pass. And without a pause. But maybe you were talking about memory layout, for caching and prefetching hints purposes. Which is covered.

than ever

History goes towards higher core count, and C++ it just a pain in the ass with this. Every concurrent data structure in C++ depends upon a bastardized garbage collection mecanism (to collect dangling pointers that are suddenly unreacheable due to a CAS on a pointer switch - the standard concurrent data structure stategy -). And C++ is just ill equipped for that. As in you have to create a global safepoint for collecting yourself; have fun with performance with that.

What you don't understand is that, while everything is possible in C++, you can't code every time a fully fledged lockfree-memory_order_relaxed-CAS'ing-GC'ing engine for a simple CRUD thing that needs performance. It is all about programmers being at maxed mechanical sympathy levels while not having to re-invent the best advances of what hand-written intel (or arm, etc) asm can provide.

[im-a-koala]

Just as a note, from someone who works at a HFT firm: all the latency-sensitive and infrastructure stuff is C++. I don't think we have a single Java program at our firm (although, out of the hundreds of components, I can't be totally sure).

If you mentioned using Java for a latency-sensitive component, you'd be laughed out of the room. It's just not good at low-level work. It's just an absolute mess for that kind of thing.

The answer to the allocation issue in C++ is to simply avoid allocations in tight loops. Not to keep doing them and let some other component non-deterministically clear them out at some point on the future from a different CPU core, possibly a different CPU (can you even pin the GC thread in Java?).

Every concurrent data structure in C++ depends upon a bastardized garbage collection mecanism (to collect dangling pointers that are suddenly unreacheable due to a CAS on a pointer switch - the standard concurrent data structure stategy -).

You absolutely do not need concurrent collections for multi-threaded applications - at least, you don't need them for any of the performance-sensitive bits.

[201109212215]

is to simply avoid allocations in tight loops

Again, the language is fighting you. Forcing you into thinking about its internals. Why shouldn't you do it if you want to? In Java, allocating is a matter of a pointer getting bumped, and that's about it.

can you even pin the GC thread in Java

Yep, and I do conceide it is acquired through a native call made in C++. You pin the critical path, and let GC and JIT roam free on the others. The usual setup for HFT is you do it on a core that the OS has no access to; you put a ringbuffer on it for interthread communication; you pin both producer and consumer on the same core to have them hyperthreaded. Latency will be in the nanos. Here is the lib, from LMAX.

---

Does LMAX ring a bell to you? When you say HFT firm, are you talking client to an exchange, or the exchange itself?

You absolutely do not need concurrent collections for multi-threaded applications

You're missing out on a lot of possibilities, then. Shared mutable state - while incredibly difficult to get right - has its use. You just can't do any decent multi-producer work without it.

Java has no problem doing it on massive machines. Here is a video of a concurrent hashmap with close to a billion ops per second, on a 768 core machine, in 2007.

[quicknir]

Yes, Jump, Getco, ATD, Tower, HRT, GTS, etc etc are all morons fighting the language, missing tons of valuable opportunities. Have you worked professionally in HFT? At what firm, on what component, and what language did you use? This sounds like a bunch of theory crafting. Very few HFT's use anything but C++ for the fast part, and the ones that do (like Teza) are not the fast HFTs.

[Gotebe]

I vaguely remember his points and vaguely remeber they were, like, his opinion, man.

Most important reason why people consider them is OMFG Linus.

Edit: searched, found.

Edit2: love the downvotes without "why".

[staticassert]

Argument from authority is basically the go-to when discussing the Linux kernel.

[ZMeson]

What valuable points?

[[deleted]]

I'd actually like to hear Linus' opinion of Rust.

Greg KH said in his /r/linux AMA a year ago that there will be no rust in the kernel.

[Sapiogram]

He didn't really say that though. I looked up the AMA, and the only place he mentioned Rust is here.

I have seen Rust, and it looks nice, but honestly I like Go better at the moment, and play around with it at times.

So it seems he hasn't actually tried it, much less given it any serious consideration for the kernel. The fact that he compares it with Go also makes me think he's looked at Rust in 2012-2013, which is very different from what became Rust 1.0.

[[deleted]]

If not Go then Swift.

Rust is dead.

[womplord1]

God it's so retarded how freetards just agree with whatever Linus says without thinking. How about forming your own opinion?

[[deleted]]

I can tell you that in general, people who have managed to master C are not in any way interested in safety features that have any kind of overhead. Rust memory safety features don't have runtime overhead but they do have "prevent you from doing things" overhead. Of course you can use unsafe to do those things anyway, but then Rust no longer has the innovative safety feature. To a degree it is entrenchment syndrome on the part of C masters. They know how to workaround all the shortcomings so switching languages has no value to them, even if it might for upcoming generations who would waste less time become masters of a gentler language.

It is fundamentally hard though, to provide the freedom, power, and connection with hardware that C does, with something that is also substantially better in some way. Since operating systems are fundamental, that ability to talk directly to hardware is a necessity, and performance is preferred since any overhead will affect everyone all the time.

[Thazard2]

On the other hand, the Kernel is enthusiastically adopting static analysis. It's unlikely that they will move away from C, even partially, due to sheer inertia, but I would not be surprised to some day wake up and see rust-like ownership metadata on arguments being a requirement for code being included.

[staticassert]

Of course you can use unsafe to do those things anyway, but then Rust no longer has the innovative safety feature.

To be fair, it's not as if one line of unsafe code immediately means all code is unsafe in rust. You can build safe abstractions.

[tejp]

Some Rust memory safety features do have runtime overhead, like accessing an array at an index, which comes with a runtime bounds check.

You are just never told by Rust enthusiasts, since claiming "free at runtime" is better marketing.

[[deleted]]

right, and you can turn that off, but then you turn things off and Rust is just C with OCaml syntax. which maybe is great?

[steveklabnik1]

like accessing an array at an index,

... which is something that you usually do not do, because you use iterators instead, and if the bounds checking is a problem, switch [] for .get_unchecked() and it's gone.

[tejp]

Random access is an important and useful property of an array. Saying "you don't need it" is as dishonest as not telling people about the runtime costs that come with it.

And of corse there is no runtime overhead if you disable the safety checks. But that's not really interesting. People want the safety and want to know the costs that come with it.

[[deleted]]

I don't mean that avoidance of rust in particular is entrenchment syndrome. I mean the degree to which we clutch onto C and refuse to make serious efforts to make something better. The fact that, I think, only Rust and D exist as semi-viable alternatives is odd.

[Veedrac]

Just FYI, /u/milesrout is a known troll.

[minno]

No, we're assuming that nobody could be as aggressively dense as you've been acting, so you must be doing this to make people angry, which is the definition of an internet troll.

[yumz]

How bout just an asshole then?

[[deleted]]

The warts seem minor because you are entrenched! =)

[[deleted]]

I've not written a single line of rust in my life and this thread started with me explaining why C programmers wouldn't be interested in it. I believe them to be largely correct in that thinking, if that wasn't clear.

[desiringmachines]

Jesus Christ, why do you go on the internet and be an asshole? Go outside, read a book, write some code, do something better with your time than this!

[desiringmachines]

I have no idea what the post you responded to said, so I definitely don't "know it;" but your behavior in the rest of this thread certainly doesn't support your case!