cqwrteur (euloanty.delete@this.live.com) on July 12, 2021 4:04 pm wrote:
> dmcq (dmcq.delete@this.fano.co.uk) on July 12, 2021 9:37 am wrote:
> > Michael S (already5chosen.delete@this.yahoo.com) on July 12, 2021 3:58 am wrote:
> > > Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on July 12, 2021 1:31 am wrote:
> > > > cqwrteur (euloanty.delete@this.live.com) on July 11, 2021 11:58 am wrote:
> > > > > https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
> > > > >
> > > > > Same with Rust crates and std. You still see 80% of cves are memory safety cves.
> > > > >
> > > > > Notice that this is only in crates. A lot of security vulnerabilities are not shown. Redox OS whatever.
> > > > >
> > > > > https://bugzilla.mozilla.org/buglist.cgi?bug_id=1513519%2C1683439%2C1690169%2C1690718
> > > > > https://phabricator.services.mozilla.com/D103999
> > > >
> > > > You really don't wanna go there; in Firefox we've got a large body of Rust code and it's exhibiting
> > > > a fraction of the issues our C++ code suffers from. And those issues are usually trivially simple
> > > > to address precisely because Rust's unsafe parts can be isolated. Additionally - if you'd be looking
> > > > for another reason to use Rust - the parts of our code we have rewritten usually take 5-to-10 less
> > > > LOCs than the old C++. Heck we've rewritten Python tools in Rust yielding less LOCs than the original.
> > > > And that's not even touching things like robustness, memory usage and performance.
> > > >
> > > > Citing an article from a former colleague about the first project he wrote in Rust from scratch:
> > > >
> > > >

Much of my work using Rust has been on the Rust compiler itself, but that mostly involves
> > > > making small edits to existing code. fix-stacks is the third production-quality Rust
> > > > project I have written from scratch, the others being Firefox’s new prefs parser
> > > > (just under 1000 lines of code) and counts (just under 100 lines of code).
> > > >
> > > > My experience in all cases has been excellent.
> > > >
> > > > * I have high confidence in the code’s correctness, and that I’m not missing edge cases that
> > > > could occur in either C++ (due to lack of safety checks) or Python (due to dynamic typing).
> > > > * The deployed code has been reliable.
> > > > * Rust is a very pleasant language to write code in: expressive,
> > > > powerful, and many things just feel “right”.
> > > > * I have been writing C++ a lot longer than Rust but I feel more competent
> > > > and effective in Rust, due to its safety and expressiveness.
> > > > * Performance is excellent.
> > > > * As mentioned above, the entire fix-stacks project wouldn’t
> > > > have happened without the third-party Symbolic crate.
> > > >
> > > > Rust gives me a feeling of “no compromises” that other languages don’t.
> > > >
> > > >

Emphasis mine.
> > > >
> > > > > So, Rust must prove it is superior to modern C++. However,
> > > > > Rust still requires a huge amount of runtime afaik,
> > > > > due to the bloat of rustfmt and all sorts of other stuffs. Clearly, using Rust is no better either.
> > > >
> > > > Actually Rust has already proven many times over that it's better than C++. In production environments,
> > > > both in the FOSS and closed-source world. C++ and C are languages that were designed in the
> > > > past century; with concepts and technical limitations from a different time and without the
> > > > accumulated experience we have now. While they evolved over time their evolution is slow due
> > > > to their large legacy and how their evolution happens (design-by-committee).
> > > >
> > > > > Also recently I've found the stupidity like this:
> > > > > https://github.com/Rust-for-Linux/linux/commit/c606d85a0d3c67b8221fee5fa67028bdebd4b0cc#diff-521fe5c9ece1aa1f8b66228171598263574aefc6fa4ba06a61747ec81ee9f5a3
> > > >
> > > > Why do you call "stupidity" making a large chunk of code safe? Weren't you the one saying that
> > > > too much of that code was unsafe? Or maybe you didn't know that the body of an unsafe function
> > > > is not unsafe by default. You seem unable to understand how unsafe code works in Rust.
> > >
> > > I don't know.
> > > I read through Rust tutorial and decided that I don't like it, certainly would not use
> > > it for code that I do for my own pleasure and would never use it for production code at
> > > my own initiative. Still could use it if management insists, but that's unlikely.
> > >
> > > [O.T.]
> > > For comparison, I read through Go manual and found it palatable.
> > > Wrote (actually re-wrote from C) one lab/testing utility in go and experience
> > > was only slightly less palatable than original impression. Would be even better
> > > if code was written in Go from scratch instead of partially translated.
> > > But now, less than a year later, I already forgot just about everything I learned about Go.
> > > Right now the language I am most productive in (I mean, in golang heartland, i.e. non-GUI non-numeric
> > > stuff on non-resource-constrained but somewhat performance-sensitive environment; small and medium embedded
> > > is a different story; and GIU, which I do rarely and generally don't like is yet another story) is the
> > > same, it was for ages - "backward C++" with very minimal addition of elements of "modern C++".
> > > May be, if somehow I start to use Go regularly, it will change, because even at
> > > small scale productivity advantages of GC are noticeable to me although not huge
> > > (and Rust appears somewhat worse in that regard event relatively to C++).
> > > My feelings about C# are similar to Go - I am rather sure that potentially I can be more productive
> > > in C# than in C++, but so far it didn't happen. Except that I find overall structure of C#/Java
> > > programs (insistence on wrapping everything in classes and lack of separation between declarations
> > > and definitions) unpleasant while overall structure of Go programs is more procedural == more
> > > pleasant for me. Also, until very recently, C# had no proper slices and Go had decent if not ideal
> > > slices right from the beginning. For my programming style slices are important.
> > > And except that ~2 years ago I actually *was* more productive in C# than C++, because the job (tester
> > > for small embedded system we did for the client) included JASON parser as rather central part. C#
> > > library for that is rather good, esp. compared to utter complicated crap I saw for C++.
> > > Also, a program ended up as relatively simple GUI and C#+WinForms
> > > combo is really good for building simple GUIs.
> > >
> > > Now, please don't take this O.T. part as suggestion to use Go in Linux kernel :-)
> >
> > Well the big point that causes problems for Go but not Rust is garbage collection. I've been getting to
> > fear garbage collection in a kernel less than formerly but I can't see it being mainstream anytime soon!
> > I tried years ago to devise a safe but powerful language that didn't have any garbage collection and failed
> > to come up with anything very acceptable so I have a great deal of respect and admiration for the devisers.
> > And it copes with asynchronous programming too which I have been using in Python and Typescript and found
> > really useful. And yes I do type checking with Python too and it has found a number of bugs I might have
> > missed otherwise. I have really tried with C++ and have a nunber of large and thick books about it but
> > I just think it is too gross and doesn't add sufficient value to warrant bothering with.
> >
>
> Why do you want Linux Kernel to be rewritten in other languages? What's wrong with continuing
> using C? Just because a some group of Rust Evenglists want that? What about next time
> there is a new language which is even safer and compiled much faster than Rust? (V lang
> for example.) Are you going to allow V lang to rewrite Linux Kernel?

Looking at V I see it has garbage collection. Which is a strong point against it for a kernel.

The problem with C is it is too bug prone. Not just the memory problems but also overflow and other problems too. Linux used to have masses of asssembler in it and practically all of that has been removed. It can be improved over time. I don't know if Rust is the solution but I think it is on the right track and perhaps just a bit of syntactic sugar and careful development can round the rough corners and make it an obvious choice. How long will Linux be used in the future and in how many machine? Quite probably the usage in the future completely dwarfs by a factor of at least a thousand any use so far, and far more security will be needed too. So the real question is what kind of cosrt are we looking at if Linux security is not improved? We've had the era of worrying about 5% loss of performance - we have entered the era of worrying about the loss off millions of peoples bank details.