Originally posted by mmstick
View Post
Has Rust been crafted with all these use cases in mind? Where you could really get rid of smartass helpers and services and just do things in simplest, robust, extremely predictable ways? Say, C could be put into mode it works like a "code generator" similar to "high-level assembler". One could take really precise control over environment. Like very exact memory layout, memory accesses and so on. This is very important in uninitialized system, because one wrong move and everything is FUBAR.
Even -nostdlib is non-standard GCC (and maybe clang?) extension, not something C mandates. Yet that's what makes it possible to use gcc to create truly low-level code like kernels, boot loaders, all kinds of self-sufficient firmwares and so no. And, honestly, it is very convenient when all this crap using same language, using same understanding of e.g. data structures (a bit tricky in C, but C99+ makes it much better). Even usermode things MAY need e.g. custom memory allocator to get best performance. When language pedals huge runtime lib and memory management so much, I'm getting worried about these issues, to say the least. I doubt Mozilla ever cared about something like this.
Even usermode low-level programs sometimes may want to do "wrong" things. Say, one of my programs had to read exact PHYSICAL memory address. This is different from VM address, and takes rather unusual Linux-specific trickery & calculations. This is also Fundamentarlly Wrong Way of accessing mmaped devices. However it has been 100x easier compared to any other options and since it has been read-only access on perfectly RO HW status register, it is safe. And saved me shitload of time compared to e.g. writing kernel driver and so on. I needed just one fucking value from HW status register at certain physical address, to understand how to proceed next. Fortunately most of you would never stumble on this code because it has benen really task-specific stuff for embedded Linux device. I wonder if Rust could handle this at all. Let's assume I want to read unsigned 32-bit value from physical mem address 0xDEADC0DE. I know HW is little-endian and ok with unaligned mem accesses (may or may not be a case, btw). How it supposed to look 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.
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.
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.
C is good in that you virtually never hit the wall with decent C toolchain like GCC. Basically, toolchain like GCC allows one virtually everythnig assembly language permits to do but in more portable and convenient ways (i.e. you only have to break portability when you really have to do something truly HW-specific). Once some lib behaves poorly or gets in the way, one could get rid of it, redefining runtime environment from lowest levels as needed.
That's what allows to use C to create boot loader, firmware, kernels and so on. What is LLVM if we've just been powered on? There is only code and some unused memory. Everything else is have to be created by launched code. There is no notion of "LLVM" or "memory allocation" at this point. Actually, whole memory allocation kind of thing is optional in C. One could use fully static memory allocation instead. This way one could create system which can't run out of memory. At least not by usual means. At most one could provoke "stack overflow" based things, but if there're no malloc, it can't fail either. Very handy in applications like microcontroller firmwares demanding reliability (erm, default Linux attitude about overcommit isn't reliability best friend btw, but only low-level system ppl suspect this :P).
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.
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.
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.
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.
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.
Leave a comment: