Hacker News Reader

refseton 7 Databases in 7 Weeks for 2025

The upcoming XTDB v2 is a SQL-first engine. We also built an experimental Clojure/Datalog-like 'XTQL' language to go along with it, to provide some continuity for v1 users, but the primary API is now SQL over the Postgres wire protocol, where we implemented a variation on SQL:2011 - see https://docs.xtdb.com/quickstart/sql-overview.html

refseton Amazon Aurora DSQL

Agreed, but it seems likely that people will casually pick this up instead of actual Postgres without fully appreciating the potential for consistency issues. I'd feel happier if AWS marketing applied your description of the value proposition - 'DynamoSQL'.

refseton Amazon Aurora DSQL

> Aurora DSQL isolation level is equivalent to PostgreSQL Repeatable Read.

So it lacks Serializable isolation also, but I guess that's the secret to how it "offers the fastest distributed SQL reads and writes".

refseton SQLite: Outlandish Recursive Query Examples

It doesn't help that SQL's recursive CTE model is a bit odd - Frank McSherry proposed a much nicer alternative (which Materialize has implemented): https://materialize.com/blog/recursion-in-materialize/

refseton Jepsen: Bufstream 0.1

> The Kafka transaction protocol is fundamentally broken and must be revised.

Ouch. Great investigation work and write-up, as ever!

refseton Bthreads: A Simple and Easy Paradigm for Clojure

Interesting, thanks for digging that answer out. HN is a treasure trove!

refseton Bthreads: A Simple and Easy Paradigm for Clojure

Agreed, I would love to see a large scale implementation and experience report. I also wonder about combining the Bthreads model with the notion of 'durable execution', as demonstrated by the folks at DBOS: https://www.dbos.dev/blog/what-is-lightweight-durable-execut...

refseton Bthreads: A Simple and Easy Paradigm for Clojure

Context from the previous post in the series:

> Behavioral Programming is a relatively new programming paradigm that excels at isolating and composing behaviors in event driven system.

> Behavioral programming was invented by David Harel[0], who also invented statecharts in 1987. It uses independent units of behavior, called bthreads, which are coordinated in a pub-sub protocol.

[0] https://cacm.acm.org/research/behavioral-programming/ (2012)

refseton Drasi: Microsoft's open source data processing platform for event-driven systems

Like a many-to-many join table?

refseton How to do distributed locking (2016)

DBOS [0] is outwardly similar although it's much younger. IIUC, internally DBOS is able to be more efficient and support lower latencies than Temporal because of the way it can push work down into Postgres stored procedures.

[0] https://www.dbos.dev/

refseton Jank development update – Moving to LLVM IR

** Clojure is _a_ language [...]

(apologies!)

refseton Jank development update – Moving to LLVM IR

> there are a host of specialized optimization strategies only possible when compilation can happen during runtime

That's a big part of why Jank is interesting to me, because it can properly embrace the idea of runtime JIT using LLVM. The JVM may still have an edge with profile-guided optimization for the foreseeable future, but perhaps Jank can help close that gap and support even more advanced possibilities for data-intensive workloads, e.g. along the lines of https://www.lingo-db.com/

refseton Jank development update – Moving to LLVM IR

I'm just an enthusiastic bystander so I don't know the answer. Hopefully Jeaye can chime in.

refseton Jank development update – Moving to LLVM IR

Clojure is language that was designed to be 'hosted' on many different underlying language runtimes, not just the JVM/Java. If Jank can implement clojure.core correctly (pass the tests!) and handle .cljc files then it counts as Clojure in the eyes of the community. See also ClojureScript, ClojureDart, ClojureCLR, SCI, Cherry, Electric, Rama etc.

refseton Jank development update – Moving to LLVM IR

Jank should be able to produce significantly smaller binaries than Graal native images at the very least, but the potential for performance gains looks to be rather large, e.g. per "jank has been consistently beating Clojure in benchmarks" [0]

[0] https://jank-lang.org/blog/2023-07-08-object-model/

refseton Jank development update – Moving to LLVM IR

Fast compilation is undoubtedly more essential in the Lisp paradigm of REPL-driven, interactive programming with S-expressions than in other languages. A pre-requisite perhaps for the world to 'Stop Writing Dead Programs' [0]

[0] https://jackrusher.com/strange-loop-2022/

refseton Jank development update – Moving to LLVM IR

Jank uses Boehm GC (written in C, also used by the likes of Inkscape, Guile and Mono) - it is discussed a little in the previous blog posts, e.g. https://jank-lang.org/blog/2023-07-08-object-model/

refseton CRLF is obsolete and should be abolished

Not a capital-T Teletype but it seems like it was widely used as a teleprinter and had similar mechanical constraints/requirements. The post does touch on this language ambiguity:

> Teletypes (technically "teleprinters" - "teletype" was just the most popular brand name)

refseton CRLF is obsolete and should be abolished

Not sure whether this changes anything about your critique, but note that the IBM 2741 terminal embedded a Selectric typewriter:

> Selectric-based mechanisms were also widely used as terminals for computers, replacing both Teletypes and older typebar-based output devices. One popular example was the IBM 2741 terminal

https://en.wikipedia.org/wiki/IBM_Selectric

refseton Game Programming in Prolog

DataScript already supports processing n-ary relations, it's just not how the data is naturally stored when you use `d/transact!`. Even though it's all in-memory anyway (ignoring the recent addition of durable storage on the JVM) the main benefit you get when 'storing' data is the suite of persistent B-Tree EAVT indexes. DataScript also let's you store plain vectors (and most other objects) as values, which you can access from the Datalog, so it's very flexible really. And learning Clojure is good fun.

If you want to try something more exotic I would be tempted by https://logica.dev/ + some flavour of SQLite (potentially in-memory/WASM).

refseton Game Programming in Prolog

This is a consequence of the Datomic information model which is focused on handling a single universe of triples (to facilitate natural schema growth) instead of independent n-ary relations. However unlike when building serious business applications, for most simple games you probably won't ever care about the ease of handling the schema growth of persisted data. You would likely care more once you think about supporting long-lived multiplayer environments or introducing played-defined concepts within the game.

refseton Game Programming in Prolog

You'd probably be interested by this approach of chaining the DataScript rules to derive the next frame if you haven't seen it already: https://frankiesardo.github.io/minikusari/#!/minikusari.tuto...

refseton 50 Years of Queries

I could also believe many groups arrived at the term independently, deriving naturally from conversation along the lines of: "These are the data on which decisions are based"

See also Rich Hickey's definition of "basis". I bet he spent a good while digging into the etymology.

refseton 50 Years of Queries

> "data base" was a term in use predating that 1963 publication

I agree, and actually reading through some of it only reinforces the feeling. I suppose the real answer could well still be CLASSIFIED, if it was even recorded in the first place.

refseton 50 Years of Queries

> The origins of the term “data base” and subsequently “database” go back a long way. The first sighting of the term was its use in 1963 by the System Development Corporation who sponsored a symposium with the title “Development and Management of a Computer-centered Data Base”. The term “data base” was picked up by the contributors to the symposium in the titles of their papers.

From Section 1 of "Nineteen Sixties History of Data Base Management" https://dl.ifip.org/db/conf/ifip3/histedu2006/Olle06.pdf

refseton 50 Years of Queries

Good overview, although a rather important aspect of the 'resilience' that's not really covered here is the way that SQL technologies navigate and sustain performance trends. Relational databases are sticky in large part because the implementations are always getting faster and more sophisticated.

SQL being a declarative language means that applications built on top of it can relatively easily take advantage of new hardware and increasing parallelization without changing any code (in addition to all manner of new software tricks, compression/optimization/joins/etc).

refseton CouchDB 3.4.1 Released

As it should be :)

refseton CouchDB 3.4.1 Released

Not sure whether this is a Lotus Notes reference also, but it should be! (that's where the idea for CouchDB came from)

refseton Insights after 11 years with Datomic [video]

Datomic is built around a simple log of fully serial transactions. It doesn't have MVCC or other such magic to coordinate concurrent writers, and this means (1) read-only queries don't require open transactions and (2) the whole stack can have mechanically sympathy with this accrete-only design, affording massive efficiency and scaling potential. Capabilities may look similar on the surface but that's where the similarity ends. Take a look at slides 13 & 14: https://qconsf.com/sf2012/dl/qcon-sanfran-2012/slides/RichHi...

Datomic is much more similar to Delta Lake or Apache Iceberg than to a classic RDBMS like Oracle in that respect - but then that analogy severely undervalues it's information modelling qualities.

refseton Insights after 11 years with Datomic [video]

> convincing a query planner to do the right thing requires deep expertise in the query planner

The advantage is that that can be somebody else's job though, and ideally (eventually) an AI's job.