Readit Newswhat else could you justify it doing?
Most knot enthusiasts will already know about it, but in the analog world The Ashley Book of Knots is fantastic. Beautifully illustrated; the author, Clifford Ashley, was a marine painter and spent decades documenting almost 4,000 knots.
Yup. Referring to knots by their ABoK numbers is also more practical than by their wildly varying names.
How does that work, with syscalls being unable to be called except from the system’s libc? I’d be a bit surprised if any binary’s embedded libc would support this model.
OpenBSD allows system calls being made from shared libraries whose names start with `libc.so.' and all static binaries, as long as they include an `openbsd.syscalls' section listing call sites.
> - Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
Rust moves at a pretty glacial pace these days. Slower than C++ for sure. There haven't been any big, significant changes to the language since async. Code that compiles today should compile indefinitely. (And the rust compiler authors check this on every release, by recompiling basically everything in crates.io to make sure.)
> - Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
Rust matches C in this regard. You can import & export C functions from rust very easily. The consumer of the foreign function interface have no idea they're calling rust and not C.
> - Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
Rust works pretty well on raw / embedded hardware via #[no_std]. There's a few obscure architectures supported by gcc and not llvm (and by extension rust). But it generally works great. I'd love to know what the real blocker platforms are (if any).
> - Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
Uh, I think this is possible today? Rustrover (intellij) can certainly produce coverage reports. This doesn't feel out of reach.
> - Rust needs a mechanism to recover gracefully from OOM errors.
True. You can override the global allocator for a program and use that to detect OOM. But recovering from OOM in general is tricky. I personally wish rust's handling of allocators looked more like zig.
> - Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.
Rust and C are pretty much even when it comes to performance. Rust binaries are often a bit bigger though.
See <https://sqlite.org/testing.html#statement_versus_branch_cove...>. Does Rustrover produce branch coverage reports?
Oatmeal and milk, nothing more. No fruit no nuts no sugar no honey no sprinkles of whatever. Perfect.
Rules for thee, free love for me.