Oh, sorry. I stand corrected then.

That is not actually a "data race". It is a race condition for sure, but a data race is a very specific thing - where two threads access the same location at the same time and at least one is a write.

That could be unsafe in Rust because it might lead to reading "impossible values" like an enum that isn't equal to any of its variants. Therefore safe Rust must prevent it or there's a soundness hole.

I'm willing to bet that it's AI. It soft-contradicts itself quite often, emphasising that C++ is "Performance First", but then also claiming stuff like "Rust achieves memory safety with zero runtime overhead".

Edit: What I am trying to say is that I have seen text like this in LLM output quite often, if the LLM is mixing text from different sources in its training data.

Also, there is just wrong stuff in the text itself, not only in the conclusion. For instance the claim that Rust's type system makes data races impossible. They are easier to avoid, but there is nothing stopping you from writing data races... Here, for instance, have a data race in safe Rust...

The whole premise is wrong, since it's based on the presumption of C++ and Rust being effectively generational siblings, with the C++ "designers" (charitable) having the option to take the Rust route (in the superficial narrow aspects covered), but choosing not to do so. When the reality is that C++ was the intellectual pollution product of "next C" and OOP overhype from that era (late 80's/ early 90's), resulting in the "C with classes" moniker.

The lack of both history (and/or evolution) and paradigm talk is telling.

Doesn't say anything you didn't already know. Probably written with AI.

Also the conclusion is wrong:

Neither approach is universally superior.

The Rust approach is obviously superior.

Thanks for pointing out. It's fixed now.

The blog link goes to a 404

As someone who's relatively new to rust, i feel that the slogan is pretty accurate, even when programming in other languages, i see that I'm way less prone to anti patterns and and write a better api for modules while barely thinking about it.

Mostly because i copy what design patterns work and are prevalent in rust's libraries and api.

Hence my question above

That's the case of for any optimization work, really

Now that should be weighted against the amount of work the rewrite is, among other factors. But anyway the article does not give any specifics

The way to really optimize Python code, is by reducing the amount of Python code in your program, since Python itself is dog slow. Instead, you want to offload as much of the work as possible to modules written in compiled languages. So completely switching to Rust, or another compiled language, is simply taking that strategy to its logical conclusion

You're correct in your assessment of the worst-case of distro maintainers, however many distro developers/maintainers do contribute to the upstream ( Debian policy explicitly encourages it, I only speak for Debian because that's the only project I've worked in) and do vet and understand the software.

"It can't be better". Except distro maintainers can block it from being included if they find errors. As noted above they also often file pull requests against the upstream. This happens a fair amount actually.

Cool parasitic fungus too!

It would only be propaganda if it wasn't organic. But people just really actually like it and like to talk about it.

If you don't like that, may I suggest not engaging with the content and just scrolling past it?

Honestly, I could not make myself read till that critique part. As much as I would like to hear what Rust actually is good for, that article is yet another cheap advertisement

Well, it really is. Went for Rust from Python and gained faster execution - wooow, no waaaay. No other language can do that (sarcasm, and to add more to it: did they ever try to actually optimise code first?)

Now this makes sense. Thank you from someone who didn't know

I'm a rust stan but honestly, I think your comment is correct. I remember the website change at the time, but what I didn't notice then was the catastrophic loss of information density.

The old bullet points really are the the money, they explained to anyone who knows programming languages what makes rust actually special. By contrast the new website suffers severely from buzzword-itis and design over content.

Yeah, as I'm implementing this, I'm also now noticing how problematic that crate split is.

If you want to generate code which uses (non-generated) types that your crate provides in its public API, you have to re-export the macro from a separate crate that also re-exports the types.
That in itself is clunky, but it's just complexity for the implementer, not the user, so it's fine.

But where it stops being fine is that this means you cannot easily provide a usage example in the macro's documentation.
If you try to use it like normal, it has to generate code referring to your API crate, which will not be defined in your macro crate, so the documentation test won't compile.

So, basically your choices are:

• Do some hacky horseshit, where you try to re-define the public API in the usage example.
• Provide a usage example, which is not checked for compile errors.
• Provide a usage example on the module that re-exports the macro rather than on the macro itself.
• Don't provide a usage example.

And yeah... if you've coded Rust for long enough, you will recognize these patterns of bad/missing usage examples, which is particularly problematic, because proc-macros are rarely terribly obvious to use. Really hope they can fix this sooner rather than later.
As far as I can tell, it would even be a valid fix, if editors and such consistently showed the documentation declared on top of the re-export, then you could write out your usage example there.

it has modules for everything

Not everything. PyYAML, Pydantic and Typer are things I commonly want in scripts that aren't in the standard library.

Simply do pip install anything. But best practice is to use a python virtual environment and install packages into that one.

It's more than "best practice". It's mandatory on many recent Linux distros. And yeah setting up a venv and installing dependencies is not something you want to have to do for each script you run.

Its one of the slowest to write code in.

It depends what your goal is. If you want robust code that works reliably then I would say Rust has the edge still. Yes it will take longer to write but you'll spend way less time debugging it and writing tests.

Unfortunately, proc-macros need to be in a separate crate. It'd be great if we don't have to do that.

Python is actually super known for its batteries included approach, it has modules for everything. Simply do pip install anything. But best practice is to use a python virtual environment and install packages into that one. Cargo does this by itself in each project and doesnt install modules globally.

But python code is so much easier to write. Its basically almost English and the syntax is easy. Rust... Not so much. Its quite ugly.

Its a systems programming language. Designed to be fast to execute. Its one of the slowest to write code in. But sure, with Ai, you can just ask for a rust script and it will run.

That's kind of the point. You can do it in most languages, so why use a shitty one like Bash? Use a good language like Rust!

Also there are aspects of languages that make many languages less suitable for this application though. For example Python, because you can't use third party dependencies (or at least you couldn't; I think uv has an equivalent of cargo script now). Java would be a pretty awful choice for example.