And I deploy that using Ansible! Well, in my case a truly static HTML file and a bunch of CSS files. But yes, Caddy is great for serving static pages. If you have set it up once, you can apply the whole thing as one setup (playbook).
Your question might hint at a questionable presumption. So let me answer your question with a question - Does one have to memory map in Rust? Perhaps there are alternatives available in Rust, that you are not considering.
People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time, but the difference to unsafe languages is, that once any bug is fixed, everyone profits from it being fixed in the implementation of Rust. Everyone who uses the language and updates to a newer version that is, which often goes without code changes or minimal changes for a project. Now compare that with unsafe languages. Every single project needs to "fix" the same kind of safety issues over and over again. The language implementation can do almost nothing, except change the language to disallow unsafe stuff, which is not done, because people like backwards compatibility too much.
> People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time
Because it's technically true. The best kind of true!
Sorry, I meant to say the opposite of truth. Neither Rust nor Ada.Spark, which use LLVM as a backend, can prove via that they are correct if LLVM has bugs.
In the same way, I can't guarantee tomorrow I won't be killed by a rogue planet hitting Earth at 0.3c. So I should probably start gambling and doing coke, because we might be killed tomorrow.
> Every single project needs to "fix" the same kind of safety issues over and over again
I doubt that's the biggest problem. Each of the unsafe libraries in C/C++/Zig can be perfectly safe given invariants X and Y, respectively. What happens if you have two (or more) libraries with subtly non-compatible invariants? You get non-composable libraries. You end up with the reverse problem of the NPM world.
To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility.
There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could trip them today. They're often "But why would anybody even do that?" problems, but it's technically legal Rust and the compiler doesn't reject your program or even ICE it just miscompiles your input which is not what we want.
> To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility.
Sure. Again, I didn't say there are no bugs in Rust codebase ever, or that Rust will prevent all of errors forever.
They are working on them, but a large chunk ~50% (45 out of 103) are either nightly-only bugs (due to nightly-only features) or LLVM bugs that are difficult to coordinate/solve.
Some part of them will probably be helped or solved by a new trait resolver, Polonius. Granted, this still won't resolve all issues. Or even all trait related issues.
> There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could trip them today.
In principle, yes. In principle you should cower in a corner, because there are many scary things in the world. From microbes, to insects, to malevolent proteins, to meteors, to gamma rays, to strangelets, to rogue black holes, to gravity entering a new stable state.
In practice, you don't. Because in practice we empirically adjust our expectations to the phenomena that occur, or have occurred. So a war is very likely, but being vaporized by a stray cosmic ray is not very likely.
And most of those UB require either strange code or a weird combination of hardware, compilers, or flags. It's probably why most people don't encounter UB in everyday Rust.
Well, it is arguably worse to run an unknown, not version pinned, unconfigured formatter over your code and expect it to improve things, unless the code is an utter catastrophe in terms of formatting.
_You_ may find it irrelevant, but speak for yourself. I don't want dependencies, that are not version-pinned and checksummed running over my code. It is certainly not irrelevant to me.
If you want to call ruff directly, this doesn't change anything. It's a purely optional feature.
However, to answer the question generally: people want this for the same reason that most people call `cargo fmt` instead of running rustfmt[1] directly: it's a better developer experience, particularly if you don't already think of code formatting as an XY-type problem ("I want to format my code, and now I have to discover a formatter" versus "I want to format my code, and my tool already has that").
I remember how in a previous job the code formatter cost me time and time again. I already intentionally format my code as it makes sense and with the goal of improving readability. Then the damn auto formatter comes along and destroys this, by splitting a log call over 5 lines, because it has seen, that the log call is longer than 80 characters. Thank you for wasting 5 LoC of screen space for something that is a sidenote basically. That'll surely improve readability. So what do people do? They increase line length to 200 characters, to avoid this shit happening. Only that now it does no longer break long lines that should be broken. Unless I added trailing comma everywhere, wasting more time to make the formatter behave properly.
I am not against auto formatters in general, but they need to be flexible and semantically aware. A log call is not the same as other calls in significance. If the auto formatter is too silly to do that, then I prefer no auto formatter at all and keep my code well formatted myself, which I do anyway while I am writing the code. I do it for my own sake and for anyone who comes along later. My formatting is already pretty much standard.
Developing a good and configurable formatter is a project almost as complex as uv's main focus, managing packages. As such it will divert time and attention from its main purpose and the outcome is questionable, considering how many bad formatters are out there. For example the "opinionated" black is terrible and has no awareness of semantics.
We already develop a formatter: Ruff (https://github.com/astral-sh/ruff). Ruff and uv are built by the same team. `uv format` is just an optional front-end to `ruff format`.
I hope for uv's sake, that the formatting is always optional and that it is not "opinionated" (read: half asses and no way to configure it), but configurable. And if we get into that, well, it's a whole different tool, that they are trying to put into uv. Seems like a bad idea.
I found Anki way too heavy and the available decks mostly wrong way around for actually learning vocabulary (that is they were from foreign language to native, instead of the other way around) and switching the direction was way too cumbersome.
I have not yet found a really good tool for learning Mandarin, except for classes and actually talking with people and doing the hard work of writing the characters again and again, for which I rarely have energy or patience.
One thing I did notice in a course was, that writing an article about a topic helped a lot. It needs to be something where you use the same new vocabulary many times. But the problem with that is, that it makes my hands and wrist hurt after a couple of writings.
I was quite successful learning Mandarin by using Anki in the way that is typically discouraged, i.e., with a downloaded deck (SpoonFedChinese). I have very little time per day to devote to learning so building my own cars isn't an option, but with this and a couple of last-minute classes I went from HSK2 to HSK3.
I also find Du Chinese and The Chairman's Bao quite useful, although indeed for the writing, nothing seems to substitute actually writing. Right now I can read much more Mandarin than I can write.
Definitely by far the best way to learn to write characters. It is very expensive (compared to most apps, anyway) but its essentially obligatory to spend the money if you are serious about learning the language. When I'm learning Mandarin my favoured method is to work my way through the HSK decks on Skritter, plus a custom deck where I add my own words. Then I make sure to put at least 1 example sentence in Anki for each word that I've learned in Skritter, to reinforce it and place it in a useful context. Skritter itself rather helpfully gives an example sentence for most words. This often then leads me to adding more words to my custom Skritter deck when the example sentence contains other words I don't know yet. In this way I expand my vocabulary beyond just HSK.
reply