On 8/6/24 18:39, Rich Pieri wrote:
On Tue, 6 Aug 2024 16:31:29 -0700
Kent Borg<kentb...@borg.org> wrote:
C/C++ compilers are more mature, so there are better optimizers for
C/C++ programmers. This is an advantage for C. Though, not always:
sometimes the machine code will simply be as fast as it possible, and
sometimes Rust will be that fast, making it a wash. But on average,
at least for the moment, C/C++ has the advantage.
Maybe. Rust is a front end to LLVM which frequently generates faster
binaries than GCC. Not always, but frequently. This puts Rust in a very
good place. And it's only going to get better.
Rust is not perfect. It is a very big language, and a lot of that is
necessary: Rust does more than do other languages. But the syntax is
also very big, including are a lot of things that to me feel like little
one-off specials that are considered qualty-of-life features. But they
feel like featuritis to me. I wish the language were more elegant. But I
admit this is a matter of taste, a judgement call.
But I do have a hunch that the language could have been more elegant,
too. But it will only be from the hindsight of using Rust for a few
years that people will be able to figure out that simpler way, and then
there will will be a Rust follow on that will have all of the advantages
of Rust, but the friendliness of Python.*
In contrast, whenever I have seen an odd larger design decision of the
language, or in std, and I looked into it, I have been impressed. They
think long and hard and carefully about everything they do. They have
good reasons for the decisions they make.
This impressed me even more when I learned a little Go. Jeeze, one
quirky thing after another. Almost as if an individual decided to
modernize C and scratch all of his personal itches along the way. And
when I saw that Go mutexes around data are merely advisory, forget to
use them and the program can still muck with the data (I hope I am
remembering this correctly), I was horrified.
Go is pretty new, how in hell could they make such a decision? By not
thinking very hard. Which is par for this era. Nothing is designed
anymore. We have "design patterns" to pick from instead, and if the PR
is small and properly formatted we are good to go!
I like the quote in section 8:
Rust is a systems programming language that runs blazingly fast,
prevents segfaults, and guarantees thread safety.
Oh. Then there's this. Specifically section 9 under Taking the Plunge.
https://bcantrill.dtrace.org/2018/09/18/falling-in-love-with-rust/
I do like that quote:
Yes, you read that correctly: *my naive Rust was ~32% faster than my
carefully implemented C*.
Again, the posting says this requires further investigation with the
early guess that Rust is being nicer to the cache. Something about being
more store-heavy than the C. I don't see that stores should be faster,
but the mix matters, and not needing expensive memory barriers to
quickly do a read could certainly help a lot.
Slight change of subject: A couple days ago I saw DARPA is firing up a
project to replace all C with Rust. Seems ambitious.
Mark should warn them.
On 8/6/24 14:53, ma...@mohawksoft.com wrote:
I call BS on that whole paragraph. Rust is OK, but ANYTHING you can write
in Rust can be written to be faster in C/C++.
-kb
* Some of the changes I am imagining would be merely presentation
differences where the underlying thing is essentially the same as Rust,
but others might be fundamental.
For example, there might be a better way to accomplish what the
ownership model does. I recently read a farewell-to-Rust posting by a
game developer who had been using Rust for years and finally gave up.
One of the key things is Rust requiring big refactorings too often,
particularly too often for game development where they apparently make
big changes and move fast. I'm not sure, but I suspect they need more
flexible and general purpose data structures to model their synthetic
worlds whereas Rust insists data structures be correct and bespoke for
the purpose. Yes, Rust makes refactorings much easier and pretty bullet
proof, but it is still work.
Another example: the falling-in-love post also admires Rust's error
handling, and s/he is right about the value of functions returning a
Result and requiring the calling function open it up to discover whether
it was an error or not. (Sure, ignore the error if you want, but that is
a sinful bug of commission not an innocent "Damn I forgot to check
whether it was negative!" bug of omission.) THis is good. But Rust's
larger error handling is a mess. There are two popular crates that
everyone (smart) uses. One to replace tons of boiler plate in how
library-like functions report errors up, and the other crate replaces
tons of boiler plate in how application-like functions handle errors
they receive. I don't think this is a place where Rust has made mistakes
so much as I think they were insufficiently clever, and the fact that
someone needed to write these is the demonstration. (But someone could!
Rust is very flexible in how it can be extended. Bravo.)
And I expect there will be various fundamental changes in this imagined
future python-of-rust language.
_______________________________________________
Discuss mailing list
Discuss@driftwood.blu.org
https://driftwood.blu.org/mailman/listinfo/discuss
