ssokolow
As for "and also not that Rust's design makes it more difficult to package", give https://blogs.gentoo.org/mgorny/2012/08/20/the-impact-of-cxx... a read.
TL;DR: It's not a Rust thing. C++ suffers from the same problem when you use templates in your APIs... it just emits a .so file with no contents if you expose only templated APIs. It's fundamentally a problem of "Unless you're willing to spend Swift-level engineering money and still accept compromises Rust and C++ can't afford, dynamic linking in the presence of monomorphic generics is a problem even research languages haven't solved".
...same as the warts in async Rust. What you're seeing is a cutting-edge language slamming up against the limitations of what cutting-edge programming language research has figured out.
At least, with Rust, you've still got the dependency tracking and automatic RUSTSEC advisory tooling you don't get with header-only C libraries.
There's a reason they offer "download and run this .exe" on Windows and "download and run this .sh" on POSIX platforms.
...plus, as they mention in the tiny "other installation methods" link, none of the distro packages are official and people have a nasty habit of coming to you for support even if you didn't point them at the downstream-patched distro package they found.
Given how much distro packagers have tried to contort Rust to fit into their pre-existing `.so`-centric packaging system, I can see why Rust upstream would want to downplay that option to avoid headaches.
Let's compare what some other supplementary package managers tell people to do:
https://security.googleblog.com/2022/12/memory-safe-language...
(And it's entirely possible it was back when I ONLY saved a copy of articles of that tier of "I may need this again" via ScrapBook/WebScrapBook, I haven't yet set up the browser/indexer for those and a few quick ripgrep searches aren't turning it up.)
I believe it had something to do with the JVM having some flawed semantics which couldn't be fixed without breaking compatibility with existing bytecode.
On an academic level, memory safety is split into "spatial" and "temporal" cases and one that Wikipedia calls "spatiotemporal", with reading off the end of "capacity" being a spatial memory safety bug and reading within "capacity" before initializing being a temporal memory safety bug.
The other temporal memory safety types as Wikipedia enumerates them are:
* Use after free
* Double free
* Mismatched free (stuff like not using the free() from the same DLL that called malloc(), mixing up malloc/free with new/delete, etc.)
TL;DR: Look at it from our perspective. It's not reasonable for us to be beholden to the limitations of build targets we never consented to supporting and possibly didn't even know about.
Just look at how long it took LLVM to catch up to GCC. Writing a competitive optimizer pipeline is hard work.
"No room for a language above assembly and below Rust" is a design goal for what it's reasonable to build with it.
If anything, using LLVM for the default backend is completely on-brand with how much priority Rust puts on being suitable for partially or incrementally rewriting C codebases.
(Sorry for the slow reply. The tab got buried.)
I don't like having to contort my code to fit each unit of work into the API of `std::panic::catch_unwind` so I can responsibily distrust the transitive dependencies beyond the reach of my Clippy lints.
...though, given the inconsistent naming of consistently laid-out buttons, I think anything that makes its way into Unicode should include something that follows the lead of what Batocera Linux does on their Wiki and with custom emojis in their Discord.
See https://wiki.batocera.org/configure_a_controller for an example of how they look inline but the gist is that it's an outline of the SNES-originated diamond of action buttons that pretty much everyone but Nintendo uses these days, with one of the circles filled in to represent the button in question.
There is a combining character that, by its description, sounds like it should be implemented to do the desired thing (U+20DD Combining Enclosing Circle), but my fonts don't render it very well when I stuff geometric characters matching the PlayStation buttons into it.
Without spaces: △⃝□⃝×⃝○⃝
With two spaces between each one so you can see how "enclosing" is getting interpreted: △⃝ □⃝ ×⃝ ○⃝
For the Markdown renderer I'm working on to replace WordPress for my blog, I resorted to shortcodes which resolve to CSS styling the `<kbd>` tag with `title` attributes to clarify and the occasional bit of inline SVG for things where I didn't want to specify a fixed font to get sufficient consistency, like PlayStation button glyphs.
(In all fairness, it's a nerd-snipe made based on the idea that I'll be more willing to blog about things I have nice tools for. I don't currently typeset button presses in any form.)
Python is the most infamous example of how putting something in the standard library doesn't automatically mean everyone will use it.
For example, as of the end of the Python 2.x cycle, Python had urllib and urllib2 in the standard library and everyone said to ignore them and use Requests... which contains a urllib3, the maintainers of which refuse to ever add to the standard library.
Python had/has a bunch of "use Twisted instead" network protocol implementations. Python's standard library XML implementations carry a big warning to use the third-party `defusedxml` crate if you are processing untrusted data. etc. etc. etc.
I have next to no Java experience, but I vaguely remember it also having some similar cases of common wisdom being to ignore the standard library-provided solution.
I still think the "because it's not in the fast path" part of "Most software will not see a bottleneck because of bounds checking because it's not in the fast path" is a bit too much of a blanket statement and could detract from the admonition to benchmark very carefully before optimizing but, otherwise, I agree.
They tried doing a comparison between ReadySet compiled normally and ReadySet with bounds checking removed so thoroughly that they needed to use a patched toolchain to achieve it and found the difference to be within the noise threshold.
Their conclusion was:
> At the end of the day, it seems like at least for this kind of large-scale, complex application, the cost of pervasive runtime bounds checking is negligible. It’s tough to say precisely why this is, but my intuition is that CPU branch prediction is simply good enough in practice that the cost of the extra couple of instructions and a branch effectively ends up being zero - and compilers like LLVM are good enough at local optimizations to optimize most bounds checks away entirely. Not to mention, it’s likely that quite a few (if not the majority) of the bounds checks we removed are actually necessary, in that they’re validating some kind of user input or other edge conditions where we want to panic on an out of bounds access.
I was just pointing out that Unicode itself has various forms of normalization and normalization-adjacent functionality that people are far too unaware of.
...and learn about the TR39 Skeleton Algorithm for Unicode Confusables. Far too few people writing spam-handling code know about that thing.
(Basically, it generates matching keys from arbitrary strings so that visually similar characters compare identical, so those Disqus/Facebook/etc. spam messages promoting things like BITCO1N pump-and-dumps or using esoteric Unicode characters to advertise work-from-home scams will be wasting their time trying to disguise their words.)
...and since it's based on a tabular plaintext definition file, you can write a simple parser and algorithm to work it in reverse and generate sample spam exploiting that approach if you want.
https://www.unicode.org/Public/security/latest/confusables.t...
> and CD-ROM!
I think you mean Microsoft Windows's Joliet extensions to ISO9660 which, by the way, use UCS-2, not UTF-16. (Try generating an ISO on Linux (eg. using K3b) with the Joliet option enabled and watch as filenames with emoji outside the Basic Multilingual Plane cause the process to fail.)
The base ISO9660 filesystem uses bytewise-encoded filenames.
Unicode just took it upon themselves to reliably round-trip legacy text... thus the precomposed forms.
Most of the other complexity and technical debt is in the writing systems themselves.
The .graphemes() method in Rust's unicode-segmentation crate takes an is_extended boolean as an argument and, if you set it to false, you're iterating legacy grapheme clusters.
As for the mouse cursors, I don't think they qualify as personal information under the GDPR, but IANAL.
TL;DR: They had a transient glitch in their network switch and, because Windows uses UTF-16 when sending remote event logs over the wire, whenever it dropped a single byte, it had the effect of swapping the endianness of the messages, resulting in scary Chinese text in the logs.
You could get the same effect by naively applying byte-wise processing to UTF-16 or UTF-32, or having an off-by-one error.
UTF-8 is self-synchronizing so one-byte errors like that only lose you one character, rather than corrupting the entire stream going forward.
TL;DR: Unicode is complicated because some non-Latin writing systems are complicated and those non-Latin writing systems account for over a quarter of the world's population. (They're either majority or present in India, Indonesia, Pakistan, Bangladesh, the Philippines, etc.)