radarroark (u/radarroark)

radarroark commented on Wine 11.0 gitlab.winehq.org/wine/wi... · Posted by u/zdw

Rohansi · 22 days ago

I'm curious why you'd want this over using a GUI library that is actually cross-platform? The way you've worded things suggests to me that you're building something new.

radarroark · 22 days ago

I want to go back to making desktop programs the way we used to before they turned into web apps that bundled chrome. I know I should just use Qt but I have some experience already with win32, and all the programs I have fond memories of are written with it (foobar2000, winamp, Everything, etc).

radarroark commented on Wine 11.0 gitlab.winehq.org/wine/wi... · Posted by u/zdw

radarroark · 22 days ago

Anyone have experience with distributing win32 programs for Linux and/or MacOS by bundling wine? I take it that statically linking is out of the question, but I am guessing you could make an AppImage binary for linux that includes wine, and for MacOS you could include wine in the app bundle. I haven't tried either though. I'm interested in this so I can use win32 as a cross-platform desktop GUI library.

radarroark commented on · Posted by u/radarroark

damnitbuilds · 22 days ago

This looks like Python's pickling: https://docs.python.org/3/library/pickle.html

radarroark · 22 days ago

Not quite the same as the object serialization you'll find in many standard libraries, because xitdb can read/write data incrementally, so you can work with large-than-memory data sets.

radarroark commented on · Posted by u/radarroark

explodes · 22 days ago

Point 1 may be a problem if you're embedded. Otherwise, enjoy the fact that the 150,000 lines of c-code are some of the most tested lines of code on the planet.

Point 2 doesn't tackle the reasons why there is a mismatch between in-memory representation and tabular data. Some benefits include the wins obtained from a schema built to utilize "normal form". Object databases have their place, but so do fully normalized database tables.

Point 3 doesn't strike me as useful. I don't find myself reverting rows to previous points in history that often, if I ever have. Tracking versions of rows is useful. I would argue that "reverting" is not, since the reverting would be better tracked by adding a new version as a forward update.

Overall, sure, a new, "light weight", object database that uses data structures* may have a place somewhere. But to replace SQLite? I think not.

*The Java API gives me the same recoil as Java JSON API. Pulling out data key by key feels like pulling teeth tooth by tooth.

radarroark · 22 days ago

> Point 1 may be a problem if you're embedded.

Large dependencies are not only a problem in embedded programming. That sort of thinking is how we got to the explosion of dependencies and software complexity we're in today.

> Object databases have their place, but so do fully normalized database tables.

Agreed, but you can build a stricter data model on top of generic data structures. The idea is to keep them separate rather than hard-coding just one specific data model. See for example running DataScript on top of xitdb: https://gist.github.com/radarroark/663116fcd204f3f89a7e43f52...

> Tracking versions of rows is useful. I would argue that "reverting" is not, since the reverting would be better tracked by adding a new version as a forward update.

"Adding a new version" to revert is exactly what xitdb does. See this line, which appends a new "version" of the database whose value points to an older version:

    history.append(history.getSlot(historyIndex));

It's fine if you don't find immutability useful directly, but it is also what enables reading the db while writes are happening, which is clearly useful even if you don't care about time travel.

radarroark commented on Databases in 2025: A Year in Review cs.cmu.edu/~pavlo/blog/20... · Posted by u/viveknathani_

SahAssar · a month ago

How do you deal with deletion requirements in a immutable database? Like how do you delete personal data when requested?

radarroark · a month ago

The fastest approach is to just zero out the data. Alternatively you can rebuild the entire database while preserving only the data accessible in the latest copy of the db (kinda similar to SQLite's VACUUM command).

radarroark commented on Databases in 2025: A Year in Review cs.cmu.edu/~pavlo/blog/20... · Posted by u/viveknathani_

beders · a month ago

While the author mentions that he just doesn't have the time to look at all the databases, none of the reviews of the last few years mention immutable and/or bi-temporal databases.

Which looks more like a blind spot to me honestly. This category of databases is just fantastic for industries like fintech.

Two candidates are sticking out. https://xtdb.com/blog/launching-xtdb-v2 (2025) https://blog.datomic.com/2023/04/datomic-is-free.html (2023)

radarroark · a month ago

People are slow to realize the benefit of immutable databases, but it is happening. It's not just auditability; immutable databases can also allow concurrent reads while writes are happening, fast cloning of data structures, and fast undo of transactions.

The ones you mentioned are large backend databases, but I'm working on an "immutable SQLite"...a single file immutable database that is embedded and works as a library: https://github.com/radarroark/xitdb-java

radarroark commented on Instant database clones with PostgreSQL 18 boringsql.com/posts/insta... · Posted by u/radimm

chamomeal · 2 months ago

Does datomic have built in cloning functionality? I’ve been wanting to try datomic out but haven’t felt like putting in the work to make a real app lol

radarroark · 2 months ago

Surprisingly, no it does not. Datomic has a more limited feature that lets you make an in-memory clone of the latest copy of the db for speculative writes, which might be useful for tests, but you can't take an arbitrary version of the db with as-of and use it as the basis for a new version on disk. See: https://blog.danieljanus.pl/2025/04/22/datomic-forking-the-p...

There's nothing technically that should prevent this if they are using HAMTs underneath, so I'm guessing they just didn't care about the feature. With HAMT, cloning any part of the data structure, no matter how nested, is just a pointer copy. This is more useful than you'd think but hardly any database makes it possible.

radarroark commented on Instant database clones with PostgreSQL 18 boringsql.com/posts/insta... · Posted by u/radimm

radarroark · 2 months ago

In theory, a database that uses immutable data structures (the hash array mapped trie popularized by Clojure) could allow instant clones on any filesystem, not just ZFS/XFS, and allow instant clones of any subset of the data, not just the entire db. I say "in theory" but I actually built this already so it's not just a theory. I never understood why there aren't more HAMT based databases.