11 ms·

For me, the issues with Rust are: - It is not fun but frustrating to work in Rust, and contrary to C, you are limited by the language/compiler on what you can

For me, the issues with Rust are: - It is not fun but frustrating to work in Rust, and contrary to C, you are limited by the language/compiler on what you can do. - building/compiling the kernel is not trivial, and you will add a new huge dependency that you have to deal with to build the kernel for whatever target. Let's suppose you want to build for MIPS, then you need to have Rust supporting MIPS. As an exemple, there is a common package in python that decided to start having their module in Rust instead of C. Now a lot of users of the module are pissed off, with good reason, because you can't build/install the module anymore in a little bit older or non conventional distributions.

wiz21c 5y ago
You are not limited. You are strongly driven. It's different. Painfully different, I agree. But as time goes by, it becomes painful.
choeger 5y ago
The latter point is an important one. Rust as a language for libraries cannot work the same way as rust as a language for applications. For the latter it is OK to depend on the cargo toolchain and be opinionated when it comes to things like dynamic linking. For the former you ideally want support in any common compiler (clang, GCC) and as little dependencies and constraints as possible.
- bsdubernerd 5y ago
  It's also a problem for application themselves IMO. Cargo combined with dependency pinning brings most of the disadvantages of similar environments with centralized package handling: the ease of adding package dependencies increases the number of dependencies themselves very rapidly. Overly-narrow version pinning forces per-package lockstep updates of the various dependencies, which in turn means multiple versions of the same package will get pulled two-or-three levels deep. This ensures each single rust package or update you build is almost a guaranteed rebuild-the-world even with a shared cache dir. And we're not touching the problem of building projects where rust is only part of it: annoying if you want to link other stuff into rust, even more so if you want to do the opposite. I'm following a couple of projects that transitioned to rust, and my experience as a contributor is not stellar. A minimal rust project can take hundreds of mb of disk space just in dependencies, and double that for build space. The solution for some has been providing build bots, but again doesn't help me as a contributor, where I need to be able to rebuild from source. This has on me almost the same effect produced by large projects: I only contribute if I have a large vested interest in the package, otherwise I just avoid because it's time consuming.
  - kortex 5y ago
    Cargo != rust. They are different things for a reason. You don't ever need cargo to manage deps or build, it's just idiomatic to do so. Nothing stopping you from building rust code with manual vcs, rustc, autoconf, and make, just like C.
    - bsdubernerd 5y ago
      Yes, however they're much more tied together as an ecosystem than, say, python and pip.
      - steveklabnik 5y ago
        Notably for this thread, Linux will not be using Cargo.
        kortex 5y ago
        Thanks for clearing that up. Say, you know a lot of things about the rust ecosystem. Do you have any insight into how hypothetical rust driver code would integrate with the rest of the kernel build process? I imagine it would have to use llvm-rustc, or is gccrs ready for the job? Would it be emitting objects that gcc/ld would link against?
        steveklabnik 5y ago
        > Do you have any insight Well, this is a working patch set, so, yes, though I have no direct involvement and haven't read all of it yet. > I imagine it would have to use llvm-rustc, Yes, it uses upstream rustc. > is gccrs ready for the job? Not yet. They're making great progress, but major chunks of the language are still missing. They'll get there. Using upstream rustc isn't a blocker for new code implementing drivers, but it is a blocker for getting into older drivers, or the kernel. The blocker is platform support; or at least, the current largest blocker, and either rustc will gain it, or gccrs will be good enough to compile this codebase. We'll see :) > Would it be emitting objects that gcc/ld would link against? Yep, it emits output that looks like any C compiler's output, you link 'em together and you're good. If you manage to compile the kernel with clang, in theory you can even get cross-language LTO; this is working in Firefox, but I'm not sure if anyone's tried it with the kernel yet or not.
- jhgb 5y ago
  Even if you're compiling dynamic libraries/.so's with a C ABI to be consumed through a C FFI from another language? That seems to be fairly common use case these days, and I don't see those issues there (unless I've missed something, which is of course very possible).
  - zozbot234 5y ago
    Rust itself largely supports this (via the 'cdynlib' project type), however for many Rust crates it either does not make sense to export a pure C API/ABI (i.e. the "crates" are purely generic code that's going to be instantiated with build-specific types, so there's no predefined API beyond that single build) or they just don't bother to enable that use case.
    - jhgb 5y ago
      Well, sure, language-level API (with a type system identical to Rust's) will be a problem, but as long as there's only one compiler, there doesn't seem to be a problem -- yet. I'm mildly wondering if this isn't a chicken and egg problem of sorts.
sanderjd 5y ago
Au contraire on the first point, Rust is super fun. But it should be clear that this is just subjective...
- kortex 5y ago
  Exactly, it's subjective fun. Some people like languages where compiler errors point you in the right direction, expressive features like ergonomic strings, closures, syntactic macros, etc. Other folks are masochists and get their jollies from cryptic errors, segfault debugging, pouring through valgrind traces, and of course manually managing memory. If you aren't suffering, are you really programming? I tease, but not entirely. Sometimes I do in fact enjoy the challenge of C programming. But it's squarely type 2 fun.
  - jstimpfle 5y ago
    The amount of segfault debugging and managing memory is roughly linearly dependent on how much you pretend to not be programming in C but in an object-oriented programming. Those languages give you syntax and/or runtime tools to get away with badly structured programmings (allocating / deallocating stuff like mad, lots of implicit behaviour). C is not like that. It wants you to think and learn how to structure programs (this is transferable knowledge, i.e. it gets much better with time).
viraptor 5y ago
> you are limited by the language/compiler on what you can do You can translate most C to Rust automatically (https://c2rust.com/ https://c2rust.com/) and there's nothing that I'm aware of that can't be done in Rust via unsafe and transmute. (technically some things like specific label jumps can't be translated, but all of those can be rewritten to other constructs) Do you have some specific cases in mind?
- kortex 5y ago
  That's "translate c to rust" in the same way as translating English to Japanese by looking up the kanji for an English word, and replacing it word by word. Why not just generate bindings at that point?
  - viraptor 5y ago
    I'm neither recommending to use it, nor saying it's a good quality result. I'm addressing the "you are limited by the language/compiler on what you can do" part, which for real code is not the case in my experience.
    - kortex 5y ago
      Ah, yeah I see your point. I suppose that's a useful shim to having full Rust interop with a pre-existing C codebase as you convert, or if you have a mature lib you just want to include wholesale in Rust. But yeah bottom line, nowhere does Rustc "stop" you from doing things. Just strongly discourage :)
- dgb23 5y ago
  How feasible is it to refactor an autogenerated unsafe Rust module into a idiomatic one, compared to starting with a new design from scratch?
  - bogeholm 5y ago
    Here’s a blog series about rewriting some classic C in Rust, first unsafely and then safely, and getting some performance wins along the way: http://cliffle.com/p/dangerust/ http://cliffle.com/p/dangerust/
kryptiskt 5y ago
In what way are you more limited by the compiler in Rust than with C? Just write "unsafe" and you're off to the races. Writing correct C is very hard and most definitely not fun. It's like juggling with with 7 balls and if you drop one you'll be shot. C is defined for a weirdo abstract machine that doesn't match what computers really do, and when people apply their intuition and knowledge about computers to their C programs "because C is low-level", it's a crapshoot whether they will trigger undefined behavior and the compiler goes off the rails with wild optimizations. If I designed a low-level language I would enable such optimizations by making it easy to communicate your precise intent to the compiler. Not by making the standard a minefield of undefined behaviors.
- tialaramex 5y ago
  > Just write "unsafe" and you're off to the races. I'm pretty sure I mention this in the LWN comments, but, since it gets repeated so often the contradiction might as well be repeated as well: No. Unsafe Rust only gets to do three things that aren't related to the "unsafe" keyword itself. It can dereference raw pointers, it can access C-style unions, it can mutate global static variables. That's everything. Your C program is free to define x as an array with four elements and then access x[6] anyway - but Rust deliberately cannot do that. Not in Safe Rust, but also not in Unsafe Rust either. Writing "unsafe" doesn't mean "Do this anyway" it only unlocks those three specific things I mentioned, and so sure enough x[6] is still not allowed because that's a buffer overflow. In fact by default the Rust compiler would warn you, if you write unsafe { foo[z] = 0; } that unsafe isn't doing anything useful here and you should remove it. That array dereference either is or, if z is small enough, is not, an overflow, and either way unsafe makes no difference.
  - geofft 5y ago
    Since the conversation is claiming that you can do everything in Rust that you can do in C, I want to provide some counter-nuance. :) I am guessing what people actually mean is that all the operations you want to do can be done via unsafe Rust somehow, and yes, you can do that. But also yes, it is not literally "just write 'unsafe'". You do need to use raw pointers. For instance, if you want to overflow a buffer intentionally, fn main() { let mut a = [1, 2, 3, 4]; let b = [5, 6, 7, 8]; let ptr: *mut i32 = &mut a[0]; unsafe { ptr.add(5).write(999); } println!("{:?}", b); } produces [5, 999, 7, 8] https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=10faea2012496ff7313715827739b3b3 https://play.rust-lang.org/?version=stable&mode=debug&editio... (Note that this is not just extremely platform-specific and compiler-specific about whether a is in front of b or vice-versa, it is straight-up Undefined Behavior because you write past the end of an object... but the equivalent C code is also Undefined Behavior, and subject to the same LLVM optimizations. So if you were happy with the corresponding C code, this is the equivalent Rust.) If you really, really want, you can write your own UnsafeSlice type that does the unsafe stuff internally and exposes the standard indexing operator, which would make foo[z] actually accept arbitrary indices just like in C. But you shouldn't. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c920971c9c8f2d0d5c9324a96b3d03e3 https://play.rust-lang.org/?version=stable&mode=debug&editio... (Among other things, a code reviewer should be suspicious of your use of "unsafe" in the internals of a thing without stating why the higher-level abstraction is safe, and in fact the abstraction is wildly unsafe here, so it's bad style to write code that launders the unsafety, so to speak. In the Rust for Linux patches, there are "SAFETY" comments above each use of "unsafe" defending their logical safety.)
galadran 5y ago
> It is not fun but frustrating to work in Rust. Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now. > add a new huge dependency Sure, but setting up Rust is much much easier than GCC with all the trimmings. > As an exemple, there is a common package in python that decided to start having their module in Rust instead of C. Now a lot of users of the module are pissed off, with good reason, because you can't build/install the module anymore in a little bit older or non conventional distributions. Assuming you are referring to pyca, you are mistaken and there has been a lot of misinformation about the change. Rust support is needed to build the module, but not install it. Pyca works just fine for users without rust and works everywhere rust does. Users on niche CPU architectures which haven't been sold commercially for 15+ years were the only ones impacted.
- brandonmenc 5y ago
  > Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now. How many of those votes were cast by programmers who have actually used the language?
  - jkelleyrtp 5y ago
    That particular metric is derived from "people who use the language outside of work and wish they could use it more at work." The survey doesn't explicitly say "which language do you love?".
    - jcelerier 5y ago
      Everything is more fun when you don't have to interoperate with Joe Coder (who left the company 7 years ago)'s APIs and idiosyncracies
      - tialaramex 5y ago
        Sure, that makes a fine hypothesis. Still though, if you're right, why does Rust report 86.1% love while Python only got 66.7% ? https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved https://insights.stackoverflow.com/survey/2020#technology-mo... Maybe the Python number is smaller because those people are working right? All the Rust programmers are just working on a fun program at home, and Python is a serious language now, you're working the 9-5 with Joe Coder? Haskell is 51.7% though. So, I guess when I wasn't looking Haskell really exploded in boring office environments and I shouldn't expect to see any more hobbyist Haskell projects everywhere... or your hypothesis was just wrong. Maybe it's just that Rust is new and exciting, let's look at what people want to use that they don't now, surely that'll be Rust too and we'll know it's just Hype. Huh, that chart is dominated by Python. 30% of programmers not doing Python wanted to start.
trissylegs 5y ago
I supposed that's why they're writing drivers not crypto libraries. The sample in the article is Binder. Which is only needed for platforms Android supports. Which are all Tier 1 & 2 Rust targets. (As is MIPS too). If you wrote a driver for HW that only appears on 1 or 2 CPU architectures then targeting is less of an issue. I would not be surprised if lots of drivers in Linux only work on x86 anyway.
geofft 5y ago
As I understand it, rustc_codegen_gcc [1], which is being merged into mainline rustc [2], supports building for MIPS. [1] https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc [2] https://github.com/rust-lang/rust/pull/87260 https://github.com/rust-lang/rust/pull/87260 Can you give it a try?
- kam 5y ago
  The default LLVM backend has supported MIPS since before 1.0 as well.
jcranmer 5y ago
Based on Debian's popcon numbers (https://popcon.debian.org/ https://popcon.debian.org/), Rust has support for 99.99% of users. The reality is that if you're using architectures at that level of reality, no one actually supports your architecture, so you're reliant on locally patching software and hoping things work. (Note that MIPS is a Tier 2 support for Rust, which is a commitment to keep it building but does not obligate running tests for every checkin).
- kmeisthax 5y ago
  Indeed. The vast majority of computing environments are covered by existing rustc support. However, people in weird retrocomputing environments are more or less existentially threatened by Rust. In my personal experience (since I wanted to see how big of a problem this is), I looked into bringing up Rust as a cross-compiler for Mac OS 9. This requires a compiler that can emit PowerPC machine code, as well as a toolchain that can handle XCOFF objects and classic Mac OS's strange resource formats (if you ever wondered why Win32 has resources, that's why). Retro68k provides such a toolchain (albeit GCC based), and I wrote a rustc target file to make it spit out XCOFF objects in PowerPC format. Then I got hit with a bunch of llvm assertions about unimplemented functionality in it's XCOFF generator and gave up. Less anecdotally, the ArcaOS people (responsible for trying to keep IBM's freakshow fork of Windows and DOS alive) and TenFourFox both have abandoned attempts to maintain Firefox forks for OS/2 and old Mac OS X (respectively), specifically because of the Quantum update making Rust a requirement to build Firefox. I heard Rust did merge in a GCC backend, which might help some of these retrocomputing projects... but there are platforms out there where the primary (or only) development environment is a proprietary C compiler. (e.g. Classzilla uses Metroworks to provide old Mozilla on Mac OS 9) I'm starting to wonder if some kind of "Rust to C" backend might be useful for these cases... Linux also can't abandon hardware support for some of these weird environments, either. So until and unless Rust-with-GCC can compile on every environment Linux does, we aren't going to see anything more than Rust drivers.
  - deleted 5y ago
    [deleted]
  - 5y ago
bitwize 5y ago
> It is not fun but frustrating to work in Rust, and contrary to C, you are limited by the language/compiler on what you can do. People who have had prior exposure to C tend to find Rust frustrating. People who have not had prior exposure to C tend to find it fun, and an average programmer of this sort can fearlessly write bare-metal code that beats the code of the best C programmers writing in C in safety and rivals it in performance. Systems programming has been fundamentally changed by Rust. It's become as accessible and democratized as web programming, no longer the sole province of a cadre of elite C programmers.
- johnnycerberus 5y ago
  Indeed it was (/s), that's why not even Servo has been shipped. Stop preaching programming languages without results. Because of their benevolent dictators, Linux (Linus Torvalds), Clojure (Rich Hikey), Zig (Andrew Kelley) and Python (Guido van Rossum), the development process of these has been less democratic, and this is precisely why the results are so good. A good design is not a democratic consensus. Look how Rust and C++ ended up, a big pile of complexity. Even Scala 3 was saved with an intervention from Martin Odersky to clean up the language, with huge backlash from the community.
  - fulafel 5y ago
    > not even Servo has been shipped Servo was not meant to ship (at least by Mozilla, when there was paid staff working on Servo), it was a research vessel and Rust components now shipping in Firefox (Stylo, WebRender) started life in Servo.
pjmlp 5y ago
> - It is not fun but frustrating to work in Rust, and contrary to C, you are limited by the language/compiler on what you can do. That depends on the beholder. Developers that grew up in Algol derived languages like Modula, Pascal and Ada, feel Rust brings fresh wind into systems programming, with safety considerations we thought it were lost forever and only partially covered by C++. Then there are the others like Kernighan, that feel that languages like Pascal, sorry Rust, is programming with a straightjacket and better not change anything.

wiz21c 5y ago

You are not limited. You are strongly driven. It's different. Painfully different, I agree. But as time goes by, it becomes painful.

choeger 5y ago

The latter point is an important one. Rust as a language for libraries cannot work the same way as rust as a language for applications. For the latter it is OK to depend on the cargo toolchain and be opinionated when it comes to things like dynamic linking. For the former you ideally want support in any common compiler (clang, GCC) and as little dependencies and constraints as possible.

bsdubernerd 5y ago
It's also a problem for application themselves IMO. Cargo combined with dependency pinning brings most of the disadvantages of similar environments with centralized package handling: the ease of adding package dependencies increases the number of dependencies themselves very rapidly. Overly-narrow version pinning forces per-package lockstep updates of the various dependencies, which in turn means multiple versions of the same package will get pulled two-or-three levels deep. This ensures each single rust package or update you build is almost a guaranteed rebuild-the-world even with a shared cache dir. And we're not touching the problem of building projects where rust is only part of it: annoying if you want to link other stuff into rust, even more so if you want to do the opposite. I'm following a couple of projects that transitioned to rust, and my experience as a contributor is not stellar. A minimal rust project can take hundreds of mb of disk space just in dependencies, and double that for build space. The solution for some has been providing build bots, but again doesn't help me as a contributor, where I need to be able to rebuild from source. This has on me almost the same effect produced by large projects: I only contribute if I have a large vested interest in the package, otherwise I just avoid because it's time consuming.
- kortex 5y ago
  Cargo != rust. They are different things for a reason. You don't ever need cargo to manage deps or build, it's just idiomatic to do so. Nothing stopping you from building rust code with manual vcs, rustc, autoconf, and make, just like C.
  - bsdubernerd 5y ago
    Yes, however they're much more tied together as an ecosystem than, say, python and pip.
    - steveklabnik 5y ago
      Notably for this thread, Linux will not be using Cargo.
      - kortex 5y ago
        Thanks for clearing that up. Say, you know a lot of things about the rust ecosystem. Do you have any insight into how hypothetical rust driver code would integrate with the rest of the kernel build process? I imagine it would have to use llvm-rustc, or is gccrs ready for the job? Would it be emitting objects that gcc/ld would link against?
        steveklabnik 5y ago
        > Do you have any insight Well, this is a working patch set, so, yes, though I have no direct involvement and haven't read all of it yet. > I imagine it would have to use llvm-rustc, Yes, it uses upstream rustc. > is gccrs ready for the job? Not yet. They're making great progress, but major chunks of the language are still missing. They'll get there. Using upstream rustc isn't a blocker for new code implementing drivers, but it is a blocker for getting into older drivers, or the kernel. The blocker is platform support; or at least, the current largest blocker, and either rustc will gain it, or gccrs will be good enough to compile this codebase. We'll see :) > Would it be emitting objects that gcc/ld would link against? Yep, it emits output that looks like any C compiler's output, you link 'em together and you're good. If you manage to compile the kernel with clang, in theory you can even get cross-language LTO; this is working in Firefox, but I'm not sure if anyone's tried it with the kernel yet or not.
jhgb 5y ago
Even if you're compiling dynamic libraries/.so's with a C ABI to be consumed through a C FFI from another language? That seems to be fairly common use case these days, and I don't see those issues there (unless I've missed something, which is of course very possible).
- zozbot234 5y ago
  Rust itself largely supports this (via the 'cdynlib' project type), however for many Rust crates it either does not make sense to export a pure C API/ABI (i.e. the "crates" are purely generic code that's going to be instantiated with build-specific types, so there's no predefined API beyond that single build) or they just don't bother to enable that use case.
  - jhgb 5y ago
    Well, sure, language-level API (with a type system identical to Rust's) will be a problem, but as long as there's only one compiler, there doesn't seem to be a problem -- yet. I'm mildly wondering if this isn't a chicken and egg problem of sorts.

sanderjd 5y ago

Au contraire on the first point, Rust is super fun. But it should be clear that this is just subjective...

kortex 5y ago
Exactly, it's subjective fun. Some people like languages where compiler errors point you in the right direction, expressive features like ergonomic strings, closures, syntactic macros, etc. Other folks are masochists and get their jollies from cryptic errors, segfault debugging, pouring through valgrind traces, and of course manually managing memory. If you aren't suffering, are you really programming? I tease, but not entirely. Sometimes I do in fact enjoy the challenge of C programming. But it's squarely type 2 fun.
- jstimpfle 5y ago
  The amount of segfault debugging and managing memory is roughly linearly dependent on how much you pretend to not be programming in C but in an object-oriented programming. Those languages give you syntax and/or runtime tools to get away with badly structured programmings (allocating / deallocating stuff like mad, lots of implicit behaviour). C is not like that. It wants you to think and learn how to structure programs (this is transferable knowledge, i.e. it gets much better with time).

viraptor 5y ago

> you are limited by the language/compiler on what you can do You can translate most C to Rust automatically (https://c2rust.com/ https://c2rust.com/) and there's nothing that I'm aware of that can't be done in Rust via unsafe and transmute. (technically some things like specific label jumps can't be translated, but all of those can be rewritten to other constructs) Do you have some specific cases in mind?

kortex 5y ago
That's "translate c to rust" in the same way as translating English to Japanese by looking up the kanji for an English word, and replacing it word by word. Why not just generate bindings at that point?
- viraptor 5y ago
  I'm neither recommending to use it, nor saying it's a good quality result. I'm addressing the "you are limited by the language/compiler on what you can do" part, which for real code is not the case in my experience.
  - kortex 5y ago
    Ah, yeah I see your point. I suppose that's a useful shim to having full Rust interop with a pre-existing C codebase as you convert, or if you have a mature lib you just want to include wholesale in Rust. But yeah bottom line, nowhere does Rustc "stop" you from doing things. Just strongly discourage :)
dgb23 5y ago
How feasible is it to refactor an autogenerated unsafe Rust module into a idiomatic one, compared to starting with a new design from scratch?
- bogeholm 5y ago
  Here’s a blog series about rewriting some classic C in Rust, first unsafely and then safely, and getting some performance wins along the way: http://cliffle.com/p/dangerust/ http://cliffle.com/p/dangerust/

kryptiskt 5y ago

In what way are you more limited by the compiler in Rust than with C? Just write "unsafe" and you're off to the races. Writing correct C is very hard and most definitely not fun. It's like juggling with with 7 balls and if you drop one you'll be shot. C is defined for a weirdo abstract machine that doesn't match what computers really do, and when people apply their intuition and knowledge about computers to their C programs "because C is low-level", it's a crapshoot whether they will trigger undefined behavior and the compiler goes off the rails with wild optimizations. If I designed a low-level language I would enable such optimizations by making it easy to communicate your precise intent to the compiler. Not by making the standard a minefield of undefined behaviors.

tialaramex 5y ago
> Just write "unsafe" and you're off to the races. I'm pretty sure I mention this in the LWN comments, but, since it gets repeated so often the contradiction might as well be repeated as well: No. Unsafe Rust only gets to do three things that aren't related to the "unsafe" keyword itself. It can dereference raw pointers, it can access C-style unions, it can mutate global static variables. That's everything. Your C program is free to define x as an array with four elements and then access x[6] anyway - but Rust deliberately cannot do that. Not in Safe Rust, but also not in Unsafe Rust either. Writing "unsafe" doesn't mean "Do this anyway" it only unlocks those three specific things I mentioned, and so sure enough x[6] is still not allowed because that's a buffer overflow. In fact by default the Rust compiler would warn you, if you write unsafe { foo[z] = 0; } that unsafe isn't doing anything useful here and you should remove it. That array dereference either is or, if z is small enough, is not, an overflow, and either way unsafe makes no difference.
- geofft 5y ago
  Since the conversation is claiming that you can do everything in Rust that you can do in C, I want to provide some counter-nuance. :) I am guessing what people actually mean is that all the operations you want to do can be done via unsafe Rust somehow, and yes, you can do that. But also yes, it is not literally "just write 'unsafe'". You do need to use raw pointers. For instance, if you want to overflow a buffer intentionally, fn main() { let mut a = [1, 2, 3, 4]; let b = [5, 6, 7, 8]; let ptr: *mut i32 = &mut a[0]; unsafe { ptr.add(5).write(999); } println!("{:?}", b); } produces [5, 999, 7, 8] https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=10faea2012496ff7313715827739b3b3 https://play.rust-lang.org/?version=stable&mode=debug&editio... (Note that this is not just extremely platform-specific and compiler-specific about whether a is in front of b or vice-versa, it is straight-up Undefined Behavior because you write past the end of an object... but the equivalent C code is also Undefined Behavior, and subject to the same LLVM optimizations. So if you were happy with the corresponding C code, this is the equivalent Rust.) If you really, really want, you can write your own UnsafeSlice type that does the unsafe stuff internally and exposes the standard indexing operator, which would make foo[z] actually accept arbitrary indices just like in C. But you shouldn't. https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c920971c9c8f2d0d5c9324a96b3d03e3 https://play.rust-lang.org/?version=stable&mode=debug&editio... (Among other things, a code reviewer should be suspicious of your use of "unsafe" in the internals of a thing without stating why the higher-level abstraction is safe, and in fact the abstraction is wildly unsafe here, so it's bad style to write code that launders the unsafety, so to speak. In the Rust for Linux patches, there are "SAFETY" comments above each use of "unsafe" defending their logical safety.)

galadran 5y ago

> It is not fun but frustrating to work in Rust. Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now. > add a new huge dependency Sure, but setting up Rust is much much easier than GCC with all the trimmings. > As an exemple, there is a common package in python that decided to start having their module in Rust instead of C. Now a lot of users of the module are pissed off, with good reason, because you can't build/install the module anymore in a little bit older or non conventional distributions. Assuming you are referring to pyca, you are mistaken and there has been a lot of misinformation about the change. Rust support is needed to build the module, but not install it. Pyca works just fine for users without rust and works everywhere rust does. Users on niche CPU architectures which haven't been sold commercially for 15+ years were the only ones impacted.

brandonmenc 5y ago
> Deeply subjective. Rust has been the most loved language on Stack Overflow for 5 years in a row now. How many of those votes were cast by programmers who have actually used the language?
- jkelleyrtp 5y ago
  That particular metric is derived from "people who use the language outside of work and wish they could use it more at work." The survey doesn't explicitly say "which language do you love?".
  - jcelerier 5y ago
    Everything is more fun when you don't have to interoperate with Joe Coder (who left the company 7 years ago)'s APIs and idiosyncracies
    - tialaramex 5y ago
      Sure, that makes a fine hypothesis. Still though, if you're right, why does Rust report 86.1% love while Python only got 66.7% ? https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved https://insights.stackoverflow.com/survey/2020#technology-mo... Maybe the Python number is smaller because those people are working right? All the Rust programmers are just working on a fun program at home, and Python is a serious language now, you're working the 9-5 with Joe Coder? Haskell is 51.7% though. So, I guess when I wasn't looking Haskell really exploded in boring office environments and I shouldn't expect to see any more hobbyist Haskell projects everywhere... or your hypothesis was just wrong. Maybe it's just that Rust is new and exciting, let's look at what people want to use that they don't now, surely that'll be Rust too and we'll know it's just Hype. Huh, that chart is dominated by Python. 30% of programmers not doing Python wanted to start.

trissylegs 5y ago

I supposed that's why they're writing drivers not crypto libraries. The sample in the article is Binder. Which is only needed for platforms Android supports. Which are all Tier 1 & 2 Rust targets. (As is MIPS too). If you wrote a driver for HW that only appears on 1 or 2 CPU architectures then targeting is less of an issue. I would not be surprised if lots of drivers in Linux only work on x86 anyway.

geofft 5y ago

As I understand it, rustc_codegen_gcc [1], which is being merged into mainline rustc [2], supports building for MIPS. [1] https://github.com/antoyo/rustc_codegen_gcc https://github.com/antoyo/rustc_codegen_gcc [2] https://github.com/rust-lang/rust/pull/87260 https://github.com/rust-lang/rust/pull/87260 Can you give it a try?

kam 5y ago
The default LLVM backend has supported MIPS since before 1.0 as well.

jcranmer 5y ago

Based on Debian's popcon numbers (https://popcon.debian.org/ https://popcon.debian.org/), Rust has support for 99.99% of users. The reality is that if you're using architectures at that level of reality, no one actually supports your architecture, so you're reliant on locally patching software and hoping things work. (Note that MIPS is a Tier 2 support for Rust, which is a commitment to keep it building but does not obligate running tests for every checkin).

kmeisthax 5y ago
Indeed. The vast majority of computing environments are covered by existing rustc support. However, people in weird retrocomputing environments are more or less existentially threatened by Rust. In my personal experience (since I wanted to see how big of a problem this is), I looked into bringing up Rust as a cross-compiler for Mac OS 9. This requires a compiler that can emit PowerPC machine code, as well as a toolchain that can handle XCOFF objects and classic Mac OS's strange resource formats (if you ever wondered why Win32 has resources, that's why). Retro68k provides such a toolchain (albeit GCC based), and I wrote a rustc target file to make it spit out XCOFF objects in PowerPC format. Then I got hit with a bunch of llvm assertions about unimplemented functionality in it's XCOFF generator and gave up. Less anecdotally, the ArcaOS people (responsible for trying to keep IBM's freakshow fork of Windows and DOS alive) and TenFourFox both have abandoned attempts to maintain Firefox forks for OS/2 and old Mac OS X (respectively), specifically because of the Quantum update making Rust a requirement to build Firefox. I heard Rust did merge in a GCC backend, which might help some of these retrocomputing projects... but there are platforms out there where the primary (or only) development environment is a proprietary C compiler. (e.g. Classzilla uses Metroworks to provide old Mozilla on Mac OS 9) I'm starting to wonder if some kind of "Rust to C" backend might be useful for these cases... Linux also can't abandon hardware support for some of these weird environments, either. So until and unless Rust-with-GCC can compile on every environment Linux does, we aren't going to see anything more than Rust drivers.
- deleted 5y ago
  [deleted]
- 5y ago

bitwize 5y ago

> It is not fun but frustrating to work in Rust, and contrary to C, you are limited by the language/compiler on what you can do. People who have had prior exposure to C tend to find Rust frustrating. People who have not had prior exposure to C tend to find it fun, and an average programmer of this sort can fearlessly write bare-metal code that beats the code of the best C programmers writing in C in safety and rivals it in performance. Systems programming has been fundamentally changed by Rust. It's become as accessible and democratized as web programming, no longer the sole province of a cadre of elite C programmers.

johnnycerberus 5y ago
Indeed it was (/s), that's why not even Servo has been shipped. Stop preaching programming languages without results. Because of their benevolent dictators, Linux (Linus Torvalds), Clojure (Rich Hikey), Zig (Andrew Kelley) and Python (Guido van Rossum), the development process of these has been less democratic, and this is precisely why the results are so good. A good design is not a democratic consensus. Look how Rust and C++ ended up, a big pile of complexity. Even Scala 3 was saved with an intervention from Martin Odersky to clean up the language, with huge backlash from the community.
- fulafel 5y ago
  > not even Servo has been shipped Servo was not meant to ship (at least by Mozilla, when there was paid staff working on Servo), it was a research vessel and Rust components now shipping in Firefox (Stylo, WebRender) started life in Servo.

pjmlp 5y ago

> - It is not fun but frustrating to work in Rust, and contrary to C, you are limited by the language/compiler on what you can do. That depends on the beholder. Developers that grew up in Algol derived languages like Modula, Pascal and Ada, feel Rust brings fresh wind into systems programming, with safety considerations we thought it were lost forever and only partially covered by C++. Then there are the others like Kernighan, that feel that languages like Pascal, sorry Rust, is programming with a straightjacket and better not change anything.