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?