LukeEF

'People struggling should just shut up 'cause everything is great - look at these charts'

I am not sure of the exact statistic, but something like 95% of all production databases are less than 10GB. There seems to be a 'FAANG hacker' fascination with 'extreme-scale' which probably comes from seeing the challenges faced by the handful of organizations working at that level. Much of the time most graph database users want (as in why are they there) a DB that allows you to flexibly model your data and run complex queries. They probably also want some sort of interoperability. If you can do that well for 10GB, that is holy grail enough. We certainly found that developing graph database TerminusDB [1] - most users have smaller production DBs, more lightly use bells and whistles features, and really want things like easy schema evolution.

[1] https://github.com/terminusdb/terminusdb

Succinct data structures ftw.

How about some succinct data structures and delta encoding for modern databases [1]. Succinct data structures are a family of data structures which are close in size to the information theoretic minimum representation (while still being queryable).

[1] https://github.com/terminusdb/terminusdb/blob/dev/docs/white...

There is a prolog based database that will take away many foundational problems in implementing a rules system or other logic programming artifact. It is called TerminusDB [1]

[1] https://github.com/terminusdb/terminusdb

From the google leaks paper:

'LoRA is an incredibly powerful technique we should probably be paying more attention to

LoRA works by representing model updates as low-rank factorizations, which reduces the size of the update matrices by a factor of up to several thousand. This allows model fine-tuning at a fraction of the cost and time. Being able to personalize a language model in a few hours on consumer hardware is a big deal, particularly for aspirations that involve incorporating new and diverse knowledge in near real-time. The fact that this technology exists is underexploited inside Google, even though it directly impacts some of our most ambitious projects.' [1]

[1] https://www.semianalysis.com/p/google-we-have-no-moat-and-ne...

There are already some open source alternatives to datomic. TerminusDB (https://github.com/terminusdb/terminusdb) for example is implemented in prolog (and Rust) so has the datalog variant query power that makes datomic so powerful. If you want free as in speech (thou I love free beer).

There are already a few open-source alternatives that run datalog variant query languages. I'd point the curious towards TerminusDB [1] and TypeDB [2]. TerminusDB is implemented in prolog (and rust) so an alternative with datalog in the heart.

[1] https://github.com/terminusdb/terminusdb [2] https://github.com/vaticle/typedb

This has to be imagined in the context of a post-SQL future. Unless of course you are a 'SQL is the end of history' person!

so the only way to not have your code as a learning source for co-pilot is to move all the code off GitHub? And even in that case your past/existing code would be source material?

'The open-source developer tools market is one of the worst markets one could possibly end up in... the answer is basic microeconomics. Developers love building developer tools, often for free. So while there is massive demand, the supply vastly outstrips it. This drives the number of alternatives up, and the prices down to zero.'[1]

5 years later and this still feels correct. From one OSS Dev Tool founder to another - more power & good luck!

[1] https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...

I bounce from default engine to engine (most recently startpage as a 'better' google) but so far always find myself back with google search. Last time I went elsewhere, I recorded the occasions when I appended the URL bar search with @google. Quick info on a business (address, telephone # etc.) and maps dominated. I haven't used another engine that can deliver similar. I also realized how much time I spend looking at maps and street viewer...

The knowledge graph and maps are a massive search moat.

it still has locks thou - unless you use the less powerful online version. Would be better imho to have a lock free desktop version of Excel that operates like an IDE where you merge changes and resolve conflicts at the point of merge.

There is a diff and patch API described here - the underlying database (TerminusDB) also has the concept of merging records, which could fit to your use case: https://terminusdb.com/docs/index/json-diff-and-patch

Founder of excel collaboration and versioning startup [1] here so I am a believer.

There are only about 30 million programmers. There are over 1 billion Excel users. Excel is Turing complete. Excel is by far the most used programming language on the planet. It is easily 20 times more popular than the next contender.

The value of Excel is that it is presenting the data, with a set of formulae that let you keep derived data up-to-date. This inferred data provides sums and computations, sometimes simple, but sometimes exquisitely complex. And through this whole range of complexity, with a billion users, virtually nobody treats Excel seriously like a programming language.

We have a programming language which is essentially acting as a declarative database, and yet we don't do unit tests, we don't keep track of changes, we collaborate with Excel by sending it to our colleagues in the mail and god-forbid we should doing any serious linting of what is in the thing.

Anyone who has used Excel in anger realizes why it is so brilliant. Show me another declarative constraint based, data driven inference language that I can teach to my grandmother.

The problem isn't Excel. The problem is that we are treating Excel like its a word processor, and not what it is: a programming language.

[1] https://versionxl.com/

Calling for people to be fired because they wrote a blog post with ideas you don't like is monstrous. Whatever other 'criticisms' you might have, that is beyond the pale and shouldn't be acceptable commentary on this platform.

I think so!

It isn't really saying anything - just trying to give a look at an ongoing internal dialogue about web3, which i suspect is pretty widespread. Devs often don't like permissionless blockchain and crypto, but do like decentralization and moving away from giant beasts like Apple, Google, Facebook. The Socratic method of back and forth points can help to stimulate critical thinking. Thou maybe that has failed in this case!

We had a discussion around these various approaches recently: https://github.com/terminusdb/technical-blogs/blob/main/blog...

So he's not a good enough technologist because you look down your nose at the title of his PhD? Such a strange worldview.

Gavin Wood who came up with the name web3 (as a 'decentralized online ecosystem') has a PhD in CompSci - hardly a lazy marketeer! This one is on the technologists...

TerminusDB person here: we were using the API internally for our immutable collaboration database service [1] so we thought we'd make it available for others to use. We think it is better than the one derived from the RFC and built specifically for collaboration, but you can be the judge of that! In any case - choice is good, right?

[1] https://terminusdb.com/

i was thinking the same thing, but looks like it was mostly the US government:

https://journals.plos.org/plosone/article?id=10.1371/journal...

Mostly the ability to think in abstractions and imagine what might be technically possible! Certainly not exclusive to programmers but more density there.

We have a immutable chain structure in TerminusDB which allows for straightforward uncoordinated multi-read access or multi-version concurrency control. This approach also makes branching simple to implement. Any number of new layers can point to the same former parent layer.

You might like this white paper (but for reasons above you will have to overlook some of the OWL information): https://github.com/terminusdb/terminusdb/blob/dev/docs/white...

Taking these concepts and trying to tie them back into what programmers do, so that the experience of building a knowledge graph database is not alien is essential if this is going to become mainstream tech.

We[1] started building with OWL, the web ontology language, to represent the shape of the graph. This made sense because OWL is a very rich language for describing graphs. However it also has drawbacks. It is very hard - and alien to common experience - for developers to read OWL. It was not built to describe schemata but rather ontologies (to describe what could be represented, rather than what must be represented). It also had no concept of a document, and as we were trying to build a document-oriented knowledge graph, we had to graft one onto it, which became a source of confusion for our users.

Eventually - with much pain and time - we decided to simplify the interface, make the concept of the document more central, make the primary interaction method be through json documents and create a schema language that looks like the JSON you hope to build (and feels more like one you might write in a programming language).

It is early days for the relaunched version (and we had to swallow the frustration of such a deep breaking change), but it certainly feels like regular programmers are now able to quickly build knowledge graphs. The combination of graph, schema, and document is powerful.

[1] https://github.com/terminusdb/terminusdb

No Netflix, no Disney plus, no HBO... Whatever about paying 10% more for a plastic rake, that's a bridge too far!

Few git-inspired version controlled databases out there if performance becomes an issue. Dolt & TerminusDB are the most prominent.

https://github.com/terminusdb/terminusdb https://github.com/dolthub/dolt

Interesting you said that - i read the first part, scanned the rest looking for continuation of the story and then searched for 'Sheila'. Really wonder what happened next - was there a reconciliation, did the hurt run too deep, did Sheila even remember or did she think they just drifted apart?

TerminusDB co-founder here. In 10.0 (anti-SemVer speaking), we decided to simplify the interface, make the concept of the document more central, make the primary interaction method be through JSON documents and create a schema language that looks like the JSON you hope to build (and feels more like one you might write in a programming language).

It's early days, but internally to the team, the traction has already been noticeable. Many more of us have built complex knowledge graphs using our software.

The possibilities that a document graph could bring to application development has always excited us. We really feel like their day will come. Its part of why we've been involved with implementation of graph databases since 2004.

The object store of yore always felt like a good idea to us, but we were aware of its problems: difficulties with referential integrity, difficulties with concepts of identity etc. These former attempts did not succeed but they gave us great information as to what might succeed in the future.