One trick we've been playing with on the Matrix side is figuring out how to tunnel encrypted Matrix over other transports - so you could absolutely use it, layered on top of ATproto spaces, as a way to get E2EE DMLS metadata-protected realtime voice/video/chat but tied to ATproto DIDs and permissions. We're in the final stages of (at last) finalising MatrixRTC, the E2EE group voip stuff in Matrix, which would pair nicely with this.
The "portable Matrix" idea is currently nicknamed Tachyon, and is earlier stage at this point, although I did a Matrix Live about it a few months back: https://www.youtube.com/watch?v=jc7yfec3iIQ
Bluesky has live video but it's a Twitch stream. ATProto itself is about databases and ways to replicate them. You can store pictures and videos there, but you wouldn't normally use a database replication protocol to actually transmit live video.
Yeah I think if Julia had a plain interpreted mode or a base template JIT that could tier up to LLVM's, they could drive that execution latency down a lot.
I've often wondered how viable it is to use AI to fill out the ecosystem gaps in awesome but niche languages (still looking at you OCaml...).
I've not gone too deep down this train of thought because a standard library/ecosystem should be solid and I don't think LLMs are quite there... but if we can use LLMs+Lean maybe we can get the quality we need to bootstrap more of the Lean ecosystem?
Yeah when things like this have happened on fridays before they've reset everyone's limits etc. Would not be surprising if this is the pretext for something of this sort.
It's still shocking to me that the approach taken wasn't to have Claude write a tool that translates Zig to Rust. I imagine it would've been cheaper, deterministic, and each iteration would produce a better tool.
This seems like a much much harder problem than having a model translate between the two languages. I think people in general are way overvaluing determinism. In most cases, it doesn’t matter if the output from two runs is different as long as it accomplishes the desired goal.
Never thought of cross language code mods to be a thing but surely there are libraries out there that deal with the interop of different ASTs across languages? Seems like an interesting area of research.
If you have a goal of making your OS usable, you have to design it with this in mind. Build your kernel and driver subsystem in a way that legacy OS interfaces can be implemented on top of them. Find ways to repurpose existing infrastructure so you don't have to do all the work yourself.
I guess I interpreted this part of their README as implying that the author found RC too fragile
> Reference counting buys correctness and composability, but at a cost.
> Disadvantage #1: you must balance every reference. Each value_create, value_retain, and each operation's implicit retain of its operands has to be matched by a value_release. Forget one and you leak; do one too many and you free memory that is still in use. The training examples in examples/ are verbose precisely because they are scrupulous about this in their error paths; that verbosity is the price of leak-free C.
I’d put it this way: though the idea of ref counting felt very natural at the beginning for my use case, at some point I realized there were probably better techniques to achieve the same goal. I found myself multiple times writing nonsense like:
sum = value_add(v1, v2)
mul = value_mul(sum, v3)
[...]
value_release(sum)
value_release(mul)
so that later I could release the sum. When you only have one intermediate value it’s still acceptable, but at 3-4 it starts getting cumbersome.
After asking for feedback, someone rightfully pointed out that the better and faster approach for an autograd engine is using an arena allocator. My reason for saying “rightfully” is that arenas are ideal when you have many “objects” that have the same lifespan, such as the values involved in the forward/backward pass. RC is better when you have a lot of “objects” with independent lifespans.
I think what would matter from this kind of measure is whether a project's use of unsafe actually has undefined behavior. Like the number of unsafe blocks is not really my concern as much as what the unsafe blocks are doing. If you build a single faulty abstraction via unsafe, anything that uses it is broken.
In my projects, it usually comes down to a scenario like needing to write inline assembly or invoke a foreign function, where there are close to zero guarantees the language can give me.
Honestly, given how trivial it is for mythos-class models to identify an exploit, I’m going to assume any sufficiently large project written in C, C++, or Zig is riddled with latent vulnerabilities and compromised.
