[HN Gopher] Next steps for Rust in the kernel
___________________________________________________________________
Next steps for Rust in the kernel
Author : TheGuyWhoCodes
Score : 213 points
Date : 2022-09-21 12:16 UTC (10 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| Longlius wrote:
| 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.
| jahewson wrote:
| > significantly better than C++
|
| You say that like there's some scalar measure of "better".
| nyxtom wrote:
| 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
| masklinn wrote:
| > 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.
| btreesOfSpring wrote:
| 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.
| vbtemp wrote:
| > 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._
| Jensson wrote:
| 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.
| seg_lol wrote:
| 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.
| Jensson wrote:
| 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.
| throw10920 wrote:
| 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.
| sophacles wrote:
| 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.
| agumonkey wrote:
| 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.
| steveklabnik wrote:
| > 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.)
| twic wrote:
| 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.
| endorphine wrote:
| 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.
| unrealhoang wrote:
| 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.
| bestouff wrote:
| Get good at Rust, the answer will come.
| vbtemp wrote:
| To the OP: This is the correct answer.
| pjkundert wrote:
| 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.
| agumonkey wrote:
| 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 ?
| sam0x17 wrote:
| > 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.
| ardel95 wrote:
| Rust is significantly better than C++. And I say that as
| somebody who has done many years of C++ development.
| lijogdfljk wrote:
| 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.
| brundolf wrote:
| 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
| runevault wrote:
| 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.
| Tolexx wrote:
| >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".
| nequo wrote:
| 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.
| [deleted]
| pabs3 wrote:
| LWN folks are fine with subscriber links being posted here,
| they view it as a form of advertising and they get subscribers
| from it.
| nequo wrote:
| 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=cust
| om&...
|
| [3] https://lwn.net/
| rascul wrote:
| 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.
| cozzyd wrote:
| In that case, why not subscribe? It's not expensive (they even
| have tiered subscription levels...) and it's awesome.
| cesarb wrote:
| > 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).
| skywhopper wrote:
| 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.
| tl wrote:
| 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
| xedrac wrote:
| 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.
| Kukumber wrote:
| > 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
| klysm wrote:
| You've added nothing to the quote but vitriol.
| javier_e06 wrote:
| 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.
| mlindner wrote:
| 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.
| sondr3 wrote:
| > Torvalds added that Rust isn't that terrible in the end; "it's
| not Perl".
|
| 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).
| bitL wrote:
| 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...
| dblohm7 wrote:
| 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.
| lvass wrote:
| Which projects?
| maccam94 wrote:
| 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
| camdenreslink wrote:
| Scala isn't that complex unless you try to pretend it's
| Haskell.
| crznp wrote:
| 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++.
| karmakurtisaani wrote:
| Scala is not that bad. I'd take it over java any day.
| WiSaGaN wrote:
| Any historical background for the reference of Perl by
| Torvalds?
| dijit wrote:
| 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.
| User23 wrote:
| > 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.
| hardware2win wrote:
| Bilion lines?
|
| What, how?
|
| Thats bigger than windows linux llvm chromium and 5 other
| compilers combined according to google
| dijit wrote:
| 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.
| angrygoat wrote:
| 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.
| LinuxBender wrote:
| 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.
| singhrac wrote:
| 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.
| belter wrote:
| 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...
| klabb3 wrote:
| Dad, let's go home. Please.
| bogeholm wrote:
| _one billion lines of Perl_? Wow
| twic wrote:
| Could have been worse. Could all have been on one line.
| umanwizard wrote:
| 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).
| nkozyra wrote:
| 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.
| dhosek wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| gautamdivgi wrote:
| 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.
| rhacker wrote:
| 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.
| gautamdivgi wrote:
| 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"?
| VyseofArcadia wrote:
| With Java? I usually think of Perl as a glue language,
| like bash scripting. Java would not be my choice to glue
| components together.
| umanwizard wrote:
| 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).
| dhosek wrote:
| 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.
| thesuperbigfrog wrote:
| >> 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.
| mschuster91 wrote:
| 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.
| edgyquant wrote:
| This is wrong, initially Linux was quite literally a bash
| kernel
| marcus0x62 wrote:
| 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.
| edgyquant wrote:
| Linux was built out initially with a hard coded call to
| bash
| werdnapk wrote:
| 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.
| chc wrote:
| 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>`.
| a1369209993 wrote:
| 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.
| chc wrote:
| 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.
| tialaramex wrote:
| 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.
| a1369209993 wrote:
| > 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).
| ElCheapo wrote:
| Linus hates Perl?
|
| Heck, so my secret project of slowly replacing every Perl
| script in the kernel with C might even get approved...
| tialaramex wrote:
| 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.
| [deleted]
| TotoHorner wrote:
| 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.
| jerf wrote:
| 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.)
| kjeetgill wrote:
| 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).
| Twisol wrote:
| 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.
| rust_is_dead wrote:
| My advice would be to learn the language that your operating
| system is written in.
| sondr3 wrote:
| 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.
| NIckGeek wrote:
| 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.
| qwery wrote:
| > 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.
| skywhopper wrote:
| 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.
| klabb3 wrote:
| 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.
| Animats wrote:
| That is the best description of why Rust exists that I've
| seen so far.
| the_duke wrote:
| 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.
| tialaramex wrote:
| 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.
| pizza234 wrote:
| 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.
| thetrashcanman wrote:
| 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).
| dijit wrote:
| 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.
| Twisol wrote:
| > 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).
| rob74 wrote:
| 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.
| Twisol wrote:
| 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/art
| icles/t...
| nextaccountic wrote:
| > 0.1% faster,
|
| The performance gains of fine-tuned code is typically two
| orders of magnitude higher
| dboreham wrote:
| All computers are pdp-11s.
| kjeetgill wrote:
| 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.
| packetlost wrote:
| You're much more likely to get bitten by those 2 things
| at the ASM level... I guess.
| kjeetgill wrote:
| So I don't work at that level, I'd love to hear more.
| What situations do they leak through in?
| packetlost wrote:
| 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).
| Twisol wrote:
| > 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/art
| icles/t...
| cbm-vic-20 wrote:
| This is true even on later PDP-11 models with memory
| caches.
| marcosdumay wrote:
| > 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.
| antegamisou wrote:
| > 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.
| jcranmer wrote:
| 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.
| Filligree wrote:
| 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.
| ImprobableTruth wrote:
| ... no? In fact I think learning assembly before C makes
| a lot more sense than the other way around.
| orobinson wrote:
| 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?".
| HideousKojima wrote:
| I learned CHIP-8 asm and Gameboy asm before ever touching
| C
| pwpw wrote:
| 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?
| HideousKojima wrote:
| 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.
| nindalf wrote:
| 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.
| kjeetgill wrote:
| > 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.
| steveklabnik wrote:
| 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.
| cannabis_sam wrote:
| Your views on programming languages are deeply
| appreciated, regardless of whether I agree or not.
| nindalf wrote:
| 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...)
| dijit wrote:
| 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.
| TrickardRixx wrote:
| Sounds to me like if I want to know "how computers think"
| I should learn assembly.
| dijit wrote:
| 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.
| jcranmer wrote:
| > 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.
| cesarb wrote:
| > 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.)
| jcranmer wrote:
| 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.
| tialaramex wrote:
| 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.
| UncleMeat wrote:
| > 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.
| Jensson wrote:
| > 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.
| dijit wrote:
| > 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.
| Symmetry wrote:
| 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.
| deckiedan wrote:
| 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).
| nextaccountic wrote:
| 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)
| aaaaaaaaaaab wrote:
| 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.
| amalcon wrote:
| 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.
| cbm-vic-20 wrote:
| > 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..
| gary17the wrote:
| > 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).
| oleganza wrote:
| 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.
| PerFartmann wrote:
| Keep on using python and JS.
|
| When the time comes you can start with Rust
| packetlost wrote:
| 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.
| avgcorrection wrote:
| 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.
| daptaq wrote:
| 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?
| schuyler2d wrote:
| 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.
| mlindner wrote:
| > 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?)
| phaylon wrote:
| 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.)
| __jem wrote:
| 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.
| roblabla wrote:
| > 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/
| jbirer wrote:
| The stereotypes of Rust developers are earned. They are a cargo
| cult.
| sidlls wrote:
| There's no reason to down vote that comment. And it isn't
| just the loudest rust evangelists. It's not the whole
| community, but for some reason Rust seems to have attracted a
| larger share of toxic evangelists than other languages (or
| paradigms: see functional programming).
| mustache_kimono wrote:
| I think this is basically nonsense. Some of most toxic
| comments I have ever encountered on HN are people whining
| about Rust. I've said it before and I'll say it again --
| some Rust users need to be confident enough in Rust to
| allow others to disagree, but, _mios dio_ , it's not as if
| their interlocutors have found some sweet spot of high
| minded debate.
|
| Moreover, "toxic", to me, is not well-meaning, generally
| positive people excited about something _legitimately
| technically interesting_ and new. "Toxic" is repeated
| flimsy arguments ("Just write better code..." and "Modern
| C++ doesn't have these issues..." and "Rust doesn't fix ALL
| BUGS so why even bother?"), mole hill matters of taste
| ("Egads! The syntax!"), and drive by hype hate (I'm glad
| the hype has died down enough for Forth to be usable).
|
| I gag on this "toxic" line every time I read it, because it
| usually also includes a boring, retrogressive, small beer,
| almost American politics-style argument. The joke that
| comes to mind is we are about 15 minutes from someone
| claiming "The coastal elites want to force you to use
| Rust." Yesterday, I saw two comments, one of which claimed
| Rust was a _conspiracy_ against C++ programmers, another
| that admitted anti-Rust fervor was about _resentment_. The
| energy is _they_ don 't want you to win. _They_ are keeping
| you down. Just yuck.
| allisdust wrote:
| I have a theory that all new rust programmers either
| become evangelists or haters based on whether they are
| able to cross the borrow checker barrier or not.
| mustache_kimono wrote:
| I mean that isn't a terrible theory. Love and hate is
| often forged in an initial "I hate this." TBC I hated the
| borrow checker once too! My fear are the people who make
| these love/hate decisions based on vibes instead of
| experience. I'm perfectly okay with someone who tries
| Rust/Java/OCaml and says "Never for me. Not again." I'm
| less okay with these technical disagreements becoming
| more tribal. I think C vs. C++ is often tribal. Because I
| like Rust, I really hate the idea Rust opinions might be
| tribal too.
| pohl wrote:
| There might be some merit to that, although it could just
| be the case that they just don't like the idea of a
| compiler telling them what they can and cannot do.
| mustache_kimono wrote:
| "Hey man, don't harsh my buzz. I want give out two
| mutable aliases to this underlying value. _I know what I
| 'm doing_."
|
| Narrator: He didn't know what he was doing.
| nyanpasu64 wrote:
| Giving out two mutable aliases to an integer or struct
| holding integers is perfectly safe in C and C++ and JS
| and Java and Python... and perfectly safe in Rust if you
| hand out multiple &struct and mark each field as Cell<T>
| (just with painful syntax compared to any other
| imperative language in existence).
| throwaway17_17 wrote:
| I agree with the sibling comment that your theory
| probably has some merit. However, it does leave out a
| class of individuals like me. I tried Rust, had no issue
| with the borrow checker. But I think that is because,
| IMO, using Rust is predicated on programming, and
| designing programs and algorithms, in the way Rust wants
| them designed. So, when using Rust I just accepted that
| my code needed to fit what Rust thinks is proper and will
| accept. There are plenty of other reasons not want to use
| Rust and to not want to see the language become the front
| runner in some sort of 'race to replace' other systems
| level languages. But I'm sure there are more knee-jerk
| reactions that become entrenched opinions than those
| opinions formed like mine.
| jamincan wrote:
| I used to wonder who these people are too, but I think
| they mostly aren't that visible or at least prominent in
| actual rust threads. But you do occasionally see drive-by
| posts in places like /r/cpp along the lines of "should I
| learn C++ and Rust?" along with a long list of why Rust
| is so much better than C++. I'd sour to Rust too, if that
| was my primary interaction with the "community".
| mustache_kimono wrote:
| > I'd sour to Rust too, if that was my primary
| interaction with the "community".
|
| Yeah, understood. I think we both know Rust people face a
| lot of the same level of criticism. And I get it. It's no
| fun. However, I don't think the way forward is to present
| the worst possible form of the argument (a strawman,
| "Rust people think Rust solves all problems", or, a vibe
| level: us vs them, "Rust people are toxic").
|
| If I wanted, I could rake some C++ people over the coals
| for being toxic right now, and not just re: Rust, because
| C++ has more than a few hard core jerks. But whataboutism
| is just not helpful. I'm more interested in something
| more substantive/constructive.
| sidlls wrote:
| That's fair. I'd be interested in that, too. I just don't
| see it as something a certain group is interested in.
| manfre wrote:
| > "toxic", to me, is not well-meaning, generally positive
| people...
|
| The self proclaimed intentions or excitement of people
| has no bearing on whether or not the environment they
| create is toxic.
| mustache_kimono wrote:
| I don't necessarily disagree. There can be a "toxic
| positivity". So, partially agree, but I think this side
| of the argument needs to be more fully fleshed out, and,
| if this is to be a serious criticism, I think the anti-
| Rust folks need to, for lack of a better word, lead, and
| be examples non-toxic behavior. Posting unserious vibe
| level HN comments is not leadership.
| manfre wrote:
| If group A creates a toxic environment and group B reacts
| (and potentially contributes to) the toxic environment,
| why would it fall upon group B to lead fixing the
| situation? Your disagreement aligns with victim blaming.
| mustache_kimono wrote:
| > If group A creates a toxic environment and group B
| reacts (and potentially contributes to) the toxic
| environment, why would it fall upon group B to lead
| fixing the situation? Your disagreement aligns with
| victim blaming.
|
| I _strongly disagree_ with this sentiment for lots of
| reasons. Most significantly, because who is to say who
| created the environment? This is a lesser form of debate
| sometimes used in American politics, and I 'd prefer not
| to engage in it -- "Rs did Y first, so we Ds are
| completely justified in doing X."
|
| Moreover, your characterization of anti-Rust folks as
| somehow "victims" is fundamentally ridiculous. Get a
| grip.
|
| _This_ isn 't leadership. This is nursing resentment.
| [deleted]
| mort96 wrote:
| Rust has attracted a large share of evangelist, because the
| problem it solves is one which other languages don't;
| guaranteed safety without being a managed language. And
| that is genuinely something to be excited about, and if
| more of the code that's currently C or C++ was Rust, we
| would probably have fewer security issues.
|
| My guess is that you're lumping all Rust evangelists
| together in one bucket and thinking of them all as "toxic
| evangelists", when a lot of them are just people who want
| the computing world to be better.
| sidlls wrote:
| Rust has _some_ safety guarantees and it is strictly
| better in that regard than C++. But it's not a panacea,
| and the footprint of `unsafe` buried in so many crates
| _is worrisome_ , especially when novice systems
| programmers see "guaranteed safety" and make assumptions
| that aren't necessarily valid.
|
| Aside from that I very carefully and clearly did not lump
| all Rust evangelists in a single bucket.
| overboard2 wrote:
| >cargo cult
|
| https://youtu.be/6zXDo4dL7SU
| howinteresting wrote:
| Year after year after year (7 years in a row), Rust is the
| most loved language on the Stack Overflow survey. Maybe it's
| just that good.
| FnuGk wrote:
| 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.
| dgs_sgd wrote:
| What are the negative stereotypes you associate with Rust and
| Rust programmers?
| MisterTea wrote:
| 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.
| gspr wrote:
| Being put off by the evangelizing I can certainly
| understand - but surely the name "rustaceans" is just some
| innocent humor.
| MisterTea wrote:
| 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.
| mustache_kimono wrote:
| > 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?"
| twic wrote:
| 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.
| sophacles wrote:
| Ahh yes. Unlike the pythonistas, the gophers, the ziguanas,
| the lispers, the perl monks, ...
| gspr wrote:
| 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).
| rust_is_dead wrote:
| 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.
| greenhearth wrote:
| 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_dead wrote:
| 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.
| allisdust wrote:
| I'm curious what caused you to be so annoyed with the
| language that you had to create a user name out of it :)
| rust_is_dead wrote:
| I am currently using linux. I predict "rust in the
| kernel" will either fail or create issues so severe that
| I'll need to move on to another operating system. I
| speculate that a huge part of the push is political, and
| if it comes to shove, it will be the day that linux has
| finally jumped the shark. Then I may register HN user
| linux_is_dead :)
| Narann wrote:
| _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.
| mustache_kimono wrote:
| > 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.
| Narann wrote:
| > 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.
| burntsushi wrote:
| > 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.
| sidlls wrote:
| 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.
| Klonoar wrote:
| 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.
| Jensson wrote:
| 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.
| GeekyBear wrote:
| > 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...
| Jensson wrote:
| 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++.
| GeekyBear wrote:
| 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...
| chomp wrote:
| 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.
| packetlost wrote:
| 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.
| gspr wrote:
| > 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.
| zozbot234 wrote:
| 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++.
| ok123456 wrote:
| 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.
| gspr wrote:
| > 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.
| ok123456 wrote:
| 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.
| brundolf wrote:
| 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
| consp wrote:
| > 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.
| kouteiheika wrote:
| > 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?
| packetlost wrote:
| > 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.
| maherbeg wrote:
| 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.
| badrabbit wrote:
| 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.
| Animats wrote:
| 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.
| w10-1 wrote:
| 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.
| keehun wrote:
| 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?
| d12bb wrote:
| 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
| surrTurr wrote:
| 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.
| topbanana wrote:
| 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.
| dkryptr wrote:
| 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.
| atoav wrote:
| 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...
| masklinn wrote:
| > 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.
| tialaramex wrote:
| 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.
| mfashby wrote:
| 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).
| davidatbu wrote:
| 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.
| Jensson wrote:
| 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.
| 8jy89hui wrote:
| 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)
| abledon wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-21 23:02 UTC)