Making The Case For Using Rust At Low Levels On Linux Systems

[computerquip]

The argument isn't about the existence of a C ABI, which is very hard to perform in comparison to Rust. The issue that C++ poses on the system is bad enough that there is a section in the Gentoo wiki dedicated to it. Ever tried updating a Gentoo installation after a GCC update and having all the C++ software on the system break because libstdc++ was updated? Anyone who maintains packages for a Linux distribution or uses Gentoo will understand that any time GCC is updated, you have to also re-release all your C++ packages, and the same goes for when a C++ library is updated, all packages relying on that library have to be rebuilt and re-released.

With Rust software, you do not even need to have the Rust standard library installed. Rust software is linked statically at compile-time, and thus will never break because a package was updated on the system, unless that package is a dependency to Rust that is dynamically linked. Cargo then allows you to perform application-wide LTO on your build to optimize it and reduce binary size greatly.

That is a completely different message than the first.
That said, you don't *actually* have to recompile those packages.
The very wiki page you're talking about explains it better than I can: https://wiki.gentoo.org/wiki/Upgrading_GCC#ABI_changes

[mmstick]

Uh, you said, "C++ really isn't good for software libraries either due to C++ not having a stable exportable interface." Unless I'm taking advantage of the verbatim quote? Your argument is that C++ doesn't have, or isn't capable of, a stable exportable interface which is bologna.

The argument isn't about the existence of a C ABI, which is very hard to perform in comparison to Rust. The issue that C++ poses on the system is bad enough that there is a section in the Gentoo wiki dedicated to it. Ever tried updating a Gentoo installation after a GCC update and having all the C++ software on the system break because libstdc++ was updated? Anyone who maintains packages for a Linux distribution or uses Gentoo will understand that any time GCC is updated, you have to also re-release all your C++ packages, and the same goes for when a C++ library is updated, all packages relying on that library have to be rebuilt and re-released.

With Rust software, you do not even need to have the Rust standard library installed. Rust software is linked statically at compile-time, and thus will never break because a package was updated on the system, unless that package is a dependency to Rust that is dynamically linked. Cargo then allows you to perform application-wide LTO on your build to optimize it and reduce binary size greatly.

[mmstick]

Some few objections & observations:
1) Low level code is not supposed to be large and complex in first place. If it is not a case, it is not a language to fix but project management I guess.

There are a lot of projects that have to be large and complex while also being written in a low level language. The Linux kernel, for example, would largely benefit from being rewritten in Rust. We could easily drastically reduce the amount of SLOC and design APIs that are more generic, and yet just as fast, much easier.

2) Strong types are double edged sword and could be annoying as well.

Rust's types are not annoying in the least. If you actually try developing software with it, it's easy to hate languages that do not provide the same level of guarantees and finesse that Rust's type system is able to pull off.

3) Furthermore, all low-level runtime environments are written in C. They are using C types anyway. Be it syscalls, low/mid level libs or something, you have to call it unless you're in mood to write whole OS and usermode from scratch (good luck with it, come back in ~10 years and show your superb achievements).

Rust's libcore interfaces directly with LLVM primitives, which is much lower level than C, and very much like a modern version of Assembly. It is what allows Rust to achieve C-like performance today, and better-than-C performance in some areas, and will allow better-than-C performance across the board in the future. SIMD support and other CPU-specific instructions can be exposed to Rust through the LLVM primitives.

4) Dealing with conversion of types is absolutely last thing one may want in low level program. Whatever, Pascal/Delphi are pain to use for low level things due to the fact virtually all OSes are using C as native implementation language. Therefore all low level calls are using C types all over place and doing conversions is no fun and even gives birth to whole new class of mistakes and errors.

Rust does not perform any sort of type conversions at runtime. Everything, including C types, are desugared to LLVM primitives and then converted to machine code. If you've ever actually tried to work with C libraries inside Rust, it is actually quite easy and convenient. It does not open up a 'whole class of mistakes and errors' in the least. The main downside is just knowing the standard quirks of C libraries such as what different error codes returned by C functions actually mean, as C libraries do not have a concept of sum types like Option and Result.

5) Sometimes it could be handy to be able to enter kernel side. A bit of kernel superpower does not hurts on low level. But wait, I could only use C to do that. Needless to say learning 2 different languages is a bit ridiculous and redundant, right?

The beauty of Rust is that you can do both programming lower level than C with libcore, and programming higher level than C++ with libstd. There's no need to have two different languages if you keep everything in Rust, which supports both low level and high level programming without hindering either's capabilities.

6) Writing perfect programs is cool. However there're thousands of C progs and libs. If you're McLeod, you would not mind rewriting everything in Rust. Mortals are really better off changing mere 20 lines of code in lib or prog which "almost does the thing". C got huge advantage here, you could literally write few lines of code yourself, while reusing the rest. Rust seems to be bad at it. It lacks bindings to most libs. Could it be used to create "universally reusable" lib like C, callable from almost any language around? Ability to create new building bricks which are reusable by others matters.

It's actually not that hard to convert existing C libraries into Rust. There was a recent talk at the last Rust convention about this very subject. The Zopfli library from Google was translated to Rust piece by piece, one function at a time. She wrote Rust unit tests along the way to not only ensure that the Rust replacements were tested, but also that the C functions could be tested too.

Although it can be argued that rewriting from scratch using idiomatic Rust is more ideal and can lead to faster implementations, large projects can easily start by just adding rust to the build system and converting one function at a time.

As for bindings to C libraries, there are tools to automatically generate bindings from C headers so this really isn't a problem. Providing a binding on Crates.io is best if you also go a step farther and wrap the C bindings up so that the library is more idiomatic to Rust, such as adding error handling.

7) Mozilla have shown us what they're up to, by enforcing signatures on extensions, with no way around. Relying on toolchain from someone like THIS looks shortsighted and hazardous to say the least. Especially when they pedal "package manager" theme. Wouldn't they introduce signatures on their package manager as well, with Mozilla being the only central authority deciding what is "good" and what is "bad", with no means of override?

How does this relate to Rust? Do you even know how Cargo works? It would be impossible for them to require signatures to Cargo crates when Cargo merely pulls libraries directly from git URLs. The Crates website is just an index of crates that conveniently map versions to precise git commits.

8) I'm really fine with installing somelib and somelib-dev using my system-wide package manager. I really do not want some third-party crap to bring some files and execute code in my system. It screws up OS management and brings winduz-like practices on my head.

You clearly do not understand how or what Cargo is. Cargo is not a system package manager like APT, DNF, or pacman. Cargo does not manage packages on your operating system. Cargo is a build tool that manages crate dependencies automatically. Rust software still has to be packaged into debs and rpms and PKGBUILDs when distributing Rust software to users on their platforms.

[computerquip]

We all know that C++ can export a C interface. That isn't what the argument is referring to.

Uh, you said, "C++ really isn't good for software libraries either due to C++ not having a stable exportable interface." Unless I'm taking advantage of the verbatim quote? Your argument is that C++ doesn't have, or isn't capable of, a stable exportable interface which is bologna.

[mmstick]

C++ can also export a C interface. I made a small library for IRC showing how this can be done here, which uses Boost ASIO and cppformat while providing a C interface: https://github.com/computerquip/cqirc/blob/master/

We all know that C++ can export a C interface. That isn't what the argument is referring to.

[computerquip]

Sorry to butt in like this but I read the remark you're responding to as that the software written with low level languages shouldn't be large and complex; not the actual language itself.

Yes. The confusing part here is that low-level language can refer to various things and needs a point of reference to understand what it actually means. A large project in assembly is difficult and hard to maintain, one reason we created higher-level languages. A large project in C or C++ is quite common and viable. Unless I'm still misunderstanding something.

[F1esDgSdUTYpm0iy]

This doesn't make any sense. The whole reason we created higher-level languages is because machine code is too complex and large to write large projects with.

Sorry to butt in like this but I read the remark you're responding to as that the software written with low level languages shouldn't be large and complex; not the actual language itself.

[computerquip]

I hate topics like this... lots of misinformation.

C++ isn't good for anything. There's good reason why everyone is moving away from C++ and using other languages instead, and why both Google and Mozilla decided to attempt to ditch their usage of C++ for Go and Rust respectively. C++ really isn't good for software libraries either due to C++ not having a stable exportable interface. That's a good reason why everyone writes their software libraries in C, and why all languages implement a C ABI as the foreign interface of choice. Rust, likewise, has the ability to export Rust libraries with a C interface, and many languages are now starting to take advantage of that, including Python and Ruby.

C++ can also export a C interface. I made a small library for IRC showing how this can be done here, which uses Boost ASIO and cppformat while providing a C interface: https://github.com/computerquip/cqirc/blob/master/

Some few objections & observations:
1) Low level code is not supposed to be large and complex in first place. If it is not a case, it is not a language to fix but project management I guess.

This doesn't make any sense. The whole reason we created higher-level languages is because machine code is too complex and large to write large projects with.

3) Furthermore, all low-level runtime environments are written in C. They are using C types anyway. Be it syscalls, low/mid level libs or something, you have to call it unless you're in mood to write whole OS and usermode from scratch (good luck with it, come back in ~10 years and show your superb achievements).

This is blatantly false. D writes its runtime in D. Rust writes its core in Rust: https://github.com/thestinger/rust-c...ee/master/core

4) Dealing with conversion of types is absolutely last thing one may want in low level program. Whatever, Pascal/Delphi are pain to use for low level things due to the fact virtually all OSes are using C as native implementation language. Therefore all low level calls are using C types all over place and doing conversions is no fun and even gives birth to whole new class of mistakes and errors.

There is no "type conversion". Machine code doesn't understand what a type is outside of an address and contents of a register. C does not pass "C types", it simply passes data that the language simply has to provide to the user in a way that's fit for the language. It has to do this anyways in order to be a systems programming language. For instance, in Rust, https://doc.rust-lang.org/book/ffi.html
The inter)face may be dangerous according to the Rust guide but that doesn't mean it's something that's specific to C.

5) Sometimes it could be handy to be able to enter kernel side. A bit of kernel superpower does not hurts on low level. But wait, I could only use C to do that. Needless to say learning 2 different languages is a bit ridiculous and redundant, right?

I have no idea what you're talking about. You do not enter "the kernel side" just because you're using a low-level language. You enter "the kernel side" when you write a driver module or writing part of the kernel. Also, C is not specific to the creation of a kernel. Haiku, which is based on BeOS, uses C++. There's another kernel actually written in rust here: https://github.com/redox-os/redox

6) Writing perfect programs is cool. However there're thousands of C progs and libs. If you're McLeod, you would not mind rewriting everything in Rust. Mortals are really better off changing mere 20 lines of code in lib or prog which "almost does the thing". C got huge advantage here, you could literally write few lines of code yourself, while reusing the rest. Rust seems to be bad at it. It lacks bindings to most libs. Could it be used to create "universally reusable" lib like C, callable from almost any language around? Ability to create new building bricks which are reusable by others matters.

C lacks things like generic containers, a decent benchmark/profiler library, and so forth. Using your logic, even if C was the most flawed language in the world, we should still use it because it has libraries... which is easily debatable. In addition, Rust can already export using a C interface, just like C++ and D can.

7) Mozilla have shown us what they're up to, by enforcing signatures on extensions, with no way around. Relying on toolchain from someone like THIS looks shortsighted and hazardous to say the least. Especially when they pedal "package manager" theme. Wouldn't they introduce signatures on their package manager as well, with Mozilla being the only central authority deciding what is "good" and what is "bad", with no means of override?

8) I'm really fine with installing somelib and somelib-dev using my system-wide package manager. I really do not want some third-party crap to bring some files and execute code in my system. It screws up OS management and brings winduz-like practices on my head.

This is ridiculous, it's not even funny. You're saying the only possible trusted source for anything is your package manager. Why do you trust your package manager so much, compared to the next package manager? Hell, in OpenSUSE, the package manager has completely fucked my setup several times due to various dependency issues. The only person executing the code is you, it's your job to verify that everything is safe, whether it's the package manager or... well, this other package manager you don't trust for some reason.

And not all libraries should be slapped into the system library directory. I'd honestly appreciate if we *didn't* do that all the fucking time since I might want to modify the library for my specific purpose and not rely on some generic build configuration provided and forced onto me. We have no way of distributing applications with our package manager with modified libraries unless we statically linked them (which a lot of GPL-based libraries actively prevent) which, in 2016, is frankly ridiculous and embarrassing.

[SystemCrasher]

Some few objections & observations:
1) Low level code is not supposed to be large and complex in first place. If it is not a case, it is not a language to fix but project management I guess.

2) Strong types are double edged sword and could be annoying as well.

3) Furthermore, all low-level runtime environments are written in C. They are using C types anyway. Be it syscalls, low/mid level libs or something, you have to call it unless you're in mood to write whole OS and usermode from scratch (good luck with it, come back in ~10 years and show your superb achievements).

4) Dealing with conversion of types is absolutely last thing one may want in low level program. Whatever, Pascal/Delphi are pain to use for low level things due to the fact virtually all OSes are using C as native implementation language. Therefore all low level calls are using C types all over place and doing conversions is no fun and even gives birth to whole new class of mistakes and errors.

5) Sometimes it could be handy to be able to enter kernel side. A bit of kernel superpower does not hurts on low level. But wait, I could only use C to do that. Needless to say learning 2 different languages is a bit ridiculous and redundant, right?

6) Writing perfect programs is cool. However there're thousands of C progs and libs. If you're McLeod, you would not mind rewriting everything in Rust. Mortals are really better off changing mere 20 lines of code in lib or prog which "almost does the thing". C got huge advantage here, you could literally write few lines of code yourself, while reusing the rest. Rust seems to be bad at it. It lacks bindings to most libs. Could it be used to create "universally reusable" lib like C, callable from almost any language around? Ability to create new building bricks which are reusable by others matters.

7) Mozilla have shown us what they're up to, by enforcing signatures on extensions, with no way around. Relying on toolchain from someone like THIS looks shortsighted and hazardous to say the least. Especially when they pedal "package manager" theme. Wouldn't they introduce signatures on their package manager as well, with Mozilla being the only central authority deciding what is "good" and what is "bad", with no means of override?

8) I'm really fine with installing somelib and somelib-dev using my system-wide package manager. I really do not want some third-party crap to bring some files and execute code in my system. It screws up OS management and brings winduz-like practices on my head.

[liam]

Are you suggesting we grant safespaces to people opposed to safespaces?

In a limited sense, yes.