I came across this when wondering if there were any efforts to give programmers additional information via audio, similar to how colors are used in syntax highlighting.
There are some interested experiments out there in modes of highlighting, such as where colors are assigned to particular variables.
IMO syntax highlighting is still the best default for navigation and general reading, but I can imagine tasks where I might want to temporarily toggle what information I'm getting through that color-of-text route.
The final comments in this text seem sobering and indicate an openness to change. I worked recently on a project to migrate RediSearch to Rust, and this was partially motivated by a decent number of recent CVEs. If SQLite doesn't have this problem, then there needs to be some other strong argument for moving to Rust.
I also think it's important to have really solid understandings (which can take a few decades I imagine) to understand the bounds of what Rust is good at. For example, I personally think it's unclear how good Rust can be for GUI applications.
It's nice that they don't dismiss out-of-hand the idea of using a language other than C (the conclusion is far less dogmatic than the editorialized title here suggests (the actual title of the page being "Why Is SQLite Coded In C?")). But let's be clear that the stability and "boringness" that C currently enjoys took literal decades to realize (pre-ANSI C was a wild-west shitshow that makes pre-ECMA Javascript look tame by comparison), and giving the same leeway to other languages probably doesn't suggest using e.g. Rust until at least 2040 or so.
It carries some weight, very roughly in the direction of formal verification. Since (assuming there isn't any unsafe), a specific class of bugs are guaranteed to not happen.
However, this repo seems like it uses quite a bit of unsafe, by their own admission.
You never have only one requirement to satisfy. For example, if you'd welcome a certain amount of contributors, your language should be something people know or people like to learn. And of course it may just be the mood of the initiator, which I find completely fine.
Personally I find rust projects very inviting. Figuring out the amount of unsafe code is easy with grep/rg (to a certain degree), the project structure is pretty standardized, etc. All of this makes even a complex project relatively easy to start with. At the same time, the language is pretty usual (C-like and readable). I understand people like it, and writing "written in rust" is a good call for those people, I guess.
"Written in JS" would communicate something else than "written in D" or "written in C++". It communicates a lot of things implicitly.
This idea about communicating size/alignment is actually something we're doing on the port of RediSearch to Rust [0]. We have an "opaque sized type" which is declared on the Rust-side, and has its size & alignment communicated to the C-side via cbindgen. The C-side has no visibility into the fields, but it can still allocate it on the stack.
It's a bit ugly due to cbindgen not supporting const-generic expressions and macro-expansion being nightly-only. It seems like this will be a generally useful mechanism to be able to use values which are not traditionally FFI-safe across FFI boundaries.
It's kind of an exploratory phase for what works sensibly with Rust's borrow checker, especially since most UI libraries/frameworks really rely on a GC.
I used to make animations with https://pivotanimator.net/ a lot as a kid, trying to make fight scenes like these. A sort of related thing is ToriBash, which is kind of a multiplayer 3D animation game where you fight each other by making decisions on which muscles to contract at each time interval.
Loved this stuff so much. I miss my summers off from school, where I would never think of a day gone as time "spent".
if you liked toribash, also check out Your Only Move Is Hustle (or YOMI hustle) which is similarly 'turn based' but in 2d. Closest thing I've found to playable Xiao Xiao.
Toribash is awesome! I last checked it a year ago but it was still alive then [1]. Worth checking out still. People who were great at it back in the day were legitimately doing dark arts with the tools the game came with. I wonder if we'll have an era of appreciation and rediscovery for pre-AI software.
Yep, had Pivot on a disk. Countless hours lost making my own sprites, and I remember the joy of downloading other peoples sprites that were actually good
I remember spending hours and hours on pivot and forums like droidz.org which used to host animations, models, and forums. I even remember learning about "easing" and different "levels" of animation and collabs as showcased on darkdemon.org[1]
I still have a bunch of .piv files on a CD backup I burned on my PC right before I switched to an iMac G5 in the summer of 2007. I should fire Pivot again and reminisce. If I recall correctly, they were absolutely crude and incredibly poorly done.
When reading this project's wiki [0], it mentions that Kanal (another channel implementation) uses an optimization that "makes [the] async API not cancellation-safe". I wonder if this is the same / related issue to the recent HN thread on "future lock" [1]. I hadn't heard of this cancellation safety issue prior to that other HN thread.
Futurelock is not about cancellation safety (cancellation is actually one solution to futurelock), though the related issues that are linked in that post are.
reply