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.

I would say:

1. Avoid async if you can. It's way more difficult and error prone than non-async Rust. Unfortunately a lot of web stuff insists on async.
2. Don't be afraid to .clone() stuff to fix lifetime errors. It's not optimal but consider that in C++ everything is pretty much cloned by default, and nobody ever said C++ was slow.
3. Use anyhow::Result for error handling. It's the easiest option.

Wow look at that CUPS code and tell me with a straight face there aren't 5 more similar vulnerabilities waiting to be found...

Yes you can use static type hinting and the static type checker (Mypy or Pyright) will catch that. Linters (Pylint) won't.

Is that even desirable? There are other runtimes for specific things, e.g. for embedded, WASM, Fuchsia, etc. Doesn't seem like there's a one-size-fits-all runtime.

I guess the proper answer is some kind of minimum standard async interface, but presumably there's a reason they haven't done that.

I dunno really, I've avoided async Rust as much as possible due to the number of footguns it has.

Ah yeah that works. Very silly. Phones can zoom!

I agree, too little regard for backwards compatibility. They also removed distutils which meant I had to fix a load of code that used it. It was bad code that shouldn't have used it even when written, but still... seems like they didn't learn their lesson from Python 2.

It's not like it would be difficult to avoid these issues either. Everyone else just makes you declare your "target version" and then the runtime keeps things compatible with that version - Android via SDK target version, Rust with its editions, hell even CMake got this right. CMake!!

It's not a browser issue. There's some weird "responsive" thing that entirely hides the graphs. You probably just have a bigger screen.

The general difficulty of setup, poor & buggy hardware support and the inevitability of dropping to the command line are bigger issues.

You can leave comments on a commit message. What do you mean exactly?

That's not really true. C# and Java are reference-based, uses GC and can be multithreaded, and are very comparable to Rust/C++/C performance. Certainly no more than twice as bad. Whereas Python is probably 50x as bad.

The real answer is that Python developers have deliberately avoided worrying about performance when designing the language, until maybe 2 years ago. That means it has ended up being extremely dynamic and difficult to optimise, and the CPython implementation itself has also not focused on performance so it isn't fast.

But I agree the aim of offering C/C++ speed is never going to be met with Python syntax.

Wow, I would love to understand what leads to such insane views. Like, did Rust kill your father or something?

I'm actually serious, why do you have such love for a bad (by modern standards) language like C and such hatred for a great language like Rust?