Aha! I was thinking about trying this exact same approach recently, so I'm glad to see I wasn't insane! Very clever.
I have been "in my spare time" (that is, never finishing) building out a page buffer mgmt system based on the one in the Umbra paper (see https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf) which has a kind of novel approach where they essentially allocate the same physical address at multiple virtual addresses but with different block/slab sizes so that they can reduce fragmentation and still support dynamic page sizes. Anyways, it seems this author is also on the same "page" (sorry) as me but focusing more on exploiting `io_uring`. Nifty.
I'm working in Rust, not Zig, but a lot of nice stuff to read through here.
I will have to read through this in more detail later when I have more brain-space available.
Nifty. I started from the part of the Umbra presentation that initially struck me as most interesting -- the allocator portion (where he talks about repeatedly MMAP_ANONYMOUS on the same address range to reduce fragmentation, etc.) I stopped working when I started pondering the bits about pointer swizzling and how I'd make that work nicely in Rust, and never got as far as the pieces that would actually do the syncs to disk.
Jinx, I'm also working on this, as a tutorial series!
I had the pleasure of hearing Neumann present the Umbra architecture on the CMU DB series webinar recently.
I'm slowly working through re-implementing the Coroutines async buffer pool paper. Blocked on trying to properly implement and understand "Morsel-Driven Parallelism":
I have the async, io_uring buffer pool written in Kotlin using it's native Coroutines but the scheduling and morsel stuff I'm still trying to understand
> Are you getting paid to work on this kind of thing, anywhere?
My dayjob is a fair bit higher level. I work on a sort of query engine on the JVM that translates an internal query IR/AST into dialect-specific SQL + other languages so you can query anything with the same frontend language:
People say that, yet it is not anywhere near Rust. But yes, I do wish people could now keep Zig submission under control. I dont want Zig community becomes another Rust community.
> I do wish people could now keep Zig submission under control. I dont want Zig community becomes another Rust community.
I don't think anybody has control over what gets posted on HN or not. People act independently and to whatever fancies them. Should the author of this blog post have avoided using Zig to keep the frontpage of HN more balanced? Obviously no. Maybe the curators of HN could prevent Zig posts from reaching the front page but they too have their own motives (eg having the frontpage reflect the topics of interest of the collective HN readership) and it might just be that these are Zig's 15mins of fame.
So I don't think your request can be fulfilled in practice and I don't think that Zig's popularity (or lack thereof) on HN will impact our community. I would recommend judging both Zig's and Rust's respective communities for how they are in their own social spaces (chatrooms, meetups, conferences) and for what they achieve on a concrete level (ie quality of the software they make), more than for what reaches the frontpage of HN with the brand name in the title.
> (Commenting from a throwaway account because they are going to lynch me otherwise.)
No, you're just using a throwaway account because you know it's going to eventually get banned, just like it has already mostly happened in the recent flurry of similar posts that you and your unsophisticated friends have made.
Unfortunately for you we play more than enough Secret Hitler to know when it's time to yeet somebody out of the server right away. Can't wait to meet your new alt, maybe next time you will be able to post more than one message before I ban you :^)
> They have a whole Discord server where they upvote and promote posts about Zig.
We have more than one Zig Discord server where people share links, most of which do get posted on HN. If you think that would be enough to game HN, you really have no idea about anything you're talking about.
> (The program won't even compile if you try to write 'hello world' with non-ASCII characters.)
Zig is not yet v1.0 and we do recommend caution to anybody that wants to invest in Zig, as they will have to deal with all the breakages that are expected in a healthy pre-1.0 language.
Yep that was me. Not interested in replying to any of the points above? Also your comment is already flagged, I would jump into a new alt if I were you.
tbh, i don't even think that promotion a product based on their language is a selling point (unless it's a lib of course!)
But this whole `built with X` is in my opinion just some 'i try to appear cool by using x language' and i don't really like it.
Don't get me wrong, i absolutely love rust, zig and go, but i believe, that you shouldn't pick a technology based on such subjective matter.
A language is just a tool to solve problems, and you don't really want to screw in a screw with a hammer, do you?
I have been "in my spare time" (that is, never finishing) building out a page buffer mgmt system based on the one in the Umbra paper (see https://db.in.tum.de/~freitag/papers/p29-neumann-cidr20.pdf) which has a kind of novel approach where they essentially allocate the same physical address at multiple virtual addresses but with different block/slab sizes so that they can reduce fragmentation and still support dynamic page sizes. Anyways, it seems this author is also on the same "page" (sorry) as me but focusing more on exploiting `io_uring`. Nifty.
I'm working in Rust, not Zig, but a lot of nice stuff to read through here.
I will have to read through this in more detail later when I have more brain-space available.