[Discuss] Port Scanning

[kentborg at borg.org (Kent Borg)]

On 8/6/24 18:39, Rich Pieri wrote:
> On Tue, 6 Aug 2024 16:31:29 -0700
> Kent Borg<kentborg at 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, markw at 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.