9 ms·

I think we should just evaluate Rust based on its merits. Ignore fanboys and ignore the opposite as well. In other words, Rust is just another tool. Regard it

I think we should just evaluate Rust based on its merits. Ignore fanboys and ignore the opposite as well. In other words, Rust is just another tool. Regard it as one without subjective emotions either way. Be constructive, don't only look for faults, but also ways how to overcome them. But don't close your eyes from them either. Acknowledging weaknesses is the first step to improvement. Some possible questions and measures to consider below. I'm sure there's a lot more to add on this list. 1) Stability. Other than for development, unstable kernels are a no go. Can possible negative effects be mitigated? 2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues. 3) Are there showstoppers for kernel builds? Interoperability, build performance, architectures unsupported by Rust, etc. If so, could these be mitigated? Conversely, is there something positive Rust could provide? 4) How does it affect runtime performance? Average case. Bloat issues? Any pathologic cases? Any benefits? 5) What other unexpected it brings on the plate? Both benefits and disadvantages. For example, could Rust types also be used to catch errors other than memory related, like invalid states? 6) <Your consideration here or above>

StavrosK 7y ago
Isn't this exactly what they're doing?
- vardump 7y ago
  I hope so, that's the impression I got. Other than that, I hope the discussion here has less of that "Playstation vs. Xbox" tone we're all familiar with.
gmueckl 7y ago
In this vain, what about other options like beterC (a very capable runtime-less D subset)? What about allowing Ada into the kernel? The fact they are focussing their evaluation on rust only is already an indication that they are playing the fanboy game to some extent. There are other languages out there that improve over C and can be used for systems programming.
- vardump 7y ago
  Although we were talking about Rust here, I'd love to see those evaluated and compared between each other as well. This is nothing away from BetterC and other languages. If anything, this could open up ways to using languages other than C in kernel development. That said, I don't think there's room for more than maybe two languages for the critical kernel components even in the long run. Not because of technical limitations, but human ones.
- roca 7y ago
  Someone would need to make the case for them. AFAIK neither Ada nor BetterC prevent memory safety bugs like Rust does... for example it appears neither of them prevent use-after-free of dynamic heap allocations, a pretty common sort of exploitable memory safety bug.
  - gmueckl 7y ago
    All that Rust does wrt to that is to enforce reference counting overhead. That has well known issues and limitations and is not very attractive, either.
    - jhomedall 7y ago
      The only types in the Rust standard library that do reference counting are `Rc` and `Arc` (which are both implemented in Rust). Borrow checking is done statically.
      - gmueckl 7y ago
        But borrow checking doesn't cover heap allocations.
        jcranmer 7y ago
        Yes it does. Borrow guarantees that the lifetime of the borrower does not exceed the lifetime can provide. Heap allocations have a lifetime--the start of a Box<> is the call to malloc, and the end is the call to free. Borrow checking prevents you from using the value after the free.
mehrdadn 7y ago
> 6) <Your consideration here or above> "Would C++ fare better or worse than Rust on these fronts?" is the question I would have.
- mikekchar 7y ago
  I was a C++ developer a long time ago (I've actually used CFront as a professional -- that's how long ago ;-) ). C++ is a fine language. You can write good code in C++. I've worked on large projects that were extremely stable and easy to work with. It can be done. The one thing I will say about C++ from long ago was that you needed to be skilled at C++. You needed to understand it and you needed to know how to write code that wasn't going to cause you problems in the future. You also needed to work on a team that allowed you to use your skill. The language is so different now that it's practically I different language so I don't know how much of that still remains, but I guess quite a lot. I've been doing some Rust recently. I like Rust. There are bits I think still need work, but generally it's a fine language. The biggest difference I see between it and C++ from long ago is that Rust helps you a lot. It's very convenient and friendly. It also scolds me when I do something stupid, which I appreciate. However, I don't really feel like I need to know less than I did as a C++ programmer. With Rust, it helps you, but if you start causing problems for yourself you can be in for a world of hurt trying to understand what the compiler doesn't like. It will catch that thing that slips by you, which is awesome, but you still have to understand what's going on under the hood. So in my book, it feels very much like C++ with a super friendly and super powerful linter. I mean it's really, really nice, but I don't think you could just hire random people off the street and give them a Rust compiler and say "This will protect you". So to answer your question (finally), I think you won't really fare much better or worse, but the journey seems a little bit more relaxed with Rust.
  - roca 7y ago
    The failure modes of "can't get code to compile" and "something weird and possibly exploitable could happen at runtime" may both be frustrating to developers, but they're worlds apart in practice. Looking at it from the point of view of a kernel maintainer evaluating submissions, the former is not your problem --- in fact it keeps the bad code from ever coming to your attention --- but the latter creates ongoing problems for you.
amelius 7y ago
Rust is still a research language. And using more than one language for a kernel/drivers, is that really a good idea? Anyone trying to fix/debug things in the kernel now has to learn Rust.
- adwn 7y ago
  > Rust is still a research language. It's not. Rust is being used for production systems by several companies, so it hardly counts as a "research language". > Anyone trying to fix/debug things in the kernel now has to learn Rust. Wrong again. If a driver for some SD card reader is written in Rust, then you won't come in contact with this if you're working on the IPv6 subsystem.
  - masklinn 7y ago
    > It's not. Rust is being used for production systems by several companies, so it hardly counts as a "research language". I don't know that Rust has ever been a research language in the first place, maybe they mean "in development", as in pre-stability?
    - fulafel 7y ago
      There's some history in this Twitter thread: https://twitter.com/graydon_pub/status/958192076209897472 https://twitter.com/graydon_pub/status/958192076209897472 The 2005-ish "one man side project" and "searching for its niche" phases do sound researchy. Interesting quote: "Funny enough, the zero cost obsession really wasn't me. I was ok paying some runtime costs. We just got overrun by C++ folks :P"
- gnode 7y ago
  I don't think it's fair to say Rust is still a research language any more than it's fair to see the ongoing evolution of C++ makes it a research language. Rust is being used to engineer production software (parts of Firefox, Tor and Microsoft Azure), and its development is aimed mostly at practical and ergonomic issues, rather than experimental or esoteric features. I agree that there's a cost to introducing a new language to a codebase. On the other hand, there's a cost to being stuck with only C, which manifests as security vulnerabilities and high cognitive overhead for want of better abstractions. I believe the Linux maintainers are taking a sensible and conservative stance here in allowing use of Rust, but not allowing Linux to depend on it.
pcwalton 7y ago
> 2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues. We actually have an objective experiment to answer this question: the rust-afl trophy case [1]. It is remarkable how different it is from the upstream AFL trophy case, which tests C and C++ code [2]. An enormous fraction of the AFL trophy case uncovered potentially-exploitable memory safety issues; by contrast, very few of the Rust issues were, with most being safe panics. [1]: https://github.com/rust-fuzz/trophy-case https://github.com/rust-fuzz/trophy-case [2]: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/
geofft 7y ago
> 1) Stability. Other than for development, unstable kernels are a no go. Can possible negative effects be mitigated? If by "stability" you mean "crash-proof-ness," I think there's no particular inherent reason Rust code is going to be more crash-prone than C, especially since basically the whole purpose of the language is increased stability. One notable shortcoming is that Rust doesn't currently have a fallible allocations API nor widespread support in common libraries for using it, so under memory pressure, if kmalloc fails, your only choice is to panic (Rust panic, i.e., unwind, maybe BUG() and kill the current thread). See https://github.com/fishinabarrel/linux-kernel-module-rust/issues/148 https://github.com/fishinabarrel/linux-kernel-module-rust/is... for some discussion. If by "stability" you mean interface stability, the Rust project has made great progress in the last year or two at stabilizing everything needed to write code that doesn't use the full standard library / link to a libc that can open files etc. See e.g. https://github.com/fishinabarrel/linux-kernel-module-rust/issues/41 https://github.com/fishinabarrel/linux-kernel-module-rust/is... . > 2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues. Agree that in practice we're going to need to test this. But all of Rust's safety features (type system that handles null pointers, borrow checker, bounds-checked arrays, safe iterators so you don't need to bounds-check in the first place, etc.) work fine in kernelspace. > 3) Are there showstoppers for kernel builds? Interoperability, build performance, architectures unsupported by Rust, etc. If so, could these be mitigated? Build performance is a bit slow, but it's not as bad as userspace Rust because you inherently can't use that many crates and you generally don't want to be linking third-party code anyway - everything should be in the kernel tree. For architecture support see https://github.com/fishinabarrel/linux-kernel-module-rust/issues/112 https://github.com/fishinabarrel/linux-kernel-module-rust/is... . Notably, all the architectures that have kernels by the major distros (I checked RHEL, Fedora, Debian, Ubuntu, SUSE, Android, Oracle, and Arch) should work. One challenge for interoperability is that most kernels in the real world are built with GCC, and rustc itself emits code using LLVM. The most common way of binding C code is using rust-bindgen, which uses libclang to parse C headers; even if you're not using bindgen, I believe you're still using LLVM's idea of C layout with #[repr(C)] structs and extern "C" functions. It's possible that kernels are built with particular GCC -m options that change the ABI (e.g., regparm) or GCC plugins (e.g., randstruct); if those aren't supported in compatible ways by LLVM / clang, then it's hard to write modules that load into an existing kernel. But, of course, if the question is to build new kernels with components in Rust, one workable restriction is to say that the C parts need to be built with Clang. There is good support for building the Linux kernel with Clang, and there are production Android models with Clang-built kernels. > 4) How does it affect runtime performance? Average case. Bloat issues? Any pathologic cases? Any benefits? There's a team that did some investigation on a prototype, and found that runtime performance was comparable, but binary size wasn't too great: https://mssun.me/assets/ares19securing.pdf https://mssun.me/assets/ares19securing.pdf (The prototype driver uses lots of unsafe code, but it's a good proof of concept for what ought to be achievable.) I think we can claw back binary size with some focused work. > 5) What other unexpected it brings on the plate? Both benefits and disadvantages. For example, could Rust types also be used to catch errors other than memory related, like invalid states? One thing I'm very curious about is whether you can use a battle-tested third-party ASN.1 implementation (for example) instead of writing your own ASN.1 implementation in the kernel. (In fact the kernel has multiple ASN.1 implementations!) Another useful thing is to use Rust's linear(ish) type system to prevent TOCTTOU bugs when checking userspace pointers, by making it very explicit when you're dereferencing the same address more than once. A little closer to memory safety: Rust's Send and Sync traits make it easy to ensure you're not unsafely using data across threads (i.e., you're forced to pay attention to shared data and are unlikely to get into a big-kernel-lock situation), and you can use the typesystem to get a better and safer interface to things like RCU pointers. RCU requires that you be in a read-side critical section to read pointers; there's no concept of locking a specific pointer, being in one lets you read any RCU-protected pointer (as long as it's of the same RCU flavor, and confusing RCU flavors did lead to a use-after-free vulnerability recently!). In Rust it's pretty easy to have a Guard object on the stack that uses RAII to enter/exit the critical section, and ensure that you pass a reference to your Guard to any dereference of an RCU pointer type.
lone_haxx0r 7y ago
<Your consideration here or above> I guess that as more languages are added to a project, it gets harder and harder to understand and develop. You need to spend time learning yet another tool to be comfortable with inspecting the code and understanding the inner workings of it.
cryptonector 7y ago
I don't think (2) needs any additional demonstration. Any experienced C programmer who just reads the Rust book should conclude that Rust >> C. (3) can be a problem: Rust does not (yet) make it possible to define an ABI for Rust, which means that only by using external representations (C repr) can Rust code interoperate with non-Rust code. However, that's not a very big deal right now. As to (1), ignoring toolchain stability (which affects C as well), the main concern would be (3) (see above). Re (4), that's a legitimate question for sure. (My suspicion is that Rust will improve performance in general, mostly due to forcing better (public and internal) API designs on programmers. However, that's just hunch.) Re (5), benefits. I think mostly it will bring this benefit: cleaner APIs. Obviously that won't apply to Linux's ABI to user-land, since that's not to be broken, but it could benefit the kernel in-tree. Re (5), disadvantages, I think mainly it's the learning curve.
- dmitrygr 7y ago
  > Any experienced C programmer who just reads the Rust book should conclude that Rust >> C. Mighty nice of you to speak for all of us C programmers, so let me continue the story where you left off: The programer then tries it, gets annoyed with complaints about ownership in cases where the programer clearly did nothing wrong, and goes back to getting work done in C, putting the rust book into his long-overflowing "cute toys to play with later" pile
  - pixel_fcker 7y ago
    “I know this code I’ve just written is safe” is the opening verse for the thousands of security vulnerabilities we see every year.
    - dmitrygr 7y ago
      I know i can implement an up-tree or a doubly-linked-list safely just fine. I do not need to have a straightjacket put on me that prevents me from doing that. If you wish to use it, do. If you want to force your employees to do it, feel free. Telling everyone else how to live their lives and do their jobs is a dick move.

StavrosK 7y ago

Isn't this exactly what they're doing?

vardump 7y ago
I hope so, that's the impression I got. Other than that, I hope the discussion here has less of that "Playstation vs. Xbox" tone we're all familiar with.

gmueckl 7y ago

In this vain, what about other options like beterC (a very capable runtime-less D subset)? What about allowing Ada into the kernel? The fact they are focussing their evaluation on rust only is already an indication that they are playing the fanboy game to some extent. There are other languages out there that improve over C and can be used for systems programming.

vardump 7y ago
Although we were talking about Rust here, I'd love to see those evaluated and compared between each other as well. This is nothing away from BetterC and other languages. If anything, this could open up ways to using languages other than C in kernel development. That said, I don't think there's room for more than maybe two languages for the critical kernel components even in the long run. Not because of technical limitations, but human ones.
roca 7y ago
Someone would need to make the case for them. AFAIK neither Ada nor BetterC prevent memory safety bugs like Rust does... for example it appears neither of them prevent use-after-free of dynamic heap allocations, a pretty common sort of exploitable memory safety bug.
- gmueckl 7y ago
  All that Rust does wrt to that is to enforce reference counting overhead. That has well known issues and limitations and is not very attractive, either.
  - jhomedall 7y ago
    The only types in the Rust standard library that do reference counting are `Rc` and `Arc` (which are both implemented in Rust). Borrow checking is done statically.
    - gmueckl 7y ago
      But borrow checking doesn't cover heap allocations.
      - jcranmer 7y ago
        Yes it does. Borrow guarantees that the lifetime of the borrower does not exceed the lifetime can provide. Heap allocations have a lifetime--the start of a Box<> is the call to malloc, and the end is the call to free. Borrow checking prevents you from using the value after the free.

mehrdadn 7y ago

> 6) <Your consideration here or above> "Would C++ fare better or worse than Rust on these fronts?" is the question I would have.

mikekchar 7y ago
I was a C++ developer a long time ago (I've actually used CFront as a professional -- that's how long ago ;-) ). C++ is a fine language. You can write good code in C++. I've worked on large projects that were extremely stable and easy to work with. It can be done. The one thing I will say about C++ from long ago was that you needed to be skilled at C++. You needed to understand it and you needed to know how to write code that wasn't going to cause you problems in the future. You also needed to work on a team that allowed you to use your skill. The language is so different now that it's practically I different language so I don't know how much of that still remains, but I guess quite a lot. I've been doing some Rust recently. I like Rust. There are bits I think still need work, but generally it's a fine language. The biggest difference I see between it and C++ from long ago is that Rust helps you a lot. It's very convenient and friendly. It also scolds me when I do something stupid, which I appreciate. However, I don't really feel like I need to know less than I did as a C++ programmer. With Rust, it helps you, but if you start causing problems for yourself you can be in for a world of hurt trying to understand what the compiler doesn't like. It will catch that thing that slips by you, which is awesome, but you still have to understand what's going on under the hood. So in my book, it feels very much like C++ with a super friendly and super powerful linter. I mean it's really, really nice, but I don't think you could just hire random people off the street and give them a Rust compiler and say "This will protect you". So to answer your question (finally), I think you won't really fare much better or worse, but the journey seems a little bit more relaxed with Rust.
- roca 7y ago
  The failure modes of "can't get code to compile" and "something weird and possibly exploitable could happen at runtime" may both be frustrating to developers, but they're worlds apart in practice. Looking at it from the point of view of a kernel maintainer evaluating submissions, the former is not your problem --- in fact it keeps the bad code from ever coming to your attention --- but the latter creates ongoing problems for you.

amelius 7y ago

Rust is still a research language. And using more than one language for a kernel/drivers, is that really a good idea? Anyone trying to fix/debug things in the kernel now has to learn Rust.

adwn 7y ago
> Rust is still a research language. It's not. Rust is being used for production systems by several companies, so it hardly counts as a "research language". > Anyone trying to fix/debug things in the kernel now has to learn Rust. Wrong again. If a driver for some SD card reader is written in Rust, then you won't come in contact with this if you're working on the IPv6 subsystem.
- masklinn 7y ago
  > It's not. Rust is being used for production systems by several companies, so it hardly counts as a "research language". I don't know that Rust has ever been a research language in the first place, maybe they mean "in development", as in pre-stability?
  - fulafel 7y ago
    There's some history in this Twitter thread: https://twitter.com/graydon_pub/status/958192076209897472 https://twitter.com/graydon_pub/status/958192076209897472 The 2005-ish "one man side project" and "searching for its niche" phases do sound researchy. Interesting quote: "Funny enough, the zero cost obsession really wasn't me. I was ok paying some runtime costs. We just got overrun by C++ folks :P"
gnode 7y ago
I don't think it's fair to say Rust is still a research language any more than it's fair to see the ongoing evolution of C++ makes it a research language. Rust is being used to engineer production software (parts of Firefox, Tor and Microsoft Azure), and its development is aimed mostly at practical and ergonomic issues, rather than experimental or esoteric features. I agree that there's a cost to introducing a new language to a codebase. On the other hand, there's a cost to being stuck with only C, which manifests as security vulnerabilities and high cognitive overhead for want of better abstractions. I believe the Linux maintainers are taking a sensible and conservative stance here in allowing use of Rust, but not allowing Linux to depend on it.

pcwalton 7y ago

> 2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues. We actually have an objective experiment to answer this question: the rust-afl trophy case [1]. It is remarkable how different it is from the upstream AFL trophy case, which tests C and C++ code [2]. An enormous fraction of the AFL trophy case uncovered potentially-exploitable memory safety issues; by contrast, very few of the Rust issues were, with most being safe panics. [1]: https://github.com/rust-fuzz/trophy-case https://github.com/rust-fuzz/trophy-case [2]: http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/

geofft 7y ago

> 1) Stability. Other than for development, unstable kernels are a no go. Can possible negative effects be mitigated? If by "stability" you mean "crash-proof-ness," I think there's no particular inherent reason Rust code is going to be more crash-prone than C, especially since basically the whole purpose of the language is increased stability. One notable shortcoming is that Rust doesn't currently have a fallible allocations API nor widespread support in common libraries for using it, so under memory pressure, if kmalloc fails, your only choice is to panic (Rust panic, i.e., unwind, maybe BUG() and kill the current thread). See https://github.com/fishinabarrel/linux-kernel-module-rust/issues/148 https://github.com/fishinabarrel/linux-kernel-module-rust/is... for some discussion. If by "stability" you mean interface stability, the Rust project has made great progress in the last year or two at stabilizing everything needed to write code that doesn't use the full standard library / link to a libc that can open files etc. See e.g. https://github.com/fishinabarrel/linux-kernel-module-rust/issues/41 https://github.com/fishinabarrel/linux-kernel-module-rust/is... . > 2) Security is often what Rust is expected to bring on the table. So is Rust actually more secure in the environment kernel requires? This could be tested by "clean-room" reimplementing something that is historically known to have many security issues. Agree that in practice we're going to need to test this. But all of Rust's safety features (type system that handles null pointers, borrow checker, bounds-checked arrays, safe iterators so you don't need to bounds-check in the first place, etc.) work fine in kernelspace. > 3) Are there showstoppers for kernel builds? Interoperability, build performance, architectures unsupported by Rust, etc. If so, could these be mitigated? Build performance is a bit slow, but it's not as bad as userspace Rust because you inherently can't use that many crates and you generally don't want to be linking third-party code anyway - everything should be in the kernel tree. For architecture support see https://github.com/fishinabarrel/linux-kernel-module-rust/issues/112 https://github.com/fishinabarrel/linux-kernel-module-rust/is... . Notably, all the architectures that have kernels by the major distros (I checked RHEL, Fedora, Debian, Ubuntu, SUSE, Android, Oracle, and Arch) should work. One challenge for interoperability is that most kernels in the real world are built with GCC, and rustc itself emits code using LLVM. The most common way of binding C code is using rust-bindgen, which uses libclang to parse C headers; even if you're not using bindgen, I believe you're still using LLVM's idea of C layout with #[repr(C)] structs and extern "C" functions. It's possible that kernels are built with particular GCC -m options that change the ABI (e.g., regparm) or GCC plugins (e.g., randstruct); if those aren't supported in compatible ways by LLVM / clang, then it's hard to write modules that load into an existing kernel. But, of course, if the question is to build new kernels with components in Rust, one workable restriction is to say that the C parts need to be built with Clang. There is good support for building the Linux kernel with Clang, and there are production Android models with Clang-built kernels. > 4) How does it affect runtime performance? Average case. Bloat issues? Any pathologic cases? Any benefits? There's a team that did some investigation on a prototype, and found that runtime performance was comparable, but binary size wasn't too great: https://mssun.me/assets/ares19securing.pdf https://mssun.me/assets/ares19securing.pdf (The prototype driver uses lots of unsafe code, but it's a good proof of concept for what ought to be achievable.) I think we can claw back binary size with some focused work. > 5) What other unexpected it brings on the plate? Both benefits and disadvantages. For example, could Rust types also be used to catch errors other than memory related, like invalid states? One thing I'm very curious about is whether you can use a battle-tested third-party ASN.1 implementation (for example) instead of writing your own ASN.1 implementation in the kernel. (In fact the kernel has multiple ASN.1 implementations!) Another useful thing is to use Rust's linear(ish) type system to prevent TOCTTOU bugs when checking userspace pointers, by making it very explicit when you're dereferencing the same address more than once. A little closer to memory safety: Rust's Send and Sync traits make it easy to ensure you're not unsafely using data across threads (i.e., you're forced to pay attention to shared data and are unlikely to get into a big-kernel-lock situation), and you can use the typesystem to get a better and safer interface to things like RCU pointers. RCU requires that you be in a read-side critical section to read pointers; there's no concept of locking a specific pointer, being in one lets you read any RCU-protected pointer (as long as it's of the same RCU flavor, and confusing RCU flavors did lead to a use-after-free vulnerability recently!). In Rust it's pretty easy to have a Guard object on the stack that uses RAII to enter/exit the critical section, and ensure that you pass a reference to your Guard to any dereference of an RCU pointer type.

lone_haxx0r 7y ago

<Your consideration here or above> I guess that as more languages are added to a project, it gets harder and harder to understand and develop. You need to spend time learning yet another tool to be comfortable with inspecting the code and understanding the inner workings of it.

cryptonector 7y ago

I don't think (2) needs any additional demonstration. Any experienced C programmer who just reads the Rust book should conclude that Rust >> C. (3) can be a problem: Rust does not (yet) make it possible to define an ABI for Rust, which means that only by using external representations (C repr) can Rust code interoperate with non-Rust code. However, that's not a very big deal right now. As to (1), ignoring toolchain stability (which affects C as well), the main concern would be (3) (see above). Re (4), that's a legitimate question for sure. (My suspicion is that Rust will improve performance in general, mostly due to forcing better (public and internal) API designs on programmers. However, that's just hunch.) Re (5), benefits. I think mostly it will bring this benefit: cleaner APIs. Obviously that won't apply to Linux's ABI to user-land, since that's not to be broken, but it could benefit the kernel in-tree. Re (5), disadvantages, I think mainly it's the learning curve.

dmitrygr 7y ago
> Any experienced C programmer who just reads the Rust book should conclude that Rust >> C. Mighty nice of you to speak for all of us C programmers, so let me continue the story where you left off: The programer then tries it, gets annoyed with complaints about ownership in cases where the programer clearly did nothing wrong, and goes back to getting work done in C, putting the rust book into his long-overflowing "cute toys to play with later" pile
- pixel_fcker 7y ago
  “I know this code I’ve just written is safe” is the opening verse for the thousands of security vulnerabilities we see every year.
  - dmitrygr 7y ago
    I know i can implement an up-tree or a doubly-linked-list safely just fine. I do not need to have a straightjacket put on me that prevents me from doing that. If you wish to use it, do. If you want to force your employees to do it, feel free. Telling everyone else how to live their lives and do their jobs is a dick move.