osalberger

The consistency guarentee assuming repeatable read or higher on each shard is parallel snapshot isolation, which is technically still higher than postgres read committed.

If you have serializable on each shard and you chop transactions so you have no cross shard transactions, the application is technically still serializable, it just behaves like two independent deployments of the application for different shards

The idea here is that many programmers would call it rateLimit, if they use CamelCase naming. If they don't, at least they can just switch to camelcase once they realize the issue, while that is not an option for single noun names

Breaks causal consistency and a bunch of other assumptions:

https://jepsen.io/analyses/mongodb-4.2.6

However, the skills library that it writes with live feedback from runtime errors and that it retrieves with a vector DB is really interesting. In that sense it looks like a very interesting code generation application.

Just checked by talking to the free version of ChatGPT, and yes, the MineFlayer api docs are indeed in its training set. It can give me detailed instructions on how to build a minecraft bot. And of course, it also knows the entire minecraft tech tree very well.

So this isn't really open ended work, its just making it do something it is already trained on, by connecting it to an API that it has learned the docs of.

Julia's JIT is a just ahead of time method jit just like SBCL, and the language is designed around making idiomatic code as fast as possible with that approach.

So every function is a multimethod that gets compiled the first time any combination of types is first encountered, and at that point the type information is propagated to all function calls inside the method body, to eliminate dynamic dispatch on those & possibly inline the appropriate method. Julia has parametric polymorphism as well, so it's common for all types in the body to be inferable.

As a result, Julia code tends to make much more heavy use of polymorphism & multimethods than common lisp (where CLOS has a significant runtime cost instead of being a near-zero cost abstraction), since the language and the runtime were designed carefully together to make that fast.

Datalog isn't especially difficult to learn though, and is intuitive enough that you can fully learn it in 20 minutes.

The relational model with unions of conjunctive queries at its core is excellent. SQL on the other hand feels like some weird COBOL dialect that gives you an incredibly verbose implementation of it.

With that said, there are a few enterprisey NoSQL databases which are relational yet provide a nicer language to work with than SQL. I mentioned datomic (which also has persistence as its key feature), but there's also TypeDB which lets you use the first class support for recursive queries to support inheritance more easily. And of course there's google's Logica language which compiles to SQL and lets you use datalog syntax and the ability to write reusable queries, though it doesn't support recursion due to the nature of its target.

Right, compilation time went down a lot with 1.6 by avoiding method invalidations during compilation. The other thing they did is ensure that the package manager properly compiles all dependencies in topologically sorted order when you install a package, instead of doing a lazy compile on package load where it would often waste time recompiling the same method.

The thing is that SQL was originally built to be an easy accessible DSL for simple database queries, and was not intended to be used to build highly complex stuff. Datalog-like query languages would do the latter much better since they are actually capable of letting you write reusable predicates and libraries for common usecases, while SQL easily grows into a monolithic monster.

Sadly a lot of the "NoSQL" hype later on was led by people who had no clue about database theory, and proceeded to throw the baby out with the bathwater and build whatever abomination MongoDB is, rather than taking SQL's theoretical basis and building a language on top of it that is actually designed for complex usecases. There were only a few exceptions like say Datomic in Clojure world that did NoSQL right.

Right. Julia is looking fairly promising as a "real" programming language that is still an excellent Matlab replacement, and possibly to a lesser extent an R replacement, and it does show that there is nothing about filling the exploratory math programming niche that requires it to have the warts that the incumbents have.

Fundamentally, R and Matlab are probably best comparable to Perl in terms of how they got popular. While they are rather ugly, they were the first to provide a simple solution to a few specific problems that a lot of people had, which snowballed them into popularity and network effect advantages