Next steps for Rust in the kernel(lwn.net)
lwn.net
Next steps for Rust in the kernel
https://lwn.net/SubscriberLink/908347/da67a5162d1bc4a3/
263 comments
Linus hates Perl?
Heck, so my secret project of slowly replacing every Perl script in the kernel with C might even get approved...
Heck, so my secret project of slowly replacing every Perl script in the kernel with C might even get approved...
The dislike of Perl in this context is that it's a write-only language. See Titus' recent talk about "Software Engineering languages" for some thoughts about that.
https://www.youtube.com/watch?v=yA_wUiNuhSc
C isn't a good software engineering language but it might be better than Perl. Or in this context, maybe not.
https://www.youtube.com/watch?v=yA_wUiNuhSc
C isn't a good software engineering language but it might be better than Perl. Or in this context, maybe not.
[deleted]
That sounds like what we heard about Scala 10 years ago until complexity started to bite, and now that language is in a free fall and its parent company in financial distress...
Given the projects where Rust is already in use (and has been for several years at this point), I don't think that is a concern.
Which projects?
The Firefox repo is 27% C++, 14% C, and 9.5% Rust - https://4e6.github.io/firefox-lang-stats/
AWS wrote Firecracker which powers AWS Lamba - https://github.com/firecracker-microvm/firecracker
Cloudflare just replaced nginx with an in-house reverse proxy written in Rust called Pingora (not yet open source)
Facebook rewrote Mercurial in Rust to help scale their monorepo (called Mononoke, now part of their EdenSCM project)
Dropbox rewrote their sync client in Rust, and they wrote their block storage service (Magic Pocket) in it.
A significant portion of Google's new Fuchsia OS is written in Rust, and it is currently powering Nest devices
NPM's backend is written in rust
curl can now use Rust's hyper library for making http requests
> A significant portion of Google's new Fuchsia OS is written in Rust
User-space part only. Kernel is C++.
User-space part only. Kernel is C++.
Scala isn’t that complex unless you try to pretend it’s Haskell.
To me, Scala's issue is identity crisis, not complexity. Some of the community wanted to pretend it is Haskell, and others wanted a better version of Java. But if you want a JVM functional language, why not Clojure? If you want a better Java, why not Kotlin (or update Java). Scala is squeezed by more consistent alternatives on all sides.
I don't think that Rust has the same issue: it has a clear (albeit potentially complex) vision of what it is trying to do, which is distinct from C and more consistent than C++.
I don't think that Rust has the same issue: it has a clear (albeit potentially complex) vision of what it is trying to do, which is distinct from C and more consistent than C++.
I think "better Haskell on JVM" (in contrast to "worse Haskell") is a good identity for Scala to have. (Please note that this is an intentional hyperbole.)
Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well.
Examples of this "better Haskell" are https://typelevel.org/cats-effect/ and https://zio.dev/ .
All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...).
None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure).
I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.
Of course, there are areas where Haskell is stronger than Scala (hint: modularity, crucial for good Software Engineering, is not one of them). And Scala has its own way of doing things, so just imitating Haskell won't work well.
Examples of this "better Haskell" are https://typelevel.org/cats-effect/ and https://zio.dev/ .
All together, Scala may be a better choice for you if you want to do Pure Functional Programming. And is definitely less risky (runs on JVM, Java libraries interop, IntelliJ, easy debugging, etc...).
None of the other languages you mentioned are viable in this sense (if also you want a powerful type system, which rules out Clojure).
I agree that Rust's identity is pretty clear: a modern language for use cases where only C or C++ could have been used before.
I don't now what situation was Scala in 10 years ago. But the situation it is now couldn't be further from "free fall".
It is _the_ language where most of the Functional Programming in the industry takes place (that's not to say that Haskell, F#, OCaml or Clojure are bad, they just aren't as widely used). And that also means that there are lot of open job positions available.
I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern-style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).
https://typelevel.org/cats-effect/
https://zio.dev/
The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.
The tooling available is from good to great and Scala is big enough that there are good libraries for typical (if not vast majority of stuff) and Java libs as a reliable fallback.
It is _the_ language where most of the Functional Programming in the industry takes place (that's not to say that Haskell, F#, OCaml or Clojure are bad, they just aren't as widely used). And that also means that there are lot of open job positions available.
I like FP and Scala comes with some awesome libraries for concurrent/async programming like Cats Effect or ZIO. Good choice for creating modern-style micro-services to be run in the cloud (or even macro-services, Scala has a powerful module system, so it's made to handle large codebases).
https://typelevel.org/cats-effect/
https://zio.dev/
The language, the community and customs are great. You don't have to worry about nulls, things are immutable by default, domain modelling with ADTs and patter matching is pure joy.
The tooling available is from good to great and Scala is big enough that there are good libraries for typical (if not vast majority of stuff) and Java libs as a reliable fallback.
Scala is not that bad. I'd take it over java any day.
And you'd be wrong!
Jokes aside, even Scala proper sees itself as an experimental testing ground more than a complete idea realized. That's why dotty became Scala 3, with a huge amount of backtracking.
It pushed the state of the art across the JVM landscape, but I think it's lost its purpose with Java, Kotlin, and Clojure around.
Jokes aside, even Scala proper sees itself as an experimental testing ground more than a complete idea realized. That's why dotty became Scala 3, with a huge amount of backtracking.
It pushed the state of the art across the JVM landscape, but I think it's lost its purpose with Java, Kotlin, and Clojure around.
Scala's purpose is, at least to me, pretty clear: Functional programming (ranging up to Pure FP) on the JVM with a powerful type system.
That's just something that Java, Kotlin, nor Clojure don't offer. And there is significant demand for Scala (and its pupose) in the industy (it just not may be as huge as Java or other more mainstream languages).
That's just something that Java, Kotlin, nor Clojure don't offer. And there is significant demand for Scala (and its pupose) in the industy (it just not may be as huge as Java or other more mainstream languages).
Any historical background for the reference of Perl by Torvalds?
Perl is notorious for being "write only".
As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects.
I feel qualified to say such things as I've worked on a billion-line perl codebase before.
As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects.
I feel qualified to say such things as I've worked on a billion-line perl codebase before.
Shudder in horror....
"Booking.com uses the Perl programming language heavily across its entire technical infrastructure." - https://medium.com/booking-com-development/a-faster-perl-run...
Dad, let's go home. Please.
> Perl is notorious for being "write only".
> As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects.
Perl gets quite unfairly picked on here, to the point where it's basically a meme. It's not like, just to pick a somewhat popular language, Ruby doesn't provide plenty of ways to write completely unreadable code that can only be understand by running it through irb, if even then.
I agree that there is plenty of bad Perl code out there, but there's plenty of bad code in any language that achieves general popularity for a time. Disciplined use can produce perfectly clear and readable code and the module system is perfectly adequate for separation of concerns.
The language does give you an absurd amount of rope to hang yourself with though. If I were managing a large Perl project today I'd have an extremely restrictive style guide and would enforce as much of it as possible via pre-commit hooks.
> I feel qualified to say such things as I've worked on a billion-line perl codebase before.
For a language that permits such densely expressive code, that's appalling. I'm so sorry.
> As in: keeping it clean and well structured is impossible and the impressive flexibility of the language is huge downside on larger projects.
Perl gets quite unfairly picked on here, to the point where it's basically a meme. It's not like, just to pick a somewhat popular language, Ruby doesn't provide plenty of ways to write completely unreadable code that can only be understand by running it through irb, if even then.
I agree that there is plenty of bad Perl code out there, but there's plenty of bad code in any language that achieves general popularity for a time. Disciplined use can produce perfectly clear and readable code and the module system is perfectly adequate for separation of concerns.
The language does give you an absurd amount of rope to hang yourself with though. If I were managing a large Perl project today I'd have an extremely restrictive style guide and would enforce as much of it as possible via pre-commit hooks.
> I feel qualified to say such things as I've worked on a billion-line perl codebase before.
For a language that permits such densely expressive code, that's appalling. I'm so sorry.
I’ve worked on a Perl codebase written by a good programmer and had the pleasure of starting the port over to Python.
This was surprisingly doable? Marshaling/unmarshaling Perl objects into Python ones isn’t difficult these days, and you can run Perl code via FFI so the transition can be piecemeal.
I have no opinions on Perl as a language (some constructs / patterns felt a bit hard to think about, but I’m far from an expert), but ultimately it’s a high level language and has been left behind tooling wise to another high level language, so it’s time to move. For us, one motivator was that having a large legacy Perl codebase (even one running well for years) hurt recruiting.
This was surprisingly doable? Marshaling/unmarshaling Perl objects into Python ones isn’t difficult these days, and you can run Perl code via FFI so the transition can be piecemeal.
I have no opinions on Perl as a language (some constructs / patterns felt a bit hard to think about, but I’m far from an expert), but ultimately it’s a high level language and has been left behind tooling wise to another high level language, so it’s time to move. For us, one motivator was that having a large legacy Perl codebase (even one running well for years) hurt recruiting.
_one billion lines of Perl_? Wow
I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java. (I wouldn't be surprised if they still had sizable amounts of Perl in dark corners).
I can imagine corporate Java codebases can end up in the billion LOC as well. I mean it MIGHT be easier to read, or easier to find developers for...
I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.
I feel like - opinion, not based in fact, I've never worked on any codebase >1M LOC - the only way you can keep a codebase like that maintainable is by very strict code style and architecture rules - e.g. no functional programming, no feature X, no feature Y, strict code style rules, strict architecture rules, etc.
Ha ha no. Sorry to disappoint :)
Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it.
This isn’t an indictment of Java. Just resume driven design.
Personal experience. We have some java code from 15-17 yrs back. About the time “design patterns” and all the other “pattern” stuff was big in everyones mind. It’s a mess of abstraction for simple tasks. Couple all that with the fact that class instantiating is possible via reflection and at this point people maintaining it have kinda given up. It works - don’t touch it.
This isn’t an indictment of Java. Just resume driven design.
That's why I left Java 5 years (after like a 12 year career in it) ago and plan on never getting another Java job. It's just making classes have "some" kind of use no matter what the task is, there's no coding to solve problems, it's coding to make structure.
To be fair, I’ve seen this in c++ as well. Building an entire structure of classes like “java” and then using “design patterns” on those abstractions. All to implement a simple 7 step socket communication protocol. It was a “wtf is going on here moment”?
I was also part of it. I did my own share of - well if we design it this way then we can have a second "type" that does X with the same interface. And it just keeps on iterating like that. It's still a useful pattern, but often at least in my own case, overused for really trivial stuff.
Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.
Programmers are highly trained like to see the world as if everything can be cast the same way. While that IS a good way to see a large variety of software problems, when you isolate down to a companies' use cases, it quickly goes away in the pragmatic sense. It then becomes something the company is paying for because they chose Java and Java developers like that sort of thing.
There's a spirograph guy in the corner, the only one left that knows perl, lurking out and trying to entice people with its merits.
Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff.
To be fair if I walked away from Rust for a year I'd probably be similarly lost.
Long ago I worked primarily in perl and ... yeesh, I recognize maybe 30% of it when looking, and that's the directly-c-adjacent stuff.
To be fair if I walked away from Rust for a year I'd probably be similarly lost.
I still will reach for Perl for the occasional quick one-of text-processing application, but I do spend a lot of time in perldoc when I do.
With Java? I usually think of Perl as a glue language, like bash scripting. Java would not be my choice to glue components together.
Nah, Perl can be a perfectly fine applications language. Some things get kind of ugly with it (object-orientation is notoriously hacky and there are two different approaches to classes that take inverse (literally) approaches to how to represent the objects in terms of Perl’s scalars, arrays and maps. It does suffer a bit from being an early mover so there are questionable choices like the fact that library code is traditionally installed system-wide so good luck if application A needs library v3 an application B needs v2 and v2 and v3 have some subtle incompatibility, but Perl is no less capable than Python and arguably more capable than PHP, both of which have plenty of applications written in them.
Perl was the primary application-layer language at Amazon. It was used for most things that didn't need to be in a low-level language for performance or other reasons (for those, C++ was used instead).
>> I suspect that person worked at Amazon. They at one point had gigantic amounts of Perl before they started slowly replacing it with Java.
The Amazon retail website (amazon.com and related versions for various countries) used the Perl Mason templating system (https://masonbook.houseabsolute.com/) to allow various teams to build web site components in a performant and secure way.
It worked quite well since it ran quickly and isolated components so that only one small change could be made without breaking other components.
The Amazon retail website (amazon.com and related versions for various countries) used the Perl Mason templating system (https://masonbook.houseabsolute.com/) to allow various teams to build web site components in a performant and secure way.
It worked quite well since it ran quickly and isolated components so that only one small change could be made without breaking other components.
Could have been worse. Could all have been on one line.
I've often found I could work around the "write only" mantra using perltidy. I pass other peoples code to perltidy with the flags that match my style, make changes, then pass it back through perltidy to match the author as close as I can. I try to encourage others to do the same.
Bilion lines?
What, how?
Thats bigger than windows linux llvm chromium and 5 other compilers combined according to google
What, how?
Thats bigger than windows linux llvm chromium and 5 other compilers combined according to google
Commentary on that was made at the time.
Linux is a pretty small codebase compared to most proprietary codebases in large companies to be fair though.
Linux is a pretty small codebase compared to most proprietary codebases in large companies to be fair though.
Yeah, this – it's easy to forget that infrastructure code (Linux, libc, openssl, ...) really is the tip of the iceberg. Industrial codebases are often at least an order of magnitude bigger; really, that shouldn't surprise us: there are so many problems to be solved, it should be unsurprising that the specific outweighs the general.
There once was a time when the only common things you could expect to be present on a Linux system were the good old `sh` (not `bash`) and a more or less old version of `perl`.
The commands supported by `sh` are... let's keep it at "fossilized from somewhere in the 80s", and so the only alternative was perl which has a ... history of being not exactly user-friendly to code for.
The commands supported by `sh` are... let's keep it at "fossilized from somewhere in the 80s", and so the only alternative was perl which has a ... history of being not exactly user-friendly to code for.
Eh? Bash predates Linux by a couple of years. I don’t remember any early Linux system — my frame of reference begins in 1994 — without bash as the default shell.
The common Debian expectation to this day is to keep acting like you only had POSIX shell features aka /bin/sh [1]. You may use /bin/bash if you like though.
[1] https://www.debian.org/doc/debian-policy/ch-files.html#s-scr...
[1] https://www.debian.org/doc/debian-policy/ch-files.html#s-scr...
That may be their expectation stylistically, but the first Debian release shipped[1] with bash as the default shell. I’m not aware of them ever having shipped the original Bourne shell. Your claim — that I was responding to - was that on early Linux systems you might only find the Bourne shell but not bash. That simply was not the case.
1 - http://archive.debian.org/debian-archive/debian/dists/buzz/m...
1 - http://archive.debian.org/debian-archive/debian/dists/buzz/m...
Linux was built out initially with a hard coded call to bash
This is wrong, initially Linux was quite literally a bash kernel
Perls big moto of TMTOWTDI always bugged me and I thought it was more of a negative than a plus which led to it being known for write-only code.
Rust is not so different from Perl in this regard — there are many ways to do practically everything. Do you want an argument that implements a trait? Cool, just use a generic with a trait bound (either specified as `<T: Trait>` or `<T> where T: Trait`). Or type the argument as `impl Trait`. Or take a `Box<dyn Trait>`.
I'm not particularly fluent in Rust, but at least several of those express meaningful differences in what you're doing, not just how. Eg are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return.
Whilst there are differences, that's not one of them. What decides whether the caller still has something is whether you passed it by reference.
fn eat(food: Edible) just takes an actual Edible. Afterwards the food is gone, perhaps this function stashed it somewhere, or gave it away, but you don't have it any more† so maybe it was Dropped (destroyed)
fn sniff(food: &Edible) -> Smell this time our function only wants an immutable reference to the Edible. The food isn't changed in any way by this predicate, it's still yours, and now you also know how it Smells.
fn lick(food: &mut Edible) -> Review but this function modifies the Edible via the exclusive reference. You still have the food, and now you've got a Review, but the food may be changed, perhaps irreversibly by being licked.
† If Edible is Copy then Rust will just copy it, so the caller still has it, types which are Copy are typically small, and they can't implement Drop, so if they were destroyed nothing happens anyway. An integer is Copy, a String isn't Copy, and neither is a File, or a network Socket, or whatever. You can make your own types Copy, if you want, and if they qualify.
fn eat(food: Edible) just takes an actual Edible. Afterwards the food is gone, perhaps this function stashed it somewhere, or gave it away, but you don't have it any more† so maybe it was Dropped (destroyed)
fn sniff(food: &Edible) -> Smell this time our function only wants an immutable reference to the Edible. The food isn't changed in any way by this predicate, it's still yours, and now you also know how it Smells.
fn lick(food: &mut Edible) -> Review but this function modifies the Edible via the exclusive reference. You still have the food, and now you've got a Review, but the food may be changed, perhaps irreversibly by being licked.
† If Edible is Copy then Rust will just copy it, so the caller still has it, types which are Copy are typically small, and they can't implement Drop, so if they were destroyed nothing happens anyway. An integer is Copy, a String isn't Copy, and neither is a File, or a network Socket, or whatever. You can make your own types Copy, if you want, and if they qualify.
> What decides whether the caller still has something is whether you passed it by reference.
I was referring to the `Box<dyn Trait>` one, as I'm at least 90% sure `Box<X>` passes a owned, dynamically-allocated X by reference (ie, Box<X> is a pointer to X).
I was referring to the `Box<dyn Trait>` one, as I'm at least 90% sure `Box<X>` passes a owned, dynamically-allocated X by reference (ie, Box<X> is a pointer to X).
A Box<dyn Bird> is some sort of Bird on the heap. But if I pass a Box<Goose> to a function which wants a Box<dyn Bird>, then my call moves the Box<Goose> into the function, I don't still have that Goose, it's gone, I hope the function takes good care of it.
If the function only wanted a reference to it, that would be &Box<dyn Bird> and then I wouldn't give up ownership by passing it to the function. But that's also a very strange thing to ask for, since we can instead pass a reference to a Bird, no need to Box it.
If the function only wanted a reference to it, that would be &Box<dyn Bird> and then I wouldn't give up ownership by passing it to the function. But that's also a very strange thing to ask for, since we can instead pass a reference to a Bird, no need to Box it.
> A Box<dyn Bird> is some sort of Bird on the heap.
No, a Box<dyn Bird> is a pointer to some sort of Bird on the heap. Unless Rust has wildly changed how it implements function calls/stack frames, local variables are stored on the stack. A pointer is a reference to the thing it points to (in sense used in the phrase "pass by reference").
> then my call moves the Box<Goose> into the function, I don't still have that Goose
Yes: you passed a Box<Goose> by value, you passed the Goose it points to by reference, and you transfered ownership of both.
No, a Box<dyn Bird> is a pointer to some sort of Bird on the heap. Unless Rust has wildly changed how it implements function calls/stack frames, local variables are stored on the stack. A pointer is a reference to the thing it points to (in sense used in the phrase "pass by reference").
> then my call moves the Box<Goose> into the function, I don't still have that Goose
Yes: you passed a Box<Goose> by value, you passed the Goose it points to by reference, and you transfered ownership of both.
I think what got confused here is just the nomenclature? In particular the use of "reference" to mean what we get when we borrow something in Rust, and its use to mean the address of something as part of a calling convention.
> are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return.
Whether I ask for a Goose or a Box<Goose>, it's mine now. The caller no longer has it, it's not just that they shouldn't use it, they can't, the compiler won't let them. Since it's mine, it is now my responsibility as owner either clean up, give it to somebody else or explicitly leak() it.
Rust doesn't promise how exactly this is implemented, and it is likely to be different for an object of 4 bytes than for an object of 400 bytes.
> are you promising to deallocate and otherwise clean up the object when you're done with it, versus are you promising that the caller can keep using it after you return.
Whether I ask for a Goose or a Box<Goose>, it's mine now. The caller no longer has it, it's not just that they shouldn't use it, they can't, the compiler won't let them. Since it's mine, it is now my responsibility as owner either clean up, give it to somebody else or explicitly leak() it.
Rust doesn't promise how exactly this is implemented, and it is likely to be different for an object of 4 bytes than for an object of 400 bytes.
None of the snippets in my post indicate borrowing. You can borrow or not borrow any of the types above.
It is true, though, that there are differences. With the generic, you can refer to the type again later, whereas the type is anonymous with `impl Trait`. And `dyn Trait` gives you dynamic dispatch. But in my experience there are usually some differences between the multiple ways to do something in Perk as well.
It is true, though, that there are differences. With the generic, you can refer to the type again later, whereas the type is anonymous with `impl Trait`. And `dyn Trait` gives you dynamic dispatch. But in my experience there are usually some differences between the multiple ways to do something in Perk as well.
For someone new to systems programming, should I just start with Rust?
Or should I learn C/C++ first and then learn Rust?
I've just done projects in Python,JS & Java so far.
Or should I learn C/C++ first and then learn Rust?
I've just done projects in Python,JS & Java so far.
It depends what you're trying to do.
If you want just to "play" and do some tiny projects as low level as reasonable - go for learning C first. You'll learn a lot - and then when you learn rust, the reasons why things are done that way will make a lot of sense. Also, so many low level utils are written in C - having a basic knowledge of it is really useful. But don't try to build a big complex thing in it unless you have a really good reason to (or you fall in love with C. Some people do!)
If you want to actually build something big and complex and for real world use - probably go for Rust.
If you want to build a big production system using an already established tech that's based on C++, learn that. (Eg. one of the C++ based game engines, or a C++ GUI framework, or whatever).
If you want just to "play" and do some tiny projects as low level as reasonable - go for learning C first. You'll learn a lot - and then when you learn rust, the reasons why things are done that way will make a lot of sense. Also, so many low level utils are written in C - having a basic knowledge of it is really useful. But don't try to build a big complex thing in it unless you have a really good reason to (or you fall in love with C. Some people do!)
If you want to actually build something big and complex and for real world use - probably go for Rust.
If you want to build a big production system using an already established tech that's based on C++, learn that. (Eg. one of the C++ based game engines, or a C++ GUI framework, or whatever).
Learning enough C to be able to understand most C you come across is a much, much smaller lift than doing the same with C++. It can be useful later and also give you an understanding of how computers work, at least down to the level of abstraction they present to compiled code which does hide some of the underlying complexity. And I think, for me at least, having a C level understanding of things will help understand the design and rules of Rust more easily. You don't need to learn it first but spending a weekend on it before diving into Rust is plausibly a good idea.
C++ has everything C has plus many layers of complexity deposited over it that can make you more productive but also obscure your relationship with the machine. If you're going to go on to Rust I wouldn't bother with C++ at all right now.
C++ has everything C has plus many layers of complexity deposited over it that can make you more productive but also obscure your relationship with the machine. If you're going to go on to Rust I wouldn't bother with C++ at all right now.
It's difficult to answer this right now because the overwhelming majority of people who use Rust now have at least some background in C or C++.
If you're coming from Java, the most difficult thing you'll need to learn is memory management, as all of those languages do that for you. The other difficult thing is threading, but that's 1) unnecessary and 2) not actually that different from Java.
Rust forces you (unsafe aside) to do memory management in one specific way, and verifies it in the compiler. C and C++ let you do whatever you want, though C++ encourages (without requiring) a Rust-like approach.
I think Rust will probably be better if you want to have a constrained environment that tries to prevent mistakes. C will be better if you want to explore on your own, learn from the mistakes, and thus understand why Rust wants you to do particular things. C++ frankly doesn't have a whole lot to recommend it unless you are working with a C++ codebase, already know C, or really need one of its features.
If you're coming from Java, the most difficult thing you'll need to learn is memory management, as all of those languages do that for you. The other difficult thing is threading, but that's 1) unnecessary and 2) not actually that different from Java.
Rust forces you (unsafe aside) to do memory management in one specific way, and verifies it in the compiler. C and C++ let you do whatever you want, though C++ encourages (without requiring) a Rust-like approach.
I think Rust will probably be better if you want to have a constrained environment that tries to prevent mistakes. C will be better if you want to explore on your own, learn from the mistakes, and thus understand why Rust wants you to do particular things. C++ frankly doesn't have a whole lot to recommend it unless you are working with a C++ codebase, already know C, or really need one of its features.
> If you're coming from Java, the most difficult thing you'll need to learn is memory management,
I'm coming from a largely Java background (though I program a lot of C and assembly as a hobby), and this statement is very true. Getting used to the borrow checker and reference lifetimes has been the largest obstacle so far. But once that is understood, the rest of Rust is basically learning the idioms and ecosystem.
I will likely change how I write C based on my experience with Rust's memory ownership model..
I'm coming from a largely Java background (though I program a lot of C and assembly as a hobby), and this statement is very true. Getting used to the borrow checker and reference lifetimes has been the largest obstacle so far. But once that is understood, the rest of Rust is basically learning the idioms and ecosystem.
I will likely change how I write C based on my experience with Rust's memory ownership model..
Unless you're doing isolated experiments, it's complicated, because systems programming inevitable interfaces and coexists with C. So one will need to have a reasonable understanding of C and its ecosystem (I'm doing this now).
Moving from high-level languages to Rust is going to be a nice punch in the face :)
Some people suggest to learn C/C++ but that ultimately depends on the resources available. If one has infinite time, certainly it's ideal, but with limited time, I think learning Rust will already be very demanding.
My suggestion: find some small projects you find interesting. Follow the usual Rust learning path (reference book first, then find other books), and apply it to the projects you've chosen; after an year or so, ask the question again.
Other small suggestion: don't start from book that pretend to teach Rust by learning another topic, because the amount of Rust that can be taught in 100 pages is useless (a lot of books pretend to do so). On the other hand, there are way more books to find fun projects/topics than there were an year ago.
Moving from high-level languages to Rust is going to be a nice punch in the face :)
Some people suggest to learn C/C++ but that ultimately depends on the resources available. If one has infinite time, certainly it's ideal, but with limited time, I think learning Rust will already be very demanding.
My suggestion: find some small projects you find interesting. Follow the usual Rust learning path (reference book first, then find other books), and apply it to the projects you've chosen; after an year or so, ask the question again.
Other small suggestion: don't start from book that pretend to teach Rust by learning another topic, because the amount of Rust that can be taught in 100 pages is useless (a lot of books pretend to do so). On the other hand, there are way more books to find fun projects/topics than there were an year ago.
> For someone new to systems programming, should I just start with Rust? Or should I learn C/C++ first and then learn Rust?
IMHO, if your end-goal is Rust, learn Rust directly.
The angle I am coming from: I've been doing C++ for 20 years and Rust for over a year.
Learning C/C++ can provide great value on its own, through gaining knowledge of how lower-level programming primitives work, but many of your C/C++ skills won't be subsequently applicable to Rust, except perhaps for core concepts such as a stack, a heap, owning memory, a `struct`, etc. This is caused by the fact that Rust takes many programming abstractions much _farther_ than C and in a substantially _different_ direction than C++. For example: where C uses manually managed pointers, Rust uses compile-time checked ownership and borrowing; where C++ uses inheritance, Rust uses generics and composition; where C uses void pointers ;) and C++ uses pure virtual functions, Rust uses traits and `where` clauses; where C and C++ use... a programmer's eyeballs to guarantee multi-threaded correctness ;), Rust uses compile-time "marker" traits; and so on.
Don't get me wrong: C and C++ are extremely able, powerhouse languages worth your time in their own respect, it is just that most of the C/C++ -specific knowledge you invest your time to learn beforehand won't be directly applicable to Rust later on, because Rust just does things in a significantly different way than C/C++.
Oh, don't forget to RTFM - Rust is easy to learn by reading (in order to understand its unique concepts), but Rust is hard to learn by experimentation alone (trying 100 different syntax variations to see what compiles).
IMHO, if your end-goal is Rust, learn Rust directly.
The angle I am coming from: I've been doing C++ for 20 years and Rust for over a year.
Learning C/C++ can provide great value on its own, through gaining knowledge of how lower-level programming primitives work, but many of your C/C++ skills won't be subsequently applicable to Rust, except perhaps for core concepts such as a stack, a heap, owning memory, a `struct`, etc. This is caused by the fact that Rust takes many programming abstractions much _farther_ than C and in a substantially _different_ direction than C++. For example: where C uses manually managed pointers, Rust uses compile-time checked ownership and borrowing; where C++ uses inheritance, Rust uses generics and composition; where C uses void pointers ;) and C++ uses pure virtual functions, Rust uses traits and `where` clauses; where C and C++ use... a programmer's eyeballs to guarantee multi-threaded correctness ;), Rust uses compile-time "marker" traits; and so on.
Don't get me wrong: C and C++ are extremely able, powerhouse languages worth your time in their own respect, it is just that most of the C/C++ -specific knowledge you invest your time to learn beforehand won't be directly applicable to Rust later on, because Rust just does things in a significantly different way than C/C++.
Oh, don't forget to RTFM - Rust is easy to learn by reading (in order to understand its unique concepts), but Rust is hard to learn by experimentation alone (trying 100 different syntax variations to see what compiles).
Start with C. C++ is fine too.
You don't need to 100% the language, a few months experience will be be handy for the rest of your computing career. It'll be a perfectly reasonable stepping stone for reading C++ without really needing to learn all the details to write it.
As much as any language can be: C is still the lingua franca, a relative common denominator. As you explore different parts of the computing environment around you, you'll run into it constantly.
Learning about python? C. Digging into how your program talks to the OS? glibc and the man pages and most examples will be C oriented. Any documentation ever explains how something is laid out in memory? It'll be explained in C structs. How function calls work? The assembly will be explained in terms of C code and C's calling convention. Any language's FFI? C. Digging into the JVM, browsers, Javascript? It's C++ but you'll know enough to eyeball the code.
This is mostly about all the things you'll want to be able to read about well. Anything you'll want to know has been done in C or C++ — Nothing big exists that you'll want to explore is mostly written in Rust or Zig yet. And there are still things that can't reasonably be yet either (oversimplification).
You don't need to 100% the language, a few months experience will be be handy for the rest of your computing career. It'll be a perfectly reasonable stepping stone for reading C++ without really needing to learn all the details to write it.
As much as any language can be: C is still the lingua franca, a relative common denominator. As you explore different parts of the computing environment around you, you'll run into it constantly.
Learning about python? C. Digging into how your program talks to the OS? glibc and the man pages and most examples will be C oriented. Any documentation ever explains how something is laid out in memory? It'll be explained in C structs. How function calls work? The assembly will be explained in terms of C code and C's calling convention. Any language's FFI? C. Digging into the JVM, browsers, Javascript? It's C++ but you'll know enough to eyeball the code.
This is mostly about all the things you'll want to be able to read about well. Anything you'll want to know has been done in C or C++ — Nothing big exists that you'll want to explore is mostly written in Rust or Zig yet. And there are still things that can't reasonably be yet either (oversimplification).
Rust has a bit of a steeper learning curve at the start, but it pays off once you get used to it. C and C++ are deceptively simple at first, but as time goes on you keep discovering more nuances that affect most of your code.
There's no real problem starting with Rust, especially if you have some experience with other languages. The biggest difference is going to be getting used to dealing explicitly with memory, since all the languages you listed have a garbage collector; but this is true of all of C, C++ and, Rust. Be kind to yourself -- don't expect it all to click instantly.
There's no real problem starting with Rust, especially if you have some experience with other languages. The biggest difference is going to be getting used to dealing explicitly with memory, since all the languages you listed have a garbage collector; but this is true of all of C, C++ and, Rust. Be kind to yourself -- don't expect it all to click instantly.
C will teach you how computers think.
Rust is it's own thing; I personally really like it but going from C to Rust is harder than just going to Rust as you have to "unlearn" C paradigms.
You'll probably be "better" if you go C first, but it will take a lot of time and energy.
In the end its completely up to you.
Rust is it's own thing; I personally really like it but going from C to Rust is harder than just going to Rust as you have to "unlearn" C paradigms.
You'll probably be "better" if you go C first, but it will take a lot of time and energy.
In the end its completely up to you.
> C will teach you how computers think.
It will teach you how a PDP-11 thinks, at best. The cache hierarchy and speculative execution are completely hidden at the level of C, to start with.
You want to learn how computers think, pick up an assembly language. (Any one will do.) You want to build portable low-level software, learn Rust, Zig, C, or C++ (in my personal order of preference).
It will teach you how a PDP-11 thinks, at best. The cache hierarchy and speculative execution are completely hidden at the level of C, to start with.
You want to learn how computers think, pick up an assembly language. (Any one will do.) You want to build portable low-level software, learn Rust, Zig, C, or C++ (in my personal order of preference).
Cache hierarchy, branch prediction, speculative execution and all of the other performance enhancements of modern CPUs are hidden from assembly too. If you are a real whiz, you may be able to hand-tune your assembly code so that it takes better advantage of one of these features and runs 0.1% faster, but otherwise these features are transparent even to assembly programmers.
Just to mention it here, too (I wrote more in a cousin comment), Intel's own Software Development Manuals [0] explicitly talks about all three of these things. I don't consider these features hidden when the primary reference for programming this platform clearly documents and provides advice on them.
[0] https://www.intel.com/content/www/us/en/developer/articles/t...
[0] https://www.intel.com/content/www/us/en/developer/articles/t...
> 0.1% faster,
The performance gains of fine-tuned code is typically two orders of magnitude higher
The performance gains of fine-tuned code is typically two orders of magnitude higher
The cache hierarchy and speculative execution are completely hidden at the level of assembly too, so I'm not sure what you're getting at.
> The cache hierarchy [...] are completely hidden at the level of assembly too
A quick glance at Intel's Software Developer's Manuals [0] falsifies this:
>> TLB and Cacheability control: CLFLUSH, CLFLUSHOPT, CLWB, INVD, WBINVD, INVLPG, INVPCID, and memory instructions with a non-temporal hint (V/MOVNTDQA, V/MOVNTDQ, V/MOVNTI, V/MOVNTPD, V/MOVNTPS, V/MOVNTQ, V/MASKMOVQ, and V/MASKMOVDQU).
> [..] speculative execution are completely hidden at the level of assembly too
Section 18.1.13 specifically mentions side-channels for speculative execution, and there are more than 100 other matches for "speculative" across the document (some of which also refer to load barriers).
So no, these things are not completely hidden at the assembly level, and at least in the case of the (or one of the?) most popular consumer CPU architecture in the world, they are actively documented in the primary reference for an assembly programmer.
[0] https://www.intel.com/content/www/us/en/developer/articles/t...
A quick glance at Intel's Software Developer's Manuals [0] falsifies this:
>> TLB and Cacheability control: CLFLUSH, CLFLUSHOPT, CLWB, INVD, WBINVD, INVLPG, INVPCID, and memory instructions with a non-temporal hint (V/MOVNTDQA, V/MOVNTDQ, V/MOVNTI, V/MOVNTPD, V/MOVNTPS, V/MOVNTQ, V/MASKMOVQ, and V/MASKMOVDQU).
> [..] speculative execution are completely hidden at the level of assembly too
Section 18.1.13 specifically mentions side-channels for speculative execution, and there are more than 100 other matches for "speculative" across the document (some of which also refer to load barriers).
So no, these things are not completely hidden at the assembly level, and at least in the case of the (or one of the?) most popular consumer CPU architecture in the world, they are actively documented in the primary reference for an assembly programmer.
[0] https://www.intel.com/content/www/us/en/developer/articles/t...
You're much more likely to get bitten by those 2 things at the ASM level... I guess.
So I don't work at that level, I'd love to hear more. What situations do they leak through in?
you'll mostly notice performance problems if you're not aware of cache lines when writing concurrent software, though it's relevant whenever you read from main memory. As for speculative execution, you probably won't really encounter issues related to that unless you go out of your way to. I don't believe it can actually cause problems in programs (though it is helpful for exfiltrating otherwise secret data).
This is true even on later PDP-11 models with memory caches.
> It will teach you how a PDP-11 thinks, at best. The cache hierarchy and speculative execution are completely hidden at the level of C, to start with.
And error recovery (that is fucking crazy on x86), and wide instructions, and I/O, and stack management, and... I am not sure C is even a good approximation for the PDP-11.
And error recovery (that is fucking crazy on x86), and wide instructions, and I/O, and stack management, and... I am not sure C is even a good approximation for the PDP-11.
All computers are pdp-11s.
> You want to learn how computers think, pick up an assembly language.
For which you'd need to be familiar with a low-level language like C.
For which you'd need to be familiar with a low-level language like C.
... no? In fact I think learning assembly before C makes a lot more sense than the other way around.
This. The computer science degree I did started off in the first term with us building computers on an FPGA by mapping out the logic gates, then programming it in assembly. Learning how to program in C followed this.
It's a good way of helping people with no programming knowledge get past the stage of "what are those magic colourful words you type that somehow make the computer do things?".
It's a good way of helping people with no programming knowledge get past the stage of "what are those magic colourful words you type that somehow make the computer do things?".
I think this is an awful way of learning for beginning CS students. It will scare off too many good kids who think this is all that CS will ever be. Top down is better. Bottom up is only going to be good for people who adore computer architecture guts and want to start at the bottom from first principals. Most kids want to use computers as a tool and not learn it's atomic structure.
Unless you're experienced well in some other language then assembly is going to scare you off. I learned assembly by looking at -O0 output from c compiler code. Then I went ahead and dived in. Just doing bare assembly is not somewhere a beginner should start unless they are just absolutely in love with low level programming.
I learned CHIP-8 asm and Gameboy asm before ever touching C
I want to learn how to build emulators for CHIP-8 and Gameboy and am having the person tug-of-war over assembly, C, or Rust. With hindsight, do you recommend doing them in assembly? And what resources did you use to get started?
I wrote my CHIP-8 emulator in C#, actually. I used the Godot game engine for rendering and sound (though I never actually got around to implementing sound). The language you write it in really doesn't matter too much unless you really care about performance, or if you want to do something fancier than an interpreter (like a JIT recompiler). I used this guide:
https://tobiasvl.github.io/blog/write-a-chip-8-emulator/
I haven't made a Gameboy emulator, just learned the assembly so I could modify some roms.
https://tobiasvl.github.io/blog/write-a-chip-8-emulator/
I haven't made a Gameboy emulator, just learned the assembly so I could modify some roms.
I wrote a CHIP-8 emulator[0] a while back in C using SDL2 for rendering everything. It still has a couple issues with the timers and taking input.
I was new to C back then so I did this project to become more familiar with it.
You can check out my blog post[1] if you're interested how I went about it (there are a couple resources at the bottom I used to build it, including the one that HideousKojima recommended).
As for language, in hindsight, C was fine. CHIP-8 is so basic that you don't really need to worry about performance or to implement a JIT compiler unless you want to learn how to do those things specifically. Just pick any one out of the three (assembly is a bit of a weird choice though, why not write a CHIP-8 emulator and then a brand new program to run on that emulator in CHIP-8 assembly if you want to learn assembly?)
As for Gameboy, it would have more instructions, a different graphics system, sound etc. and overall be more complicated than CHIP-8. Try it out if you either feel a bit more adventurous or have implemented CHIP-8.
[0](https://sr.ht/~gotlou/chip8-emulator) [1](https://gotlou.srht.site/chip8-emulator.html)
You can check out my blog post[1] if you're interested how I went about it (there are a couple resources at the bottom I used to build it, including the one that HideousKojima recommended).
As for language, in hindsight, C was fine. CHIP-8 is so basic that you don't really need to worry about performance or to implement a JIT compiler unless you want to learn how to do those things specifically. Just pick any one out of the three (assembly is a bit of a weird choice though, why not write a CHIP-8 emulator and then a brand new program to run on that emulator in CHIP-8 assembly if you want to learn assembly?)
As for Gameboy, it would have more instructions, a different graphics system, sound etc. and overall be more complicated than CHIP-8. Try it out if you either feel a bit more adventurous or have implemented CHIP-8.
[0](https://sr.ht/~gotlou/chip8-emulator) [1](https://gotlou.srht.site/chip8-emulator.html)
No, you don't. In the curriculum I've taught, assembly was taught before C. As long as you have any programming language experience, you should be fine with assembly--I've explained it in terms of even MATLAB before.
Assembly was my first language. I had no trouble picking that up, and in fact didn't meet a compiler until ten years later. They were much too expensive at the time.
I don’t think this is true.
Check this post out - Should you learn C to "learn how the computer works"? (https://steveklabnik.com/writing/should-you-learn-c-to-learn...). Spoiler alert - no.
Check this post out - Should you learn C to "learn how the computer works"? (https://steveklabnik.com/writing/should-you-learn-c-to-learn...). Spoiler alert - no.
> C is not “how the computer works.” I don’t think most people mean this phrase literally, so that is sort of irrelevant.
Understanding the context means that learning C for this reason may still be a good idea for you, depending on your objectives.
I think summarizing that article as "no" really undercuts how diplomatic and reasonable Steve Klabnik is in it.
I think summarizing that article as "no" really undercuts how diplomatic and reasonable Steve Klabnik is in it.
Of course learning widely used technologies may be a good idea for some people, depending on their objectives. That’s a truism.
But is it necessary to understand now a computer works? No.
You can also check out "C is how the computer works" is a dangerous mindset for C programmers (https://steveklabnik.com/writing/c-is-how-the-computer-works...)
But is it necessary to understand now a computer works? No.
You can also check out "C is how the computer works" is a dangerous mindset for C programmers (https://steveklabnik.com/writing/c-is-how-the-computer-works...)
Thank you for the kind words. I got enough heat for it at the time that it took me a full year to return to the topic, so it's nice that some folks still remember it fondly.
Your views on programming languages are deeply appreciated, regardless of whether I agree or not.
Steve Klabnik has done a lot for systems programming and that post is a lot more even-handed than you're suggesting.
If, however, we're talking about the kernel then perhaps we should listen to what Torvalds says about this topic.
"People who designed C, designed it at a time where the language had to be geared towards the output, so when I read C I can think about the Assembly that it will create":
http://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s
Consider that he said this in a time with C++, even if Rust was in its infancy: it is not as tied to the assembly it produces. Not by a long shot.
If, however, we're talking about the kernel then perhaps we should listen to what Torvalds says about this topic.
"People who designed C, designed it at a time where the language had to be geared towards the output, so when I read C I can think about the Assembly that it will create":
http://www.youtube.com/watch?v=MShbP3OpASA&t=20m45s
Consider that he said this in a time with C++, even if Rust was in its infancy: it is not as tied to the assembly it produces. Not by a long shot.
Sounds to me like if I want to know "how computers think" I should learn assembly.
I know you're trying to be a smart-arse; but by virtue of using C you will learn Assembly.
The issue with Assembly directly is that it's absurdly non-portable, too low level and too unstructured to do anything reasonable with it.
There's a reason that Linux is written in C and not ASM Directly.
The issue with Assembly directly is that it's absurdly non-portable, too low level and too unstructured to do anything reasonable with it.
There's a reason that Linux is written in C and not ASM Directly.
> by virtue of using C you will learn Assembly.
Even interpreting this as charitably as possible--that you don't mean literally learning assembly but rather learning everything besides specific assembly syntax that you would have picked up from learning assembly--this claim doesn't hold water.
For starters, C isn't that much closer to hardware than, say, Java. The main differences you have with C are that a) C has a pointers-are-almost-integers model [1] and b) C has a more limited runtime than other languages. C is still a fundamentally based on an abstract machine semantics model, and that abstract machine doesn't have a close bearing on modern hardware.
In particular, C does not distinguish between registers and memory, and if I had to pick the single most salient feature of modern hardware you need to understand well to be able to say you understand how computers work, it's the register/memory distinction. If you think processors are mostly like they were in the 1970s--when you could say "add 1 to this memory location"--then C's shrugging off the register/memory distinction makes sense, but this is a situation that hasn't been true for several decades.
Another failure of C is that it's far less expressive than assembly. There are features in other languages that are impossible to express in C. How do you write a function with multiple entry points, as you can in Fortran? Or a coroutine, as you can in Algol? Or nested functions, as in Pascal? Or try-catch, as in C++? Or functions with multiple return values, as in Matlab? Indeed, how do you write something like JMP *reg in C, a useful primitive for state machines?
No, C does not come close to being a good description of modern processors, where "modern" means "anything that came out since I was born."
[1] Not going to open up the can of worms that is pointer provenance.
Even interpreting this as charitably as possible--that you don't mean literally learning assembly but rather learning everything besides specific assembly syntax that you would have picked up from learning assembly--this claim doesn't hold water.
For starters, C isn't that much closer to hardware than, say, Java. The main differences you have with C are that a) C has a pointers-are-almost-integers model [1] and b) C has a more limited runtime than other languages. C is still a fundamentally based on an abstract machine semantics model, and that abstract machine doesn't have a close bearing on modern hardware.
In particular, C does not distinguish between registers and memory, and if I had to pick the single most salient feature of modern hardware you need to understand well to be able to say you understand how computers work, it's the register/memory distinction. If you think processors are mostly like they were in the 1970s--when you could say "add 1 to this memory location"--then C's shrugging off the register/memory distinction makes sense, but this is a situation that hasn't been true for several decades.
Another failure of C is that it's far less expressive than assembly. There are features in other languages that are impossible to express in C. How do you write a function with multiple entry points, as you can in Fortran? Or a coroutine, as you can in Algol? Or nested functions, as in Pascal? Or try-catch, as in C++? Or functions with multiple return values, as in Matlab? Indeed, how do you write something like JMP *reg in C, a useful primitive for state machines?
No, C does not come close to being a good description of modern processors, where "modern" means "anything that came out since I was born."
[1] Not going to open up the can of worms that is pointer provenance.
> C does not distinguish between registers and memory
Just nitpicking, but doesn't C have the register keyword? (I know it does nothing at all nowadays, but AFAIK it did make a slight difference back in the dark ages.)
Just nitpicking, but doesn't C have the register keyword? (I know it does nothing at all nowadays, but AFAIK it did make a slight difference back in the dark ages.)
C's register keyword is a storage specifier, it actually does do something, what it does is announce "This might not have an address" (your CPU registers don't have addresses) and so you can't make a pointer to it with the unary & address operator.
Your C compiler might conclude - even if it doesn't decide to put the variable in a register - that since the variable notionally doesn't have an address some optimisations are available which it can't otherwise be sure are safe.
Your C compiler might conclude - even if it doesn't decide to put the variable in a register - that since the variable notionally doesn't have an address some optimisations are available which it can't otherwise be sure are safe.
Considering that `volatile register _Atomic int x;` is a totally legal statement, and two [1] of those keywords have semantics that are only relevant for memory operations, I'd say that the "register" keyword isn't sufficient to distinguish register from memory.
[1] Okay, the official semantics of "volatile" strictly speaking are completely orthogonal to memory, but the practical effect that everyone agrees on (don't optimize this memory access) is inherently oriented towards memory, and the fact that the semantics are so vague about what it actually does is partially a reflection of the fact the semantics themselves don't distinguish between register and memory.
[1] Okay, the official semantics of "volatile" strictly speaking are completely orthogonal to memory, but the practical effect that everyone agrees on (don't optimize this memory access) is inherently oriented towards memory, and the fact that the semantics are so vague about what it actually does is partially a reflection of the fact the semantics themselves don't distinguish between register and memory.
> by virtue of using C you will learn Assembly.
I don't believe this at all. You won't learn how to deal with limited numbers of registers. You won't learn about method prologues and epilogues. You won't learn about oodles of stuff.
I don't believe this at all. You won't learn how to deal with limited numbers of registers. You won't learn about method prologues and epilogues. You won't learn about oodles of stuff.
> You won't learn how to deal with limited numbers of registers. You won't learn about method prologues and epilogues.
Those things takes like an hour to learn, translating C to assembly is trivial, it takes time and will be verbose but it isn't hard at all. So even though you don't learn all the details you still learn all the higher level stuff related to assembly programming when you program in C.
This isn't true for other languages, translating arbitrary C++ or Java or Javascript to assembly is really hard, so they don't teach you to think like an assembly programmer.
Those things takes like an hour to learn, translating C to assembly is trivial, it takes time and will be verbose but it isn't hard at all. So even though you don't learn all the details you still learn all the higher level stuff related to assembly programming when you program in C.
This isn't true for other languages, translating arbitrary C++ or Java or Javascript to assembly is really hard, so they don't teach you to think like an assembly programmer.
> deal with limited numbers of registers
I mean; you will likely end up stepping through debuggers where you will see registers being used. At least if you learned C like I learned C.
Similarly for Prologue and Epilogue.
"why does a function call have a cost" is a common question and it's solved forever after an hour googling.
I mean; you will likely end up stepping through debuggers where you will see registers being used. At least if you learned C like I learned C.
Similarly for Prologue and Epilogue.
"why does a function call have a cost" is a common question and it's solved forever after an hour googling.
Rust is written in the blood of fallen C/C++ projects.
If you're willing to accept, at face value, that certain easy tasks are convoluted for Good Reasons, you can go straight to Rust. If you want figure out why for yourself, start with C.
If you're willing to accept, at face value, that certain easy tasks are convoluted for Good Reasons, you can go straight to Rust. If you want figure out why for yourself, start with C.
That is the best description of why Rust exists that I've seen so far.
This is highly personal and depends on your learning style.
I always want to learn bottom up, and personally recommend starting with C.
A)
Rust gives you many great abstractions that you will want to use, even if you skip the standard library. This gets in the way of really learning to work with and understanding pointers and low level mechanisms. You can certainly do that in Rust, but you have to force yourself to ignore most oft the language.
B)
You will have to read and interact with C code eventually, and be it just calling out to libraries or wrapping libraries in Rust interfaces.
A solid understanding of C is critical to do that correctly.
There's also a lot of safety tooling that you rarely need with Rust, but should be comfortable with. (Like valgrind)
After learning Rust you will hate working with C (well, I do...), so it's better to do it early.
I always want to learn bottom up, and personally recommend starting with C.
A)
Rust gives you many great abstractions that you will want to use, even if you skip the standard library. This gets in the way of really learning to work with and understanding pointers and low level mechanisms. You can certainly do that in Rust, but you have to force yourself to ignore most oft the language.
B)
You will have to read and interact with C code eventually, and be it just calling out to libraries or wrapping libraries in Rust interfaces.
A solid understanding of C is critical to do that correctly.
There's also a lot of safety tooling that you rarely need with Rust, but should be comfortable with. (Like valgrind)
After learning Rust you will hate working with C (well, I do...), so it's better to do it early.
I essentially began with C, but my guess is that you should start lower if you can.
You don't want to get fooled into thinking C's abstract machine is what your actual machine is like, because it really, really isn't. A bunch of the stuff C is deliberately vague about because it wasn't portable in the 1970s is very concrete and important to understand about on a real computer. Rust's Wrapping<u8> and Saturating<i16> have behaviour that you could buy with a real CPU (indeed your actual CPU almost certainly can do Wrapping<u8> with no extra work) but C doesn't promise anything like this and names types things like "short int" which could be anything.
On the other hand, some things C makes seem obviously concretely real, are just being simulated convincingly and that's not necessarily how your CPU works at all. Nobody really promised "pointers" are just integers you can go around doing arithmetic with for example.
You don't want to get fooled into thinking C's abstract machine is what your actual machine is like, because it really, really isn't. A bunch of the stuff C is deliberately vague about because it wasn't portable in the 1970s is very concrete and important to understand about on a real computer. Rust's Wrapping<u8> and Saturating<i16> have behaviour that you could buy with a real CPU (indeed your actual CPU almost certainly can do Wrapping<u8> with no extra work) but C doesn't promise anything like this and names types things like "short int" which could be anything.
On the other hand, some things C makes seem obviously concretely real, are just being simulated convincingly and that's not necessarily how your CPU works at all. Nobody really promised "pointers" are just integers you can go around doing arithmetic with for example.
I started using Rust because I wanted a programming language that compiled to native binaries, and the choice at the time was really only C++, Go and Rust. In the end I chose Rust because it was new and shiny, and I've stuck with it. Never written a single unsafe line of code or anything low-level, it's just been CLI tools and web APIs.
I would argue that if you’re really interested in systems programming, learning C is required just because the vast majority of the resources on systems programming is explained using C. The only notable exception is the Book Rust In Action! That being said, is your goal to be a systems programmer or a rust programmer? If it’s the latter, then learn Rust! But, as it seems that you are learning programming in general, learn the basics and data structures algorithms (these are rather language agnostic).
You’ll ultimately need to know both. Lots of new stuff will be in Rust, but plenty of old C/C++ code won’t be going away in our lifetimes. I’d start with the one used by the projects you are most motivated to work on immediately.
> should I learn C/C++ first and then learn Rust?
If your endpoint is Rust anyway, just start there. You can always learn C (and/or C++) later.
I don't think it matters (much) which language you start with. Any one of the suggested languages (or commonly suggested languages in general) will be fine. I think this applies in general too, at any levels of skill/experience, but probably matters more for someone with less experience.
If your endpoint is Rust anyway, just start there. You can always learn C (and/or C++) later.
I don't think it matters (much) which language you start with. Any one of the suggested languages (or commonly suggested languages in general) will be fine. I think this applies in general too, at any levels of skill/experience, but probably matters more for someone with less experience.
Don't start with C++.
Between C and Rust, Rust has better tooling and an easy to use library ecosystem. C is a smaller and easier to grasp language.
I would start with Rust if you want to write a real world project. And probably start with Rust if you just want to write some leetcode algorithms as well (but C is fine here too)
Between C and Rust, Rust has better tooling and an easy to use library ecosystem. C is a smaller and easier to grasp language.
I would start with Rust if you want to write a real world project. And probably start with Rust if you just want to write some leetcode algorithms as well (but C is fine here too)
Depends on what you're doing, but really Rust is built with the explicit goal of being able to link to C easily. You would be doing yourself a favor to learn C (not C++) in general, but especially because you will be able to use C libraries from Rust.
I learned Rust because I need to write low-level high-performance stuff and I don't want to spend time learning how to do it correctly in C++. Rust compiler automates many chores for me, just like any computer technology is supposed to.
I'd recommend learning Rust because the way Rust pushes you into writing code will lead you to write better C code, etc.
People that learn C or C++ first often end up fighting the Rust compiler a bit until they adjust their mindset.
People that learn C or C++ first often end up fighting the Rust compiler a bit until they adjust their mindset.
Personally I'd recommend Rust first, then C.
Rust's borrowing and ownership semantics are not bizarre and novel solutions to things that aren't problems in other languages. Rust's borrowing and ownership semantics are a compiler-level reification of problems that exist in all languages, and especially multithreaded languages. This 100% includes C. You may not adopt Rust's exact solutions in all cases, but if your are programming at a system's level at all and you're not thinking about the problems that Rust exposes directly, you're in trouble and you don't even know it. Using Rust is a great way to work in an environment where the compiler is forcing you to learn how that all works, and will train you good and hard about how to think about issues of ownership and what code is allowed to touch what.
I primarily work in Go, a garbage collected language, and I heavily use the concurrency features. That doesn't mean I don't have to think about ownership because the language lacks any support for it, or that I don't have to worry about who is responsible for deallocating things because I work in a GC'd language. It means I have to think about those things, but I lack support from the language. My personal career experience means this is not a terrible tradeoff; as a result of all my time in Erlang and Haskell it is no big deal for me to operate concurrently in a manner that I know will work, because while they are different than Rust, they were also harsh taskmasters in terms of only allowing me to do certain things that work. Other tradeoffs make Go worth it for me despite this lack of language support. But the lack of support doesn't make the problems go away. It just makes it so you can't see them immediately at compile time.
I would expect that someone who learned Rust for a year, then learned C for a year, would probably produce better C code than someone who learned C for two years. Eventually, the C programmer will, by hook and by crook, learn all the things that Rust would have taught you, but you'll be learning it in an enviromnent that lets you make mistakes, then build on them for months before they finally blow up in your face. It is far easier to learn about what mistakes you are making in an environment where it instantly tells you that you made a mistake.
(Also, I should clarify something: By "C" here, I mean programming in raw C, without any particular additional support. For the sort of purposes I'm talking about here, I actually consider "C with a strong static analysis tool like Coverity" a separate language. If you use such a tool pervasively and work in a code base that has either been cleaned to its satisfaction or started from scratch under the analyzer's support, you can also learn in a fast-feedback environment what not to do. It won't be the exact same lessons as Rust, but it'll be good enough; there are many paths to enlightenment in this case, just as I trod a completely different one as mentioned above. The important point is to use one of these, or perhaps another, and not simply stand in front of the monster that is Raw C with nothing but your own wits to guide you. I don't care how smart you are. It'll eat you alive. You do not want to be responsible for trying to tame the thing yourself under your own power and nothing else.)
Rust's borrowing and ownership semantics are not bizarre and novel solutions to things that aren't problems in other languages. Rust's borrowing and ownership semantics are a compiler-level reification of problems that exist in all languages, and especially multithreaded languages. This 100% includes C. You may not adopt Rust's exact solutions in all cases, but if your are programming at a system's level at all and you're not thinking about the problems that Rust exposes directly, you're in trouble and you don't even know it. Using Rust is a great way to work in an environment where the compiler is forcing you to learn how that all works, and will train you good and hard about how to think about issues of ownership and what code is allowed to touch what.
I primarily work in Go, a garbage collected language, and I heavily use the concurrency features. That doesn't mean I don't have to think about ownership because the language lacks any support for it, or that I don't have to worry about who is responsible for deallocating things because I work in a GC'd language. It means I have to think about those things, but I lack support from the language. My personal career experience means this is not a terrible tradeoff; as a result of all my time in Erlang and Haskell it is no big deal for me to operate concurrently in a manner that I know will work, because while they are different than Rust, they were also harsh taskmasters in terms of only allowing me to do certain things that work. Other tradeoffs make Go worth it for me despite this lack of language support. But the lack of support doesn't make the problems go away. It just makes it so you can't see them immediately at compile time.
I would expect that someone who learned Rust for a year, then learned C for a year, would probably produce better C code than someone who learned C for two years. Eventually, the C programmer will, by hook and by crook, learn all the things that Rust would have taught you, but you'll be learning it in an enviromnent that lets you make mistakes, then build on them for months before they finally blow up in your face. It is far easier to learn about what mistakes you are making in an environment where it instantly tells you that you made a mistake.
(Also, I should clarify something: By "C" here, I mean programming in raw C, without any particular additional support. For the sort of purposes I'm talking about here, I actually consider "C with a strong static analysis tool like Coverity" a separate language. If you use such a tool pervasively and work in a code base that has either been cleaned to its satisfaction or started from scratch under the analyzer's support, you can also learn in a fast-feedback environment what not to do. It won't be the exact same lessons as Rust, but it'll be good enough; there are many paths to enlightenment in this case, just as I trod a completely different one as mentioned above. The important point is to use one of these, or perhaps another, and not simply stand in front of the monster that is Raw C with nothing but your own wits to guide you. I don't care how smart you are. It'll eat you alive. You do not want to be responsible for trying to tame the thing yourself under your own power and nothing else.)
I've personally been doing C and then C++ for about a decade before moving onto Rust 2-3 year ago. I don't think you're missing out on much by skipping C or C++, but I recommend dabbling in them a bit (doesn't matter if before/while/after learning Rust), as it will make you appreciate Rust more.
Most production systems have been transitioning to Rust in the past few years, so that’s the safest bet in my opinion.
The story I’m seeing at most companies is that they have a few old guys taking care of maintaining their legacy C/C++ codebase, and there’s a diverse bunch of young folks shipping new components in Rust.
The story I’m seeing at most companies is that they have a few old guys taking care of maintaining their legacy C/C++ codebase, and there’s a diverse bunch of young folks shipping new components in Rust.
My advice would be to learn the language that your operating system is written in.
Keep on using python and JS.
When the time comes you can start with Rust
When the time comes you can start with Rust
Linus loses control over kernel for quite a long time already.
I don't think he's trying to be an all-controlling BDFL. What I see is, he acts as a trim tab which steers the kernel to a general direction rather than a precise bearing.
Missing context? That came after a list of concerns and what-ifs about putting Rust in the kernel. Not an endorsement but also not a backhanded compliment, like you made it sound like with your cherry-picking.
I'm surprised Torvalds is so sanguine about Rust. Maybe it's age but I remember his epic gamer rant about how he would never allow C++ in the kernel. Either Rust is significantly better than C++ in his view, or he's accepted that C is likely not going to be the dominant systems programming language forever and opted for the least dangerous alternative.
Guess I should start my 5th attempt at finally getting good at Rust.
Guess I should start my 5th attempt at finally getting good at Rust.
> Either Rust is significantly better than C++ in his view
Probably this one:
- Rust has the clear goal of memory safety, which is an active issue in the kernel (see: Kees Cook's Kernel Self Protection Project), even more so when it comes to drivers which are a lot more variable in quality and have very variable levels of oversight, which is why those are the primary use case.
- Rust has a much more expressive type system, especially without the need to go into template weeds.
- Rust has a lot less implicit behaviours.
- Rust features tend to be more orthogonal and mis-interact less with one another.
- While Rust has a fairly steep learning curve, short of unsafe it doesn't kneecap you, if it doesn't like what you're doing (right or wrong) it tells you, it doesn't go off into the weeds doing the wrong thing.
Probably this one:
- Rust has the clear goal of memory safety, which is an active issue in the kernel (see: Kees Cook's Kernel Self Protection Project), even more so when it comes to drivers which are a lot more variable in quality and have very variable levels of oversight, which is why those are the primary use case.
- Rust has a much more expressive type system, especially without the need to go into template weeds.
- Rust has a lot less implicit behaviours.
- Rust features tend to be more orthogonal and mis-interact less with one another.
- While Rust has a fairly steep learning curve, short of unsafe it doesn't kneecap you, if it doesn't like what you're doing (right or wrong) it tells you, it doesn't go off into the weeds doing the wrong thing.
And while there are no shortage of C++ programmers who've said "just use C++" over the years, not too many actually lifted a finger to make it happen - the people who wanted Rust for Linux actually built Rust for Linux.
https://rust-for-linux.github.io/docs/kernel/
Out of that, core is basically just what you get from Rust's core itself, alloc is similar to Rust's provided alloc but is fairly heavily customised to meet the requirements of the kernel and of Linus. But kernel is custom code for the kernel specifically. Overall that's a lot of effort.
We didn't see a similar effort for C++. Would that have overcome Linus' reluctance? Well, it can't if it doesn't exist.
https://rust-for-linux.github.io/docs/kernel/
Out of that, core is basically just what you get from Rust's core itself, alloc is similar to Rust's provided alloc but is fairly heavily customised to meet the requirements of the kernel and of Linus. But kernel is custom code for the kernel specifically. Overall that's a lot of effort.
We didn't see a similar effort for C++. Would that have overcome Linus' reluctance? Well, it can't if it doesn't exist.
Linus had been positive towards Rust way before those projects started, way more than he was towards C++. C++ had plenty of kernels written in it, he still didn't want it near his tree. Rust is just a better language in his eyes for kernel purposes than C++ and I absolutely agree with him.
All great points. It is also a young enough language that significant kernal dev can have significant influence on the future of the language itself. CPP's future seems to be predicated upon its past adoption.
> Either Rust is significantly better than C++ in his view
Do you remember the Paul Graham essay on the Blub programming language? (http://www.paulgraham.com/avg.html)
C++ is kind of like the Blub language. If you know C++ well enough, you can do anything you need to do, so something like Rust just seems too esoteric and weird and pretentious.
Fortunately, I spent many years using Rust recently (coming from primarily a C background) and when I'm on a project using C++, it just feels too weird and rudimentary and horribly over-complicated.
To end with a quote from the PG article:
_But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub._
Do you remember the Paul Graham essay on the Blub programming language? (http://www.paulgraham.com/avg.html)
C++ is kind of like the Blub language. If you know C++ well enough, you can do anything you need to do, so something like Rust just seems too esoteric and weird and pretentious.
Fortunately, I spent many years using Rust recently (coming from primarily a C background) and when I'm on a project using C++, it just feels too weird and rudimentary and horribly over-complicated.
To end with a quote from the PG article:
_But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub._
Paul Graham favored Lisp, which gives programmers limitless freedom to implement whatever they want, Rust is the opposite side of that.
C++ is full of footguns and it is easy to make mistakes, but it is also one of the most powerful and expressive languages out there.
C++ is full of footguns and it is easy to make mistakes, but it is also one of the most powerful and expressive languages out there.
Rust gives you data race freedom and memory safety and a myriad of other great correctness preserving qualities like Options, `unsafe {` and a high quality type system.
Not to mention that it is blazingly fast.
Not to mention that it is blazingly fast.
Yes, Rust is much easier to write and faster to learn than C++. This makes Rust better for many cases, but you can't really say it is more powerful.
C++ templates are hard to learn and understand, but they are one of the most powerful constructs we have in any programming language, I miss them when I work in other languages.
C++ templates are hard to learn and understand, but they are one of the most powerful constructs we have in any programming language, I miss them when I work in other languages.
This is a good point. Rust is better than C++ in many ways but when it comes to templates and compile time optimizations then its flipped and C++ is much better. The Rust trait system also feels pretty limited too.
Though as far as compile time templates go I think Nim templates generally meets or exceeds C++ templates in most areas. But I've become addicted to compile time type ducking, which is antithetical to Rust's vision of programming.
Though as far as compile time templates go I think Nim templates generally meets or exceeds C++ templates in most areas. But I've become addicted to compile time type ducking, which is antithetical to Rust's vision of programming.
Rust is literally designed to constrain what you can do much more tightly than C(++)/Python/Lisp. That's basically the opposite of the common definition of "freedom".
You can argue that what you give up in exchange for this freedom is more valuable, but don't twist the definitions of words.
You can argue that what you give up in exchange for this freedom is more valuable, but don't twist the definitions of words.
> That's basically the opposite of the common definition of "freedom".
It depends on which "common definition" you're working from. To make an analogy, both GPL advocates and MIT/BSD license advocates argue that their conception of freedom is "more free."
Rust is closer to the GPL here. By limiting certain things that you can do, you are free to do things that would be harder if you're allowed to do anything. The canonical example here is Stylo; the project was attempted with C++ multiple times, but was too buggy. But Rust's restrictions allowed the Rust version to succeed. You can argue it both ways: Rust limits certain kinds of code patterns (outside of unsafe, of course...) but that may enable you to do things that were too hard to do when there were no safeguards.
(A more generalized version of this debate is the distinction between "positive liberty" and "negative liberty," this debate transcends software.)
It depends on which "common definition" you're working from. To make an analogy, both GPL advocates and MIT/BSD license advocates argue that their conception of freedom is "more free."
Rust is closer to the GPL here. By limiting certain things that you can do, you are free to do things that would be harder if you're allowed to do anything. The canonical example here is Stylo; the project was attempted with C++ multiple times, but was too buggy. But Rust's restrictions allowed the Rust version to succeed. You can argue it both ways: Rust limits certain kinds of code patterns (outside of unsafe, of course...) but that may enable you to do things that were too hard to do when there were no safeguards.
(A more generalized version of this debate is the distinction between "positive liberty" and "negative liberty," this debate transcends software.)
Yeah Rust forces your program to use certain patterns. But in return, other users can assume those patterns exist. In result, Rust is one of the best programming languages to do refactorings in that exist. You are less free to write code that can be refactored badly, you are more free to do refactors. A sensible trade in my opinion.
Rust is literally designed with the `unsafe` keyword that tells the compiler: "hey you won't be to prove this is correct, but I'm going to do it anyway, don't check it".
The restrictions merely apply to provably correct code.
I'm not sure how telling the compiler to disable the safety features so you can do your thing is unbearably limiting.
The restrictions merely apply to provably correct code.
I'm not sure how telling the compiler to disable the safety features so you can do your thing is unbearably limiting.
Indeed, but in a similar manner, lisp restricts you out of the low level architecture, and you operate in a higher free-er plane where most ideas will work fine. Rust constraints are mostly liberating because you're safe to assume things will work.
Interesting. In my experience, seasoned C++ programmers grasp the advantages of Rust very quickly. Not all of them are convinced that the advantages outweigh the practical problems, but they don't deny the existence of the advantages.
I would have said C is firmly a Blub, though.
I would have said C is firmly a Blub, though.
I’m a C++ guy from back in the 90’s CFront days.
I love Rust; I’d do any new project in Rust instead of C++.
It’s worth the effort to learn.
I love Rust; I’d do any new project in Rust instead of C++.
It’s worth the effort to learn.
How did it affect your coding ? do you use different patterns / idioms ? are you more ambitious due to less bugs ? do you design / prototype differently ?
I think it's both. I remember reading at one point (not sure if it was quote or speculation) that the difference is C++ adds a lot of abstractions that:
- Have hidden costs
- Have sneaky failure-modes
C just... doesn't add any abstractions. And then Rust adds abstractions, but makes a concerted effort to avoid ones that have these two problems
- Have hidden costs
- Have sneaky failure-modes
C just... doesn't add any abstractions. And then Rust adds abstractions, but makes a concerted effort to avoid ones that have these two problems
Rust is significantly better than C++. And I say that as somebody who has done many years of C++ development.
I love that it draws so many different types. I'm a Python/JS/Go programmer historically. Rust is closer to Go to me. Of course it's not Go, but i'm far from a migrating C/C++ dev. Hell i only know a pinch of C++ from when i was first learning the trade.
I always had the impression Linus saw C++ as C but more complicated/worse. Rust is DIFFERENT by creating guarantees that are harder to get around and if you do try by using the functionality available in unsafe blocks it is clear as day to anyone and everyone who looks at the code.
My view is he's being pragmatic. Why switch from C to C++? The expected value from such a change isn't worth the effort.
Rust though? That could make the kernel more secure in the long-term and rule out a whole class of bugs. This makes sense.
Rust though? That could make the kernel more secure in the long-term and rule out a whole class of bugs. This makes sense.
I think the main point is Rust takes much less time to learn to be able to contribute to a complex code base at the caliber of Linux. With safe abstraction on top of unsafe, the seasoned/guru developers can build building blocks for intermediate/beginner to confidently use and contribute on the higher level.
I think a lot of it comes from the fact that he realizes there is a demand for kernel maintainers in the future and the C expertise isn't there as well. If you can get maintainers to come in that are Rust devs then they can work on things without introducing significant issues due to some of the default safety guarantees and guardrails that Rust provides while at the same time having approximate to near performance parity
> Guess I should start my 5th attempt at finally getting good at Rust.
The thing that finally made Rust click for me was doing a usb HID project. Suddenly all the machinery around ownership and multi-threading made sense and I was able to get things done, and I could suddenly also do all the things I previously attempted to do in Rust.
The thing that finally made Rust click for me was doing a usb HID project. Suddenly all the machinery around ownership and multi-threading made sense and I was able to get things done, and I could suddenly also do all the things I previously attempted to do in Rust.
>Guess I should start my 5th attempt at finally getting good at Rust.
I guess i should do the same too but I have really and man the language is not easy to grok. These days it also feels like if you don't know Rust, you are somewhat "old school".
I guess i should do the same too but I have really and man the language is not easy to grok. These days it also feels like if you don't know Rust, you are somewhat "old school".
> significantly better than C++
You say that like there’s some scalar measure of “better”.
You say that like there’s some scalar measure of “better”.
Surely it's implied in context that this is better for developing the Linux kernel, by Linus and Linux kernel developers ?
Sounds like Torvalds is taking a measured and pragmatic approach. Which is the only thing that will work. Kudos for taking it slow, allowing maintainers to opt out until the integrations are more proven, and resisting the urge to rush such a huge change. If anything, Linus is moving very rapidly, given that Rust still requires unstable features to work with the kernel.
I have a number of negative stereotypes associated with Rust and Rust programmers that I am trying to set aside right now and just look at this from a technical perspective. Has the Rust-portability situation been addressed? Or will this change restrict the number of platforms the Linux kernel will be usable on? Assuming that is the case (I remember reading that GCC will acquire Rust support), what will the advantages be? I would guess stability might improve due to more static analysis, but what about performance? Build-time? And will this have any effect on Rust?
Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless, if you only want C-written work, you're no worse off.
The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc.
As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development.
The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.
The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.
The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc.
As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development.
The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.
The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.
> The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases.
Do you have a link to some of the discussion around this? I'm curious to hear what kernel devs thought of the driver and how it was introduced to them. Is there a talk about it? Or mailing list archives? (Or both?)
Do you have a link to some of the discussion around this? I'm curious to hear what kernel devs thought of the driver and how it was introduced to them. Is there a talk about it? Or mailing list archives? (Or both?)
From the Linux Plumbers Conference from a couple days ago: https://www.youtube.com/watch?v=Xw9pKeJ-4Bw&t=8040s (Warning: It's a longer stream, but the timestamp should be where the driver is shown. There's a table of contents down in the comments.)
I was very put off from Rust because of the people acting out those stereotypes that I've encountered whenever the topic comes up. But then I decided to just learn it (partially driven by work requirements), and it's honestly great. I don't think we should be rewriting a ton of software just because there's better compiler-level safeguards, but it does make it much harder to shoot yourself in the foot without realizing it. There's some issues, dynamic linking isn't really supported. I've had good luck with various embedded targets, having trialed STM32F4s, RP2040, ESP32-C3, and am waiting on getting an NRF52840. Surprisingly, the ESP32-C3 is the best out of the box experience I've had, but library support is just not there.
IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.
IMO Rust is a really good language, and it deserves it's place in the toolbelt of most systems programmers. It's not always the right choice, but it's usually a good choice.
> But then I decided to just learn it (partially driven by work requirements), and it's honestly great.
I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use. It's not even close to mature enough to consider using except for test projects. It doesn't fix programmer errors despite every rust user trying to convince me otherwise that all imported crates are perfect.
I like the idea of the language somewhat but the entire ecosystem ruins it for me.
I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use. It's not even close to mature enough to consider using except for test projects. It doesn't fix programmer errors despite every rust user trying to convince me otherwise that all imported crates are perfect.
I like the idea of the language somewhat but the entire ecosystem ruins it for me.
> I did for work as well and in my case I do not want to touch it again for quite a while. Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use
I've encountered none of this. Of course Cargo is going to have broken libs, it's just a package repo like npm, pypi (+ pip), etc.. The differences between "editions" is pretty large, but I haven't seen much reason to not use the latest release in most cases. The tooling out there is very good at supporting multiple toolchains simultaneously (though, not in the same project, necessarily).
> It doesn't fix programmer errors despite every rust user trying to convince me otherwise
No engineer who knows what they're talking about will ever say this. You're either spewing lies or are believing the words of people who have no idea what they're talking about, neither of which are good. Rust helps prevent a specific class of memory errors that are very common in C (and to a lesser extent, C++). It still gives you the `unsafe` escape hatch that lets you do almost anything you can do in C.
> It's not even close to mature enough to consider using except for test projects.
Our production hard-realtime control system begs to differ.
I've encountered none of this. Of course Cargo is going to have broken libs, it's just a package repo like npm, pypi (+ pip), etc.. The differences between "editions" is pretty large, but I haven't seen much reason to not use the latest release in most cases. The tooling out there is very good at supporting multiple toolchains simultaneously (though, not in the same project, necessarily).
> It doesn't fix programmer errors despite every rust user trying to convince me otherwise
No engineer who knows what they're talking about will ever say this. You're either spewing lies or are believing the words of people who have no idea what they're talking about, neither of which are good. Rust helps prevent a specific class of memory errors that are very common in C (and to a lesser extent, C++). It still gives you the `unsafe` escape hatch that lets you do almost anything you can do in C.
> It's not even close to mature enough to consider using except for test projects.
Our production hard-realtime control system begs to differ.
> Cargo is a terrible system with all kinds of hidden and possible broken dependencies you introduce and everything depends highly on the version of rust you use.
Can you give a concrete example of this?
Can you give a concrete example of this?
What language and ecosystem do you like using? I'm curious as to what ecosystem isn't terrible unless it's just C with vendored dependencies.
> dynamic linking isn't really supported
This is one of my few big gripes with Rust too, but it should be pointed out that it's dynamic linking with other Rust code that isn't really supported. Dynamic linking with e.g. C libraries is a breeze.
This is one of my few big gripes with Rust too, but it should be pointed out that it's dynamic linking with other Rust code that isn't really supported. Dynamic linking with e.g. C libraries is a breeze.
You can of course link with Rust code that exports a pure C ABI. Such code works just like a shared library coded in C/C++.
I'm not sure how useful that would be since people pin specific version of libraries with Rust. They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken.
Part of the discipline of writing C++ and C libraries is writing around a stable interface, that you can link against. In C++ that means using the pImpl pattern.
Part of the discipline of writing C++ and C libraries is writing around a stable interface, that you can link against. In C++ that means using the pImpl pattern.
> They don't care about ABI stability so even if you could just update links to a library, the interface would be horribly broken.
Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.
Which is, of course, the actual gripe we're discussing. The lack of dynamic linking is just a consequence.
If there's an exploit/problem in, say, a crypto library, Rust's ecosystem seems less resilient. Instead of just updating the library system wide, you have to get everyone to rebuild their applications with a safe version of the library (if it's even possible).
This has happened and will absolutely happen again. Just being "memory safe" will not prevent protocol errors, bad IVs, preventing timing attacks, or the other subtle things involved when doing cryptography on the wider internet.
This has happened and will absolutely happen again. Just being "memory safe" will not prevent protocol errors, bad IVs, preventing timing attacks, or the other subtle things involved when doing cryptography on the wider internet.
On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once)
There's a huge list of tradeoffs between dynamic and static linking, and Rust is betting that in today's world, with modern tooling, internet availability, hardware speeds, and memory size, the benefits of static linking outweigh the costs. I guess time will tell
But- traditionally Linux has really leaned into the opposite approach, so it'll be interesting to see how that dissonance plays out, and whether one or both is forced to compromise, as Rust gets more embedded in the Linux ecosystem
There's a huge list of tradeoffs between dynamic and static linking, and Rust is betting that in today's world, with modern tooling, internet availability, hardware speeds, and memory size, the benefits of static linking outweigh the costs. I guess time will tell
But- traditionally Linux has really leaned into the opposite approach, so it'll be interesting to see how that dissonance plays out, and whether one or both is forced to compromise, as Rust gets more embedded in the Linux ecosystem
> On the other hand- crates.io + the toolchain make it way easier for fixes to propagate outward into the ecosystem, and then for new builds to be created with them (even for multiple platforms at once)
As a Rust fan who subscribes to the classical Linux distro model (and even exclusively gets his Rust crates from there), I disagree. What you suggest comes with a cost, namely having to accept software in constant flux. To me, that cost in unacceptably big.
I write a bit more about this gripe here: https://news.ycombinator.com/item?id=32925491
As a Rust fan who subscribes to the classical Linux distro model (and even exclusively gets his Rust crates from there), I disagree. What you suggest comes with a cost, namely having to accept software in constant flux. To me, that cost in unacceptably big.
I write a bit more about this gripe here: https://news.ycombinator.com/item?id=32925491
I wholeheartedly agree. It's the one worry I have with a language that I otherwise love.
(Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)
(Of course the problem is technically hard, or possibly unsolvable, so I don't blame the Rust folks for its existence.)
> Has the Rust-portability situation been addressed?
The rust portability story is in the process of being addressed, by two different projects:
gcc-rs[0] adds a Rust frontend to GCC.
rustc-codegen-gcc[1] adds a GCC backend to rustc.
Both are progressing pretty well, but it will likely still take a while until they reach maturity.
> Or will this change restrict the number of platforms the Linux kernel will be usable on?
There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature.
> what will the advantages be?
There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely).
As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations.
[0]: https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/
[1]: https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/
The rust portability story is in the process of being addressed, by two different projects:
gcc-rs[0] adds a Rust frontend to GCC.
rustc-codegen-gcc[1] adds a GCC backend to rustc.
Both are progressing pretty well, but it will likely still take a while until they reach maturity.
> Or will this change restrict the number of platforms the Linux kernel will be usable on?
There won't be any Rust inside the Linux core, only for drivers. So no, the linux kernel will always be usable on all platforms. However, the drivers written in Rust won't be usable on platforms not supported by LLVM until a GCC alternative becomes mature.
> what will the advantages be?
There are multiple: Safety, improved stability, and developer productivity. Compile time will likely take a hit (Rust is famously slow to compile), but I don't expect a big shift in runtime performance (could be slightly better due to the extra opportunities the compiler has for optimization, but it's not super likely).
As for having any effects on Rust: it already has! A lot of unstable features got prioritized due to being necessary for the kernel, such as fallible allocations.
[0]: https://github.com/Rust-GCC/gccrs - monthly reports at https://thephilbert.io/category/gccrs-status-updates/
[1]: https://github.com/rust-lang/rustc_codegen_gcc - monthly reports at https://blog.antoyo.xyz/
There are two in flight projects to bring GCC to Rust: gccrs and rustc_codegen_gcc. These both seem to be making good progress. Otherwise, right now Rust is only being included for drivers, so doesn't have as many portability concerns.
What are the negative stereotypes you associate with Rust and Rust programmers?
The belief that the problem of memory safety that Rust has some compile-time protections against is the only problem (or so much more important problem that the rest almost don’t matter) of programming, and that therefore Rust is the only sane choice to use for any project. There’s a reason that memes like “Rust Evangelism Strike Force” exist.
That’s the biggest one, anyway. I picked up Rust for the first time 8 years ago. I liked it: it felt comfortable in my “worn” C++ hands. But the community outside of a very few core individuals who care deeply about the language’s success can be quite toxic and dismissive of anyone who suggests Rust isn’t basically perfect. And it was a bit of a turn off for me, personally.
That’s the biggest one, anyway. I picked up Rust for the first time 8 years ago. I liked it: it felt comfortable in my “worn” C++ hands. But the community outside of a very few core individuals who care deeply about the language’s success can be quite toxic and dismissive of anyone who suggests Rust isn’t basically perfect. And it was a bit of a turn off for me, personally.
Uh, what? I’ve found Rust as a project and community to be a very self criticizing group - they know when they’ve got it wrong.
They’re simply right about one core thing and they’re loud about it when it comes up. Until something proves them wrong and steals their thunder… I don’t know what to tell you.
They’re simply right about one core thing and they’re loud about it when it comes up. Until something proves them wrong and steals their thunder… I don’t know what to tell you.
In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe and everyone should migrate to Rust. They might not represent everyone from Rust but that is the part of the Rust community that the C++ community sees the most.
Not sure what to do about that really, but I think it caused many C++ programmers to hate the language before they even tried it.
Not sure what to do about that really, but I think it caused many C++ programmers to hate the language before they even tried it.
> In every C++ thread here on HN I've read the past few years there are always some people saying that C++ is unsafe
Experience shows that memory safety issues are the most common cause of security issues.
Microsoft:
>As we’ve seen, roughly 70% of the security issues that the [Microsoft Security Response Center] assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated.
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
Google:
>Roughly 70% of all serious security bugs in the Chrome codebase are memory management and safety bugs, Google engineers said this week.
https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
Experience shows that memory safety issues are the most common cause of security issues.
Microsoft:
>As we’ve seen, roughly 70% of the security issues that the [Microsoft Security Response Center] assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated.
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
Google:
>Roughly 70% of all serious security bugs in the Chrome codebase are memory management and safety bugs, Google engineers said this week.
https://www.zdnet.com/article/chrome-70-of-all-security-bugs...
You clipped that quote, the aggravating part is where they say that everyone who writes C++ needs to migrate to Rust. Even if it is/was true that will still anger a lot of people when it get posted in every thread about C++.
That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety.
Microsoft:
>we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available.
First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead.
We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide.
When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible.
Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run. What this means for performance in terms of raw speed, control, and predictability, is that Rust, C, and C++ can be thought of in similar terms.
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
Microsoft:
>we’ll peek at why we think that Rust represents the best alternative to C and C++ currently available.
First, there are plenty of fantastic memory safe languages already available and widely used inside and outside of Microsoft, including .NET languages like C# or F# and other languages like Swift, Go, and Python. We encourage anyone who is currently using C or C++ to consider whether one of these languages would be appropriate to use instead.
We, however, are talking about the need for a safe systems programming language (i.e., a language that can build systems other software runs on, like OS kernels). Such workloads need the speed and predictable performance that C, C++, and Rust provide.
When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ — namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible.
Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run. What this means for performance in terms of raw speed, control, and predictability, is that Rust, C, and C++ can be thought of in similar terms.
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...
> That doesn't excuse downplaying the security issues so common when using languages that do not offer memory safety.
Sure thing but can Rust live up to its memory-safety promise? Or even data-race freedom promise?
I must say that, coming from systems programming background, I was always skeptical about those promises because IMO these problems fundamentally cannot be solved in bare-metal programming language. They're implied by the complexity of HW not loop-holes in programming languages.
That said I see nothing wrong with Rust but I think that people are vastly overselling its core features while at the same time a quick glance over https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust will give you exactly a list of bugs which Rust seems to promise not to run into.
Another very recent example, and a very good blog post about memory corruption taking place in Rust: https://www.graplsecurity.com/post/attacking-firecracker
Sure thing but can Rust live up to its memory-safety promise? Or even data-race freedom promise?
I must say that, coming from systems programming background, I was always skeptical about those promises because IMO these problems fundamentally cannot be solved in bare-metal programming language. They're implied by the complexity of HW not loop-holes in programming languages.
That said I see nothing wrong with Rust but I think that people are vastly overselling its core features while at the same time a quick glance over https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust will give you exactly a list of bugs which Rust seems to promise not to run into.
Another very recent example, and a very good blog post about memory corruption taking place in Rust: https://www.graplsecurity.com/post/attacking-firecracker
That's not a good reason to hate Rust, in my opinion. The community around it, maybe (although "hate" is a strong word), but not the language.
I have a word in mind, but before that I would ask: what are some safety-critical systems written in Rust? If there are any, how big a role does Rust play in their safety properties? Is it much different from any other programming language?
I can already hear faint exclamations about the language's age, but are Rust programmers justified in putting forward claims about safety? Or do they shift to using the word in the sense of "fewer bugs in this particular class" (and nevermind any other effects the language may have on development).
Even if we take such a narrow and distorting view of "safety", we can look at, say, "The Power of Ten" and ask how does Rust use fare with each rule, and is it any more advantageous than other languages in use by safety-critical systems.
I can already hear faint exclamations about the language's age, but are Rust programmers justified in putting forward claims about safety? Or do they shift to using the word in the sense of "fewer bugs in this particular class" (and nevermind any other effects the language may have on development).
Even if we take such a narrow and distorting view of "safety", we can look at, say, "The Power of Ten" and ask how does Rust use fare with each rule, and is it any more advantageous than other languages in use by safety-critical systems.
I don't think anyone ever said it was completely safe. This is a pre-conception on the part of the critics. Every Rust resource I looked at stated that the toolset exists to support inherent safety, but there is still a contract with the programmer that requires them to know what they are doing.
Rust is "safe" and other languages are "unsafe". Haskell is "pure" while other language are "impure". Some macro systems are "hygienic" while others are "dirty". It is not an accident that the humpty dumpties (language designers) chose to use these particular terms for their semantic distinctions. It's useful for propaganda. The mind encounters a colloquial term and equivocates. This happens in both the critics and the evangelizers. Inferences drawn are then often unjustified.
Agreed, it does appear to be heavily sponsored and marketed. And you are correct that these pre-conceptions affect advocates as well! But I think the push for wide-scale acceptance is not unreasonable. If it is completely necessary I suppose only will be known sometime in the future.
I'm curious what caused you to be so annoyed with the language that you had to create a user name out of it :)
From my experience, the stereotype is that they are very positive within their own community, very loud and negative towards anything not in the Church of Rust. Of course, this doesn’t fit most Rust programmers, most I’ve met are great people and developers, it’s just the loud people getting the attention.
The simple fact that they call themselves rustaceans and evangelize the language. It feels the language spread via a religious uprising rather than merit of making good programs easy to write.
Ahh yes. Unlike the pythonistas, the gophers, the ziguanas, the lispers, the perl monks, ...
Being put off by the evangelizing I can certainly understand – but surely the name "rustaceans" is just some innocent humor.
In order to be one of the cool kids you have to identify as one. From my point of view the self identifying and adopting a title is key to the indoctrination process.
> In order to be one of the cool kids you have to identify as one.
You really don't? Every time I read a comment like this, I think, "Who hurt you?"
You really don't? Every time I read a comment like this, I think, "Who hurt you?"
I like Rust the language, and i have found most people in the community to be smart and reasonable. But i also find "Rustaceans" to be rather cringe. I don't think it's specific to Rust; i think this need to form a visible community identity, a brand really, is very common in Silicon Valley culture. Hence why most startups there have cutesy names for employees, people go round sticking logos of software they use on their laptops, etc.
The crab is cool though. As language mascots go, it's a lot more adorable than the Gopher or that LISP alien thing, and almost as adorable as Bjarne Stroustrup.
The crab is cool though. As language mascots go, it's a lot more adorable than the Gopher or that LISP alien thing, and almost as adorable as Bjarne Stroustrup.
I love Rust, it's the most fun I've had programming since first discovering the concept as a kid, with the possible exception of the time I was enamored with Haskell. But one stereotype that I've faced a lot is in connection with the ecosystem. In particular, if you're not satisfied with "rustup everything, then let cargo pull all your deps from crates.io, it just works" as a way of work, you'll sadly face quite a bit of hostility from parts of the community. Seriously; a programming language or its community shouldn't dictate how I assemble and build code! Luckily there are exceptions, and more importantly, the toolchain and ecosystem seem to be getting better in these regards all the time.
Still love the language though, and in general the community is very friendly and welcoming (if not always open to criticism).
Still love the language though, and in general the community is very friendly and welcoming (if not always open to criticism).
Rust community is nice until you use unsafe.
More seriously, the number of peoples you can have a sane discussion about unsafe use is quiet low because when you need to use unsafe is because of a complicate/hard to explain/understand problem.
This combined with the (99% of the time valid) safety dogmas brings some to instantly tell you how to not use unsafe with blatantly bad workaround without considering why you _would_ use unsafe at the first place.
This safety/anti-unsafe dogma makes some peoples far too vocal.
I consider Rust community to be nicer with time, seriously, but I can't say this "I don't understand your problem, but I saw a unsafe, here is a code that doesn't use unsafe" is not a thing. Of course, it's changing, because Rust is more widely use, and "here is when you need unsafe" patterns are emerging. As a Rust user, I'm happy.
More seriously, the number of peoples you can have a sane discussion about unsafe use is quiet low because when you need to use unsafe is because of a complicate/hard to explain/understand problem.
This combined with the (99% of the time valid) safety dogmas brings some to instantly tell you how to not use unsafe with blatantly bad workaround without considering why you _would_ use unsafe at the first place.
This safety/anti-unsafe dogma makes some peoples far too vocal.
I consider Rust community to be nicer with time, seriously, but I can't say this "I don't understand your problem, but I saw a unsafe, here is a code that doesn't use unsafe" is not a thing. Of course, it's changing, because Rust is more widely use, and "here is when you need unsafe" patterns are emerging. As a Rust user, I'm happy.
> the number of peoples you can have a sane discussion about unsafe use is quiet low
There will always be outliers, but I actually think the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. See a really great discussion at: https://www.reddit.com/r/rust/comments/we91es/good_example_o...
Just some anec-data, but I had some benchmark code which was unsafe (indexing into an array of bytes, no UTF8 validation), that I wanted to rewrite as safe (by leaning on the std lib, so plenty of unsafe under the hood) just to see how much slower it would be, and the code ended up being ~20-30% faster. Sometimes the unsafe patterns we bring with us just don't match the Rust model.
There will always be outliers, but I actually think the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue. See a really great discussion at: https://www.reddit.com/r/rust/comments/we91es/good_example_o...
Just some anec-data, but I had some benchmark code which was unsafe (indexing into an array of bytes, no UTF8 validation), that I wanted to rewrite as safe (by leaning on the std lib, so plenty of unsafe under the hood) just to see how much slower it would be, and the code ended up being ~20-30% faster. Sometimes the unsafe patterns we bring with us just don't match the Rust model.
> the Rust community has done a really great job around discussing unsafe in the years since the actix-web issue.
I agree, I started Rust before this drama (I wouldn't call that an _issue_, it was the whole culture that goes wrong here), now peoples try to understand why you need unsafe, but it hasn't been the case and for _years_ it was almost impossible. actix-web is the pivot point but the simple fact you need a sad situation like this show how crazy the safety discussions were before, really.
Once again: Things are changing and I'm more than happy to see pragmatism in the Rust community. But you can't behave like all of this didn't happens.
> Sometimes the unsafe patterns we bring with us just don't match the Rust model.
I agree and noticed this too in some cases (compiler does miracles), that's why discussions have to be serious.
I agree, I started Rust before this drama (I wouldn't call that an _issue_, it was the whole culture that goes wrong here), now peoples try to understand why you need unsafe, but it hasn't been the case and for _years_ it was almost impossible. actix-web is the pivot point but the simple fact you need a sad situation like this show how crazy the safety discussions were before, really.
Once again: Things are changing and I'm more than happy to see pragmatism in the Rust community. But you can't behave like all of this didn't happens.
> Sometimes the unsafe patterns we bring with us just don't match the Rust model.
I agree and noticed this too in some cases (compiler does miracles), that's why discussions have to be serious.
> now peoples try to understand why you need unsafe
I think that was always the case. actix is a singularly unique example, and I had never seen anything like it before or since. Not even close. There just hasn't been any Rust project with that kind of popularity that also contained egregiously unsound code. So we're not just talking about unnecessary use of unsafe here, but egregiously unsound usage of unsafe.
The attitude toward 'unsafe' has pretty much always been the same. Use it. It exists for a reason. But make sure it's justified and strive for soundness.
I think that was always the case. actix is a singularly unique example, and I had never seen anything like it before or since. Not even close. There just hasn't been any Rust project with that kind of popularity that also contained egregiously unsound code. So we're not just talking about unnecessary use of unsafe here, but egregiously unsound usage of unsafe.
The attitude toward 'unsafe' has pretty much always been the same. Use it. It exists for a reason. But make sure it's justified and strive for soundness.
i might be wrong but currently rustc is based on llvm so any platform llvm cant target, rust can target.
For the linux kernel it seems like they want to use a gcc frontend for rust (gccrs) that is currently under development. So with gccrs rust should be able to work on any platform gcc supports thus giving it the same portability of the current c code in the kernel.
jbirer(3)
Read the article, mentally replacing Rust with C++ (or terms like gccrs with g++). Interesting times for the kernel; you have to wonder whether Rust will be a success or if there will be a repeat of the 1992 attempt [1] to include C++.
[1]: http://harmful.cat-v.org/software/c++/linus
[1]: http://harmful.cat-v.org/software/c++/linus
Rust brings a lot more to the table than C++ does - it solves many of the "hard" problems, at compile time, that kernel developers have to constantly grok with. I have a feeling, that it'll not only do well in the Kernel, but may eventually become the preferred language.
Does anyone have good resources to learning rust? I have a fairly good working knowledge of C, C++, and Swift.
I understand there's the Rust Book, Rustlings, and Rust By Example at https://www.rust-lang.org/learn. Are there other good resources? Does anyone have a strong suggestion on which of those official resources I should start with?
I understand there's the Rust Book, Rustlings, and Rust By Example at https://www.rust-lang.org/learn. Are there other good resources? Does anyone have a strong suggestion on which of those official resources I should start with?
Start with the Rust book. Then "Rust for Rustaceans" by John Gjengset is a fantastic resource to learn about more than just the basics. He posts hour long videos on his youtube where he explains the concepts that he mentions in his book. I found that reading a chapter and then watching one of his videos really taught me about /why/ the language is as it is, rather than just learning to get the compiler to be happy. (It also includes chapters about API design and what to look out for if you are going to publish your own crate)
> Does anyone have a strong suggestion on which of those official resources I should start with?
The rust book. Reading it start to finish provides a very good basis.
And if you're tempted to "learn by doing" with the usual linked lists, go and read "learning rust with entirely too many linked lists": https://rust-unofficial.github.io/too-many-lists/
Rust has enough rare or novel concepts that trying to learn on the job with no book learning whatsoever is really reserved for the rarefied few. Though I understand that a lot of C and C++ concepts port quite easily, it also differs from those languages (especially C++ for advanced features) that doing a bit of a reset will avoid future pains e.g. Rust's concepts of copy, move, references, ... are very different from C++'s and going in half-cocked will be frustrating.
The rust book. Reading it start to finish provides a very good basis.
And if you're tempted to "learn by doing" with the usual linked lists, go and read "learning rust with entirely too many linked lists": https://rust-unofficial.github.io/too-many-lists/
Rust has enough rare or novel concepts that trying to learn on the job with no book learning whatsoever is really reserved for the rarefied few. Though I understand that a lot of C and C++ concepts port quite easily, it also differs from those languages (especially C++ for advanced features) that doing a bit of a reset will avoid future pains e.g. Rust's concepts of copy, move, references, ... are very different from C++'s and going in half-cocked will be frustrating.
If you‘re willing to spend money on a great book that teaches you all the basics of Rust, I can only recommend Programming Rust, 2nd edition (OReilly). It includes tons of examples, code snippets and is also a good resource for looking up stuff once you‘re done reading it. It also includes many passages comparing C++ with Rust, so that might be useful for you.
It‘s a great book for anyone, who already knows a few programming languages. Programming beginners, should look elswhere tho.
A few things. The hardest thing about Rust is to forget many of tthe paradigms or aesthetical ideas other languages hammered into your brain. Programming Rust like you would program Python, Javascript or C++ is going to give you a hard time, but each time in a different way. If you program Rust in the Rust way, suddenly things become easy.
That means what the best way to start is depends on your background. In my eyes you can do nothing wrong with going through the rust book you already mentioned. Having read 4 different Rust books I have to say this introduction in combination with "Programming Rust" by Jim Blandy, Jason Orendorff, Leonora F. S. Tindall is probably the best way to get started. https://www.oreilly.com/library/view/programming-rust-2nd/97...
That means what the best way to start is depends on your background. In my eyes you can do nothing wrong with going through the rust book you already mentioned. Having read 4 different Rust books I have to say this introduction in combination with "Programming Rust" by Jim Blandy, Jason Orendorff, Leonora F. S. Tindall is probably the best way to get started. https://www.oreilly.com/library/view/programming-rust-2nd/97...
So, with "good working knowledge" of C++ and Swift, you probably aren't going to have too much trouble with the basics, if anything you might worry that there's some subtlety which you're missing when actually nope, whatever just seemed easy maybe actually was that easy.
[ For example move really is as simple as Rust makes it look, it is a headache in C++ because they added it to a finished working language ]
Several people suggested books/ web pages let me suggest some videos:
Jon Gjengset's "Crust of Rust" Youtube videos are good once you reach the point where you can write more than "Hello, world!" with some confidence but certain specific things aren't clicking.
https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...
For example, Jon does a whole video on lifetime annotations, which are something you won't see in most popular languages, but also one on Rust's iterators, which are a familiar concept from both C++ and Swift but don't work quite like either (they're very different from C++ iterators, your Swift experience will help more).
I recommend watching specifically a handful on topics you don't feel you understood well, although you could watch all of them especially if you just enjoy Jon's style and have the free time. They're not fast paced, if you wanted "Rust in 60 minutes" this is not that, but each one is actually writing carefully chosen code that runs and talking through what's going on, not just clicking through slides.
[ For example move really is as simple as Rust makes it look, it is a headache in C++ because they added it to a finished working language ]
Several people suggested books/ web pages let me suggest some videos:
Jon Gjengset's "Crust of Rust" Youtube videos are good once you reach the point where you can write more than "Hello, world!" with some confidence but certain specific things aren't clicking.
https://www.youtube.com/watch?v=rAl-9HwD858&list=PLqbS7AVVEr...
For example, Jon does a whole video on lifetime annotations, which are something you won't see in most popular languages, but also one on Rust's iterators, which are a familiar concept from both C++ and Swift but don't work quite like either (they're very different from C++ iterators, your Swift experience will help more).
I recommend watching specifically a handful on topics you don't feel you understood well, although you could watch all of them especially if you just enjoy Jon's style and have the free time. They're not fast paced, if you wanted "Rust in 60 minutes" this is not that, but each one is actually writing carefully chosen code that runs and talking through what's going on, not just clicking through slides.
I think there's a missing book - 'Thinking In Rust'. The mechanics of borrow-checking, lifetimes, std lib, tokio can all be learned quite quickly. It's the muscle memory of techniques and design patterns that takes the longest to re-learn.
As you already know C and C++ this one is great: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/sh...
Just go through everything in "3 Syntax and Semantics" and "4 Effective Rust", you already know how to program C and C++ so that is all you should need to know. Took me a few days.
Just go through everything in "3 Syntax and Semantics" and "4 Effective Rust", you already know how to program C and C++ so that is all you should need to know. Took me a few days.
This is my journey so far:
(1) Go through the Rust Book,
(2) Do "exercises" (small side projects, advent-of-code, rustlings. ..etc),
(3) Go through "Rust for Rustaceans". It's specifically targetted at "intermediate Rust developers". If you have "good working knowledge" of C and C++, I will wager that you will absolutely love this book, because, to me, (1) it explained so much of Rust's design choices, and (2) you will learn so much so quickly.
(1) Go through the Rust Book,
(2) Do "exercises" (small side projects, advent-of-code, rustlings. ..etc),
(3) Go through "Rust for Rustaceans". It's specifically targetted at "intermediate Rust developers". If you have "good working knowledge" of C and C++, I will wager that you will absolutely love this book, because, to me, (1) it explained so much of Rust's design choices, and (2) you will learn so much so quickly.
I learned it combining the Book and Rustlings. There's a table in the exercises directory mapping the exercises to the chapters of the book, so I'd every day do the exercises for yesterdays chapter first before todays chapter to have some sort of spaced repetition. For more material, check out https://github.com/jondot/rust-how-do-i-start
I started with the book to learn the fundamentals. I didn't get very far before I decided to rewrite an existing API I had in Python into Rust.
It definitely took some time and learning but now I have 6 Rust API microservices, a few scheduled/queue-reading services, and a shared library for common models/utils/providers.
It definitely took some time and learning but now I have 6 Rust API microservices, a few scheduled/queue-reading services, and a shared library for common models/utils/providers.
I enjoyed the rustlings puzzles. They reference the book a lot, and I tend to learn better by doing (at least a little bit of doing).
I appreciate the write-up representing the flow of discussion, not just the outcome, for the insight it carries about how decisions move through the group.
It appears Linus has said it is happening, and a bit how it should happen, but has not given strong guidance or even parameters on how long any experiment would last.
Instead, he says the maintainers can decide to accept or reject or use Rust however they like. He doesn't even say they should state their policy, so they can let people try and still reject them.
Giving maintainers the ultimate discretion I think tracks the incentive system in the kernel: maintainers, who do boatloads of work, get to be deciders. That also gives companies a strong incentive to employ maintainers.
On the tools front, Linus expressly said he wants not just an anointed compiler on kernel.org, but compilers from the distributors. He's driving Rust normalization and platform adoption as a condition of use, even though the kernel historically adopts a fairly narrow (if not archaic) set of tools.
Somehow this all seems like a bunch of rafts tied together with (platform) boats pushing at the edges -- somewhat tenuous, hard to drive, but vaguely heading in the right direction.
As others have mentioned, it's interesting that Linus and many maintainers are getting older, and instead of getting freedom and flexibility in their maturity, they can look forward to more low-level bouts of increasing complexity. When they talk about the integration of Rust, they're clearly anticipating it might not fully happen until after they're gone. That, too, could change the incentives.
It appears Linus has said it is happening, and a bit how it should happen, but has not given strong guidance or even parameters on how long any experiment would last.
Instead, he says the maintainers can decide to accept or reject or use Rust however they like. He doesn't even say they should state their policy, so they can let people try and still reject them.
Giving maintainers the ultimate discretion I think tracks the incentive system in the kernel: maintainers, who do boatloads of work, get to be deciders. That also gives companies a strong incentive to employ maintainers.
On the tools front, Linus expressly said he wants not just an anointed compiler on kernel.org, but compilers from the distributors. He's driving Rust normalization and platform adoption as a condition of use, even though the kernel historically adopts a fairly narrow (if not archaic) set of tools.
Somehow this all seems like a bunch of rafts tied together with (platform) boats pushing at the edges -- somewhat tenuous, hard to drive, but vaguely heading in the right direction.
As others have mentioned, it's interesting that Linus and many maintainers are getting older, and instead of getting freedom and flexibility in their maturity, they can look forward to more low-level bouts of increasing complexity. When they talk about the integration of Rust, they're clearly anticipating it might not fully happen until after they're gone. That, too, could change the incentives.
I believe that in 10 years, we'll look back at Rust in the kernel and see it as a big disaster. Some people will blame the kernel team (they didn't adopt Rust well enough), and some will blame Rust itself (writing a non-toy kernel in it hasn't been tried before).
But heck, we should TRY it. So I'm glad this is finally happening.
But heck, we should TRY it. So I'm glad this is finally happening.
Rust covers an infinitesimal footprint of the C/C++ code out there running the world. Rust won't replace anything substantial or meaningful in the embedded world for the time being.
I would say that that statement is a tautology of any new language and was true also of C and C++ when they were respectively introduced.
If this happens, and it seems inevitable at the moment, I personally see this resulting in a potential decline of a Linux kernel in the next few years.
Just a few questions off top of my head:
* How much will it affect the development velocity? Existing devs (and maintainers) will at least need to learn how to read and debug Rust code. New devs will likely have no good competences in C which is 99% of the codebase so how good/quickly will they be able to blend in?
* How many existing kernel developers will community potentially loose because of the increased complexity?
* How much new talent will it actually be able to attract? Now people will need to learn two completely different languages and their vastly different ecosystems.
* Does Rust have high enough entry bar to produce competent kernel developers? Sometimes high entry bar acts as a very good filter to end up in a pool with a highly skilled (and motivated) engineers.
* Coordination of development efforts is now going to become much more complex. This includes writing new features (C or Rust or both?), maintaining the old ones (rewrite pieces in Rust or not?) but also code-reviews which will now pose a bigger challenge given that it will consist of mixed Rust+C code.
Having worked in codebases which mixed C and C++, I already understand what kind of issues mixing C and Rust is going to produce. And I expect them to be much more accentuated because distance(C, C++) << distance(C, Rust).
Just a few questions off top of my head:
* How much will it affect the development velocity? Existing devs (and maintainers) will at least need to learn how to read and debug Rust code. New devs will likely have no good competences in C which is 99% of the codebase so how good/quickly will they be able to blend in?
* How many existing kernel developers will community potentially loose because of the increased complexity?
* How much new talent will it actually be able to attract? Now people will need to learn two completely different languages and their vastly different ecosystems.
* Does Rust have high enough entry bar to produce competent kernel developers? Sometimes high entry bar acts as a very good filter to end up in a pool with a highly skilled (and motivated) engineers.
* Coordination of development efforts is now going to become much more complex. This includes writing new features (C or Rust or both?), maintaining the old ones (rewrite pieces in Rust or not?) but also code-reviews which will now pose a bigger challenge given that it will consist of mixed Rust+C code.
Having worked in codebases which mixed C and C++, I already understand what kind of issues mixing C and Rust is going to produce. And I expect them to be much more accentuated because distance(C, C++) << distance(C, Rust).
Whatever happened to that effort to write a QNX-compatible kernel in Rust. The QNX kernel is tiny. That should be working by now.
That's what you really want in Raspberry Pi sized projects.
That's what you really want in Raspberry Pi sized projects.
For those with better understanding of where zig is at, why not zig for kernel development? Is it merely because it's still in heavy dev?
I think the answer to your question is also the answer to the question of how Zig achieves memory safety at compile time.
Yeah, Rust is C with a sane version of C++'s RAI, Zig is C with a sane version of C++'s templates. Having Turing complete duck typed template metaprogramming is very fun and useful, but I understand why you wouldn't want that in huge security critical codebases.
I love this, but also very surprised Trovalds is ok with a language that changes so much. But with git and all it maybe easier to manage just as if you would C89/99/11.
I always have reservations about clicking LWN "subscriber links" since I have not subscribed.
Perhaps it's worth waiting a week before posting these? LWN's paywall is dropped at that point.
Perhaps it's worth waiting a week before posting these? LWN's paywall is dropped at that point.
LWN folks are fine with subscriber links being posted here, they view it as a form of advertising and they get subscribers from it.
That is good to know. But I looked this up and what I've found is Jonathan Corbet saying in 2010 that "occasional" posting of subscriber links is fine.[1]
I am not Jonathan Corbet so I don't know what he considers occasional. But this is the fourth LWN subscriber link posted in the past 7 days, and the eighth in the past 14 days.[2]
For reference, LWN currently lists 10 paywalled posts, the oldest from 13 days ago.[3] Those posted on HN are nearly every paywalled article that they have.
[1] https://news.ycombinator.com/item?id=1966033
[2] https://hn.algolia.com/?dateEnd=1663790400&dateRange=custom&...
[3] https://lwn.net/
I am not Jonathan Corbet so I don't know what he considers occasional. But this is the fourth LWN subscriber link posted in the past 7 days, and the eighth in the past 14 days.[2]
For reference, LWN currently lists 10 paywalled posts, the oldest from 13 days ago.[3] Those posted on HN are nearly every paywalled article that they have.
[1] https://news.ycombinator.com/item?id=1966033
[2] https://hn.algolia.com/?dateEnd=1663790400&dateRange=custom&...
[3] https://lwn.net/
Agreed, the number of subscriber links is kind of high. If it still gets them extra subscribers, then probably its ok. I guess they are monitoring the numbers on that.
In that case, why not subscribe? It's not expensive (they even have tiered subscription levels...) and it's awesome.
> In that case, why not subscribe?
Not the OP, but a possible reason: not all people have credit cards. In fact, the very first thing I did once I finally decided to get a credit card (which, frankly, is only really necessary to buy things from outside my country; within the country, there are other convenient payment methods) was to subscribe to LWN. Before that day, other than a brief year in which a friend had paid for my LWN subscription with his credit card, I mostly waited the one week to read the paid articles (and, in fact, I'm still subscribed to the LWN mailing list which automatically tells you whenever a paid article becomes free).
Not the OP, but a possible reason: not all people have credit cards. In fact, the very first thing I did once I finally decided to get a credit card (which, frankly, is only really necessary to buy things from outside my country; within the country, there are other convenient payment methods) was to subscribe to LWN. Before that day, other than a brief year in which a friend had paid for my LWN subscription with his credit card, I mostly waited the one week to read the paid articles (and, in fact, I'm still subscribed to the LWN mailing list which automatically tells you whenever a paid article becomes free).
[deleted]
If you have the means then I would recommend subscribing https://lwn.net/subscribe they are pretty much the only foss news outlet that published so high quality articles.
You might consider subscribing to get more of LWN's content as it's released. Some time ago, the wait for the paywall removal for information that was relevant to something I was doing then and possibly not a week later is what finally got me to subscribe.
I know the article is serious, but it has the writing-style of an onion/babylonbee article lol.
esp the last paragraph: >As time ran out, Matthew Wilcox asked whether kernel developers should be writing idiomatic Rust code, or whether they will be writing "C in Rust". Ojeda answered that code might be more C-like toward the beginning; adoption of more advanced features (such as async) might take longer. Gleixner asked what could be done to prevent developers from using unstable features (once the features used by the kernel are stabilized); the answer was to specify the version of the compiler to be used with kernel development.
esp the last paragraph: >As time ran out, Matthew Wilcox asked whether kernel developers should be writing idiomatic Rust code, or whether they will be writing "C in Rust". Ojeda answered that code might be more C-like toward the beginning; adoption of more advanced features (such as async) might take longer. Gleixner asked what could be done to prevent developers from using unstable features (once the features used by the kernel are stabilized); the answer was to specify the version of the compiler to be used with kernel development.
> Instead, Bottomley suggested that, rather than bringing in Rust, it might be better to just move more Rust-like features into C. Ojeda said that he has actually been working with the C language committee to push for that to happen, but any such change will take a long time if it happens at all. Christoph Hellwig said that this sort of change will have to happen anyway unless the plan is to rewrite the whole kernel in Rust; he was not pleased at the idea of rewriting working code in a new language. Perhaps the sparse static analyzer could be enhanced to do more Rust-like checking, he said. Ojeda answered that the result of such efforts would be like having Rust — but much later.
Some reasonable people in this sea of sectarian crabs, glad to hear that
Some reasonable people in this sea of sectarian crabs, glad to hear that
You’ve added nothing to the quote but vitriol.
Glowing endorsement from Torvalds right there. I'm really curious about how this will work out, Rust is my favourite programming language by a fair margin and seeing it being used more and more in places where C or C++ has traditionally dominated is very exciting. The future is looking bright (for those of us who like Rust).