dmcq (dmcq.delete@this.fano.co.uk) on July 12, 2021 4:26 pm wrote:
> 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.

V lang has a garbage collection lol.

https://github.com/vlang/vinix