[HN Gopher] Linus Torvalds on where Rust will fit into Linux
___________________________________________________________________
Linus Torvalds on where Rust will fit into Linux
Author : CrankyBear
Score : 147 points
Date : 2021-03-23 15:51 UTC (7 hours ago)
(HTM) web link (www.zdnet.com)
(TXT) w3m dump (www.zdnet.com)
| esgwpl wrote:
| >The kernel is different from userspace projects - more difficult
| in some respects (we use a lot of very odd header files that
| pushes the boundary of what can be called "C"), but easier in
| many other respects (mainly in the sense that the kernel is
| fairly self-contained, and then doesn't rely on other projects
| for the final binary).
|
| I'm interested in what Torvalds meant by these odd header files,
| does anyone know?
| cransoon wrote:
| /* * This returns a constant expressionn while
| determining if an argument is * a constant expression,
| most importantly without evaluating the argument. *
| Glory to Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
| */ #define __is_constexpr(x) \ (sizeof(int)
| == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
| nmfisher wrote:
| Jesus, can someone unravel that for me?
| joseluisq wrote:
| Wow! the above code is described by itself about what
| Torvalds means with: very odd header files that *pushes the
| boundary* of what can be called "C".
|
| I'm not a C dev BTW.
| PixelOfDeath wrote:
| The dark side of c is a pathway to many abilities, some
| considered to be unnatural
| ufo wrote:
| Some explanation from Linus about how this trick works:
| https://lkml.org/lkml/2018/3/20/845
| 120bits wrote:
| "sizeof( _(void_ )1)"
|
| "- this will break the minds of everybody who ever sees
| that expression."
|
| It indeed broke my mind!
| 120bits wrote:
| wow! As mainly a Java engineer. This is an alien language to
| me.
| tambourine_man wrote:
| Probably some crazy macros that the kernel code uses. You can
| end up having an almost dialect of C with extensive use.
| xiphias2 wrote:
| > From where Kroah-Hartman sits, "it will all come down to how
| well the interaction between the kernel core structures and
| lifetime rules that are written in C can be mapped into Rust
| structures and lifetime rules for drivers in Rust to be able to
| use them properly. That's going to take a lot of careful work by
| the developers wanting to hook this all up and I wish them the
| best of luck."
|
| It's really interesting that any C code already has to have a
| memory management ownership model, and the consistency of that
| model makes Rustification easy / hard.
| gtsop wrote:
| I love the idea of more rust into linux because I think it will
| make the code more secure and easier to contribute/modify. I am
| scared of any potential problems an immature ecosystem (relative
| to C ofcourse, don't jump the gun) can cause to this life-
| depending tool called the linux kernel. I am glad linus is open
| to it but careful. Balanced approach
|
| Edit: I am also a proponent of careful re-writes of very old
| userspace utilities (eg: ping) accompanied by very rigorous tests
| to ensure there aren't any behavour changes
| enriquto wrote:
| > I am also a proponent of careful re-writes of very old
| userspace utilities (eg: ping) accompanied by very rigorous
| tests to ensure there aren't any behavour changes
|
| That would be great, but a prerequisite for that is that the
| rust language is stable to ensure that there aren't any
| behaviour changes in the compiler itself.
| nynx wrote:
| Rust has been stable since 2015.
| turminal wrote:
| Always the same arguments, hilarious.
| moocowtruck wrote:
| let me in on the hilarious part i want to laugh too
| jhgb wrote:
| Probably the part where there's major libraries that have
| required unstable Rust for years?
| throwaway525142 wrote:
| Can you point out which? I'm only aware of rocket.
| nynx wrote:
| I'm not really sure how that's an argument. It's just a
| fact. Rust has been stable and backwards compatible since
| 2015.
| chomp wrote:
| Rust doesn't support the same amount of architectures C and Linux
| do, hopefully either Rust learns to support more architectures,
| or this stays confined to just driver code because I'd hate to
| see Linux disappear from some of the more esoteric architectures.
| brundolf wrote:
| Or maybe this would inspire people to expand LLVM support?
| There's nothing fundamental that prevents Rust from running on
| those architectures (as far as I know)
| willcipriano wrote:
| I don't believe there is anything fundamentally preventing
| any language from running on any architecture other than "we
| haven't gotten around to it yet". Can't you emulate any
| Turing machine inside of any other Turing machine? I'd guess
| you could run the latest version of Python on anything more
| advanced than a abacus if you had a couple of lifetimes to
| waste on the project.
| brundolf wrote:
| My point is that a) half of the work doesn't have to happen
| because of LLVM's back-/front-end split, and b) if these
| are architectures that people care about keeping around and
| investing in, the benefits of adding LLVM support will go
| beyond just Rust
| bitwize wrote:
| Weird architectures weren't supported to begin with:
| https://blog.yossarian.net/2021/02/28/Weird-architectures-we...
|
| If you're still running a system with an arcane ISA, support it
| yourself. 99% of the people running modern Linux are interested
| in three CPU architectures (four or five once RISC-V gains
| traction), all of them supported by Rust. Supporting old or
| obscure ISAs is not a priority at this point compared to
| bringing kernel memory safety into the 21st century, which Rust
| helps a lot with.
| Gaelan wrote:
| While I think I agree with this article, that isn't the case
| here. That article is talking about taking C code that
| happens to be portable to an obscure architecture, but never
| officially supported it, then complaining when the never-
| official support breaks for some reason. We're talking here
| about the Linux kernel, which (by necessity) was explicitly
| ported to every architecture it works on, so any lost
| architecture support would be an explicitly removed feature.
| tambourine_man wrote:
| Linus is very proud of Linux running on anything, from toasters
| to HPC, so I think it's safe to assume less common
| architectures aren't going away.
| Hublium wrote:
| I thought that was NetBSD's thing?
| throwaway0x1 wrote:
| Indeed it was, two decades ago... Linux has taken the pole
| position in supported architectures now though.
| steveklabnik wrote:
| Linux removes platform support from time to time, like any
| project. IA64 was a recent, notable example.
|
| That being said, it is true that Rust doesn't yet support all
| the platforms that are important to the kernel. That's one of
| the reasons this is starting with drivers, and is one of the
| reasons why some folks are pursuing a Rust frontend for gcc.
| pm215 wrote:
| It depends entirely on whether there are still developers
| interested in maintaining support for those architectures. It
| seems pretty safe to assume that Torvalds isn't going to be
| in favour of "we drop anything without a rust backend
| tomorrow"; but on the other hand 8 archs were dropped in 2018
| -- https://lwn.net/Articles/749292/ -- essentially for lack
| of any active interest in them. It's possible that eventually
| "set of archs with a rust backend" and "set of archs which
| people care about enough to keep alive in the kernel"
| converge to the same set. It's even possible that one day
| "does this even have a rust backend?" becomes a marker of "is
| this thing really of use to anybody" in the same way that in
| 2018 "does this thing have support in upstream gcc" was a
| marker for "maybe we can drop this". That would be years from
| now, if ever, though, IMHO.
| Narishma wrote:
| Plenty of them have already gone away. If they don't have
| people maintaining them, they get dropped over time.
| dralley wrote:
| > Another point is taking on drivers first for "any initial
| trials to drivers is simply the architecture side," said
| Torvalds. "Lots of drivers are only relevant on a couple of
| target architectures, so the whole issue with Rust code not
| being supported on some architectures is less of an issue."
| xiphias2 wrote:
| I think adding new targets to LLVM is an infititely easier task
| than writing safe C code (as long as the LLVM team is open to
| it)
| Blikkentrekker wrote:
| _Rustc_ 's lack of architecture support is purely an _LLVM_
| issue /
|
| A far as I know, the latter supports many architectures the
| former does not.
| steveklabnik wrote:
| It is true that Rust supports a subset of the architectures
| LLVM supports, but to be honest, I am not sure if "many" is
| the right adjective. I mean that in a literal sense, I
| don't have a good handle on the list. For Rust, the list is
| https://doc.rust-lang.org/nightly/rustc/platform-
| support.htm..., but I'm not sure if there's such a list for
| LLVM, other than looking at something like
| https://llvm.org/doxygen/Triple_8h_source.html and figuring
| it out?
| junon wrote:
| This is false equivalency.
| justaguy88 wrote:
| The other avenue is adding a Rust frontend to GCC
| dahfizz wrote:
| Can someone with more knowledge than me explain what benefit Rust
| presents to a low level codebase such as a kernel?
|
| I am a C programmer by trade who has played with Rust. It is a
| great language but there is very little you can do safely. In
| higher level projects you can mostly push the un-safety into the
| standard library.
|
| But when you have to do everything yourself, all of the "buggy"
| code has to be marked unsafe anyway. Allocating and accessing(!!)
| memory is unsafe. Interfacing with C or asm is unsafe. Your
| buffer/vector implementation is unsafe.
|
| Basically, all the common culprits for memory bugs in C would be
| the code marked unsafe if rewritten in rust. So what is the
| benefit?
| sfvisser wrote:
| Ideally, you write a small subset of unsafe primitives and
| encapsulate those in a safe interface and try to use those to
| implement your actual kernel logic.
| habitue wrote:
| unsafe isn't like a taint, where things that use unsafe code
| must propagate their unsafety outward. It's more like saying
| "there are invariants that this function expects, but does not
| enforce, and the caller may violate those invariants".
| Obviously, we want to minimize code like that. The best way to
| do that is to build abstractions around the unsafe code that
| only interact with the unsafe code in a way that respects those
| invariants. Often, (though not always) that means giving up
| some amount of flexibility to the user of your safe
| abstraction. If you design it right, the caller may never miss
| that flexibility.
|
| A recent example of using private constructors and zero-sized
| compile time invariant enforcement is an embedded blog here:
| https://www.ecorax.net/macro-bunker-1/
|
| The embedded rust community uses this typestate pattern to
| build safe abstractions around pin interactions. Very similar
| things can be done to build safe abstractions around the
| volatile memory accesses etc that the kernel does.
| greydius wrote:
| > all the common culprits for memory bugs in C would be the
| code marked unsafe if rewritten in rust
|
| You've answered your own question.
| dralley wrote:
| >It is a great language but there is very little you can do
| safely.
|
| Even extremely performance-oriented and low level projects such
| as the standard library or the Redox kernel are less than 5%
| unsafe code. There's _lots_ you can do safely.
| danhau wrote:
| I'm not a pro but here are my two cents.
|
| The benefit, and really the point of unsafe, is to encapsulate
| the unsafe stuff behind safe APIs and to use Rust's other
| features, like the borrow checker for example, to enforce
| correct usage of such API.
|
| Ex.: I was using nanovg (vector graphics library in C) to build
| a GUI app some day. I was using Rust and a bare-bones FFI
| library that provided a 1:1 mapping to the C API. On top of
| this unsafe C-API, I built a wrapper library in safe Rust that
| doesn't allow me to use nanovg incorrectly. And not in the use-
| after-free sense of incorrect (that too), but instead in the
| "you can't call this function between these other two, that's
| undefined / will produce unexpected graphical results".
|
| So the power of unsafe is to encapsulate "unsafe" behaviour and
| to enrich it with compile-time information, to build guarantees
| around it.
| adamnemecek wrote:
| If you are looking for a Rust nanovg port, look no further
| https://github.com/femtovg/femtovg. We are in the process of
| adding a wgpu backend and we are definitely looking for
| contributors so contact me if you want to get involved.
| filmor wrote:
| You'd write the allocator or low-level memory access logic once
| with unsafe code and afterwards all code using the
| functionality can be written as safe code. That limits the
| amount of code that can have data races.
| zanellato19 wrote:
| Accessing memory is not unsafe, wdym?
| mcguire wrote:
| Building memory management/allocation/malloc systems is.
| megous wrote:
| In a multi-core system, it may be, since you're not really
| accessing main memory directly, but you're going through
| several levels of all kinds of caches, some shared and some
| not (L1 (instruction, data), L2, L3, TLB, ...), and sometimes
| competing with devices that access the memory "directly" via
| DMA.
| Asraelite wrote:
| I guess dereferencing a raw pointer?
| steveklabnik wrote:
| I work on firmware and kernel-level code, in pure Rust, at my
| job. We don't do malloc at all.
|
| One of the key features Rust enables is that you can build safe
| abstractions on top of unsafe things. Another key feature is
| that those abstractions often mean compile-time, but not run-
| time, cost.
|
| If you build the right abstractions, you can minimize the
| amount of unsafe code pretty dramatically. I don't have numbers
| handy for our codebase (and it's not open source yet, but will
| be eventually), but as an example, the Redox documentation (a
| Rust-based kernel that is, uh... linked... below) says:
| https://doc.redox-os.org/book/ch01-07-why-rust.html#unsafes
|
| > A quick grep gives us some stats: the kernel has about 300
| invocations of unsafe in about 16,000 lines of code overall.
| Every one of these is carefully audited to ensure correctness.
|
| The advantage here is that, if and when there are bugs in this
| code, you only have to look at the modules containing those
| unsafe invocations, rather than the entire codebase.
|
| There are also other advantages to the Rust language that make
| it worthwhile too, regardless of safety percentage, but it is
| true that this is often people's first concerns. The code that
| landed in linux-next has a lot of unsafe in it, because it is
| specifically trying to build out the proper abstractions here.
| The idea is that drivers built on top of this code will not
| need nearly as much, generally.
| alexfromapex wrote:
| Another advantage, when compared with C, is the
| package/dependency management and build tooling which makes
| compiling for targeted architectures a little easier
| jabedude wrote:
| To be honest this advantage is not being used in Linux.
| kbuild isn't going to use cargo but rather rustc directly
| mcguire wrote:
| " _The advantage here is that, if and when there are bugs in
| this code, you only have to look at the modules containing
| those unsafe invocations, rather than the entire codebase._ "
|
| I would be cautious with statements like that. You can limit
| some kinds of operations to unsafe code, audit the daylights
| out of those, build abstractions that make it impossible to
| use that unsafe code from safe code in an unsafe manner, and
| still not be doing the right thing.
| steveklabnik wrote:
| Sure, I thought the context of this discussion was memory
| safety specifically, and so that's what I was talking
| about. In a less specific conversation I would have said
| "memory safety bugs," but thought it would be redundant
| here. I guess not.
| junon wrote:
| Which types of bugs? Please specify when talking about code
| safety.
| steveklabnik wrote:
| I do generally, but given that this is a pretty focused
| topic on something very specific, I thought "memory safety"
| was that topic.
| DSingularity wrote:
| For example use after free or array indexing bugs (eg
| incorrect limit checks).
| dahfizz wrote:
| > The advantage here is that, if and when there are bugs in
| this code, you only have to look at the modules containing
| those unsafe invocations, rather than the entire codebase.
|
| That is a brilliant feature I had not thought of. Thanks!
| steveklabnik wrote:
| No problem! I think the skepticism is very warranted. We
| know that these systems can be created, but we don't have
| examples of this working at the same scale as projects like
| Linux yet. That takes time and effort, exactly as Linus and
| Greg Kroah-Hartman say. We'll see how it works out in
| practice. I also think the "de novo system" and "adding
| Rust into a large existing system" are two related, but
| different, problems, with their own unique challenges.
| xiphias2 wrote:
| One great thing that I see with Rust is that the
| developers are open to extensions of the language that
| are provided just to be more compatible to the C memory
| model (like anonymous unions). I don't know many other
| languages like that.
| KennyFromIT wrote:
| Linus:
|
| > I'm interested in the project, but I think it's driven by
| people who are very excited about Rust, and I want to see how it
| actually then ends up working in practice.
| brundolf wrote:
| [deleted]
|
| (Deleted because I only meant to bring up the broader
| phenomenon of what makes a person feel "excited" or "unexcited"
| about a language; I was specifically trying (unsuccessfully) to
| avoid the hotbed topic that has arisen below)
| capableweb wrote:
| I think emotional reaction happens to a lot of things that we
| like, where we raise up their benefits and downplay their
| negatives. At least for the first few years, until we're in a
| different context or something else comes along that solves
| it even better.
|
| I also think that's why lisp people are so feverish about
| lisp as well: as you get more involved in the language with
| its charms, the more excitement you get and you want to see
| the language in more places/contexts
| steveklabnik wrote:
| It would be a mistake to characterize this push as an
| "emotional concern." The main driver is security. The folks
| doing this work are advocates of memory safety first, and
| Rust second. It just so happens that in this particular
| context, Rust is the most appropriate choice.
|
| EDIT: it's all good! I didn't think your comments were bad.
| brundolf wrote:
| [deleted]
| steveklabnik wrote:
| I think it depends on what "re-write it in Rust" means.
| Some people say that it means folks specifically asking
| for a project to be re-written in Rust. Others seem to
| imply that any new code written in Rust counts. To
| illustrate the difference, ripgrep would be the latter,
| but not the former.
|
| If we're talking about the former, I think the actual
| instances of this are few and far between, and are
| complained about far more than actually occurs. At one
| point I was actually trying to get hard data on this, but
| there really were only a handful of times I could find
| this seriously occurring, and they were pretty easily
| dismissed. The folks who talk about it like a plague of
| some kind never seem to show their evidence, or link to
| one or two examples at best.
|
| If we're talking about the latter, it shouldn't be
| surprising that folks who like a language write software
| in that language. That's why languages exist. I don't
| know why some people really want to say that folks cannot
| write whatever software they want in whatever language
| they want.
| capableweb wrote:
| > At one point I was actually trying to get hard data on
| this, but there really were only a handful of times I
| could find this seriously occurring
|
| This is probably depending on the environment. Corporate
| environments would move very slow, open source kind of
| fast and SMB/SME somewhere in the middle. All of them
| plagued by cargoculting, but especially average
| performing SMB/SME are the most guilty, and also where
| I've seen the most "Hey, we should probably rewrite this
| service in Rust because it'll be better for sure" since
| some years back.
| steveklabnik wrote:
| Yes, this is a good point, for sure.
| capableweb wrote:
| I actually stumbled upon[1] a data source for you! Seems
| there is some activity in the "Rewrite it in Rust"
| domain, and there is a collection of it being suggested
| in a lot of places: https://github.com/ansuz/RIIR
|
| - [1] https://news.ycombinator.com/item?id=26561093
| busterarm wrote:
| I think if security is a main concern of people working on
| Linux, there are both lower hanging fruit AND bigger fish
| to fry than getting code into Rust.
|
| Not that it isn't a worthy effort, but it's still an effort
| by people who are more excited about Rust than they are
| acting in the interest of security.
|
| Edit: It's almost a meme at this point that you can't even
| be remotely critical of Rust on this board without kneejerk
| mass downvoting.
| steveklabnik wrote:
| Do you know anything about the people whose motives you
| are questioning? What work they've done, and why? I think
| if you did, you may not say what you've said.
| busterarm wrote:
| I'm well aware of whom I'm speaking to and the efforts
| made by others.
|
| I'm also well aware of lots of other security problems
| facing Linux that need love and the steps being taken by
| other operating systems where Linux lags behind.
|
| So while I'm not saying that there isn't a concern about
| security by the people involved, I am certainly saying
| why this as opposed to other things.
|
| I have my pet problems and areas where I prefer to work
| too.
| pdimitar wrote:
| > _there are both lower hanging fruit AND bigger fish to
| fry than getting code into Rust._
|
| Do tell, I am very interested?
|
| > _but it 's still an effort by people who are more
| excited about Rust than they are acting in the interest
| of security_
|
| Needlessly dismissive. What if the people got excited
| _because_ of the increased security?
| busterarm wrote:
| > Needlessly dismissive. What if the people got excited
| because of the increased security?
|
| If only people were so excited about making OpenSSL not a
| flaming hot bag of shit.
|
| Can't wait to find out what that patch on Thursday will
| be for.
| pdimitar wrote:
| I don't see how that overlaps with many of us, myself
| included.
|
| My 19 years of programming have taught me that something
| that continuously craps the bed (like OpenSSL) needs to
| be rewritten because from one point and on it's clear
| that the cost of maintenance exceeds the cost of
| rewriting.
|
| Furthermore, do consider that some of us were programming
| C and C++ and found them sub-optimal. But here we would
| likely venture into language wars because there are a lot
| of programmers like myself out there who will never
| subscribe under the notion of "C is fine, you are just
| doing it wrong".
| busterarm wrote:
| > My 19 years of programming have taught me that
| something that continuously craps the bed (like OpenSSL)
| needs to be rewritten because from one point and on it's
| clear that the cost of maintenance exceeds the cost of
| rewriting.
|
| I would agree and it was already done by the OpenBSD
| project. Google started BoringSSL/Tink. Amazon created
| s2n. Linux continues to use OpenSSL. It's still probably
| in the top 3 problems with security in Linux that needs
| fixing.
|
| The rest of your statement is just making my point for
| me.
| pdimitar wrote:
| Well, in that case your statement of "If only people were
| so excited about making OpenSSL not a flaming hot bag of
| shit" is severely misplaced. I have no influence over
| Linux governance. 99.9999% of us out there don't have
| that influence. So what was your point exactly?
|
| Rants are fine and we all do them but I will strongly
| disagree with any responsibility or guilt transferred to
| me because I am excited about Rust and not about OpenSSL.
| As you yourself pointed out, alternatives exist but
| aren't adopted so the problem is political and not
| technical. Right?
|
| > _The rest of your statement is just making my point for
| me._
|
| Not sure what you mean but okay. -\\_(tsu)_/-
| busterarm wrote:
| > Furthermore, do consider that some of us were
| programming C and C++ and found them sub-optimal. But
| here we would likely venture into language wars because
| there are a lot of programmers like myself out there who
| will never subscribe under the notion of "C is fine, you
| are just doing it wrong".
|
| > Not sure what you mean but okay. -\\_(tsu)_/-
|
| Blame the carpenter, not the tools.
|
| C or C++ isn't a real business problem domain that anyone
| has. Nobody's committing their budget to fix that. That's
| the kind of problem only held by ideologues and other
| unreasonable people.
|
| My point was that people who care about fixing problems
| in the security domain will look to fix the biggest
| problems they can in the security domain. They won't look
| at it and say "no, I can't fix this because C/C++ is
| unacceptable to me."
|
| That's someone who cares more about the tools than the
| problem domain. Whethor or not you think C/C++ are
| suitable to the problem domain of writing secure
| software, software will be written in C/C++ and must be
| secured.
|
| Turn down work all you want though. More for the rest of
| us.
| pdimitar wrote:
| > _My point was that people who care about fixing
| problems in the security domain will look to fix the
| biggest problems they can in the security domain. They
| won 't look at it and say "no, I can't fix this because
| C/C++ is unacceptable to me."_
|
| Sometimes that's true, sometimes it isn't. It's a cost-
| benefit analysis like almost anything else.
|
| Everyone is free to disagree on this -- or like you,
| misinterpret my motivation as "caring more about the
| tools than the problem domain". Quite the contrary, I
| want the problems solved but I also put deadlines and
| energy budgets on trying to solve problem X with tool Y
| and if it doesn't cut it within the deadline and/or the
| budget then it's out. Sure, that means more C/C++ work
| for you. I am OK with that.
|
| But let's not pretend that OpenSSL can only be written in
| C or C++ now. We all know that's not true.
|
| > _Blame the carpenter, not the tools._
|
| It's no accident that professional craftsmen utilize
| innovation in their tooling as well, like Sushi chefs
| using ceramic knives for some fish and steel knives for
| others. Ceramic knives weren't that popular some mere
| decades ago.
|
| Your black and white philosophy makes no favours to your
| argument.
|
| It seems you take an issue with the rising popularity of
| Rust. But let me ask you this: if you are so confident in
| C/C++'s superiority, why are you bothered?
| busterarm wrote:
| > It seems you take an issue with the rising popularity
| of Rust. But let me ask you this: if you are so confident
| in C/C++'s superiority, why are you bothered?
|
| I don't have a problem with Rust at all. It's a fine tool
| and I'd be happy to use it (and have), just like any
| other. I work on interesting problems and am tools-
| agnostic (aside from certain languages being suited or
| not to specific domains).
|
| I have a problem with people who lose their objectivity
| as a result of their enthusiasm for Rust and go around
| shouting in every project like it's the most important
| thing to happen in the last 30 years of Computer Science.
| It wouldn't be such a meme if people didn't actually
| friggin' do this.
| pdimitar wrote:
| > _I have a problem with people who lose their
| objectivity as a result of their enthusiasm for Rust and
| go around shouting in every project like it 's the most
| important thing to happen in the last 30 years of
| Computer Science. It's an annoying trend the last 4-5
| years._
|
| I hear this a lot and I've never witnessed it once. ;)
|
| It's all filter bubbles, dude. Chill. The world is not
| ending.
|
| As an example: the comments from both Linus/Greg and the
| Rust community that relate to the OP are quite balanced
| and nobody is shouting for revolutions.
|
| ---
|
| ...That being said, I wouldn't make grandiose claims
| about Rust myself even if it solved a lot of problems for
| me, but still: Rust is an important innovation
| regardless. It seems a lot of the software area has
| chased its own tail before we had some languages step
| forward and solve various problems that people kept
| trying to fix themselves on an ad-hoc basis (and kept
| failing at it).
|
| Rust is one example, Erlang/Elixir are another, and when
| OCaml finally gains parallel abilities, it will be an
| additional (and very fine) example as well. Surely other
| examples exist.
|
| If we're now discussing just the point you quoted me on
| -- I on my side take issue with the people who are way
| too liberal and love to pretend that it doesn't matter
| what language is being used regardless of the business
| and technical problems. Because oh my god yes, yes it
| does matter. A lot.
| lenkite wrote:
| All new languages are _extremely_ important innovations
| until they age a bit and get severe warts. Rust is
| already getting them. See:
| https://theta.eu.org/2021/03/08/async-rust-2.html
|
| Rust is already getting foot-guns like C++ did.
|
| Modern C++ (>C++17) with RAII and neat libraries is
| already an elegant, high performance and high-
| productivity language with good IDE/editor support.
|
| And its not like C++ is standing still. You have
| _standardised_ concepts, modules and co-routines out this
| year. Modules will fix several of C++ 's shortcomings wrt
| build tooling and setup. I am personally looking forward
| to C++ 20 co-routine support in all the major compilers -
| will enable one to develop graceful-async, portable and
| _stable_ libraries without all that Rust churn needing
| re-writes all the time.
|
| Competition is good, but its best to take the Rust
| blinkers off a bit.
| pdimitar wrote:
| Don't get me wrong -- I agree Rust has some footguns. And
| I had high hopes for the 2021 Edition to introduce some
| terser syntax here and there but alas, not happening.
|
| I am not fangirling for Rust at all.
|
| I am saying that it's much easier to make costly mistakes
| in C and legacy C++. I am aware of the modern efforts in
| C++ but they don't help with the literal mountains of
| legacy code that has to be maintained out there...
| [deleted]
| ilaksh wrote:
| People who are interested in OS security should fund Redox OS.
|
| https://www.patreon.com/redox_os
|
| The fact that he is only getting around $1,000 per month on
| Patreon points to deep, deep flaws in humanity. Especially when
| you compare it to other funding amounts for say Linux or popular
| smut on Patreon. A total lack of foresight and values.
| godman_8 wrote:
| Lol what? Deep flaws in humanity? All because some small time
| non-visible OS doesn't receive more funding? The only deep
| flaws I can see are within you generalizing an entire
| population because you don't get what you want.
| edoceo wrote:
| > generalizing an entire population because you don't get
| what you want.
|
| The true deep flaw of humanity.
| maxrev17 wrote:
| U wot m8?
| Bancakes wrote:
| Yesterday it was openbsd, now its redux os. Any other flavour
| of the year you wanna share?
| moistbar wrote:
| 2021 is the year of the Haiku desktop.
| happytoexplain wrote:
| Redox OS getting much less than Linux or porn on Patreon points
| to deep, deep flaws in humanity and a total lack of foresight
| and values? I think there's probably a reasonable version of
| this opinion, but yours is intensely, unrealistically
| judgmental and righteous.
| Someone1234 wrote:
| I like Rust, but I don't understand why "OS written in
| [language]" is a compelling goal within itself. Like an OS
| absolutely needs goals and a target demographic to be useful,
| and it doesn't feel like simply existing to show that a
| language can do it is enough.
|
| Plus if I was going to fund a toy research kernel that aims to
| increase security, I'd go whole-hog and bring Singularity OS[0]
| back from the dead, because at least that plays with new ideas
| and tested the limits of what was thought to be possible.
|
| [0]
| https://en.wikipedia.org/wiki/Singularity_(operating_system)
| crimper wrote:
| I am not arguing with your original point about the language.
| But Singularity is as closed code as it can get and has a
| bunch of crazy assumptions associated to it (must have .NET
| installed which rules out most architectures) Can you explain
| what you like about it? Compared to C, Rust avoids a whole
| category of memory related bugs
| Someone1234 wrote:
| Redox OS is "*NIX written in Rust." Singularity was a
| complete reimagining of OS architecture from the ground up.
| It isn't simply "the same ideas but now in Sing#/CLR!" it
| was an answer to "what if we designed a clean-sheet OS
| today?" There's a long paper on it here[0].
|
| But keep in mind Singularity is still a toy OS. It has no
| use-case, and doesn't aim for real-world goals that would
| make it commercially successful. I just think that even as
| toy OS's go, it was one of the more interesting ones of
| recent times.
|
| [0] https://www.microsoft.com/en-us/research/wp-
| content/uploads/...
| sophacles wrote:
| > I like Rust, but I don't understand why "OS written in
| [language]" is a compelling goal within itself.
|
| There's a few good reasons in my mind:
|
| * proof of concept - if a language claims to be a systems
| language, being able to point to an OS in it is pretty good
| proof that it's true.
|
| * dogfooding - if there are problems with how the language
| works for the OS case, they can be highlighted by the OS.
| (this is similar to self hosting a compiler)
|
| * community building - some folks want to work on a new OS,
| and doing it in a specific language helps grow both groups
| and at least introduces them to each other.
| ilaksh wrote:
| The goal is to make a secure operating system that takes
| lessons from Linux and improves the architecture.
| toast0 wrote:
| I don't have any particular feelings about Rust, but
| proponents of Rust contend it is good for systems work, and
| that its memory safety checks eliminate memory safety issues
| arrising from safe code and that limiting code that doesn't
| pass those safety checks to marked areas makes it easier to
| audit and reason about memory safety leading to fewer memory
| safety issues in the final product.
|
| An operating system is the essential piece of systems work,
| so a Rust OS should serve as a demonstration of the efficacy
| of Rust in systems work. Is the performance on par with
| contemporary operating systems? Is the code about as easy to
| understand as contemporaries? Is there a reduction in memory
| safety issues vs contemporaries?
|
| Positive results from such a project could inspire others to
| use Rust for more systems work and perhaps integration into
| other OS kernels and/or key userspace libraries.
|
| Plus, writing an OS is kind of fun.
| simion314 wrote:
| The flaws might not be in humanity but in the RIR = rewrite it
| in Rust crowd. If you are part of RIR crowd let us know why you
| would not support this project and which one you are supporting
| or would support if you had the possibility.
___________________________________________________________________
(page generated 2021-03-23 23:02 UTC)