This gives me flashbacks to the Objective-C / Java bridge [1] from over a decade ago. It makes me wonder how they are dealing with memory management when Java objects are being used from Swift (or Swift objects from Java). This was one (of various) issues that made using the Cocoa Java bridge a bit unpleasant.
I guess Swift has a lot less run-time dynamism going on, so it may not be too hard to translate Swift semantics to Java. Definitely interested to see how this unfolds over the next year.
> It makes me wonder how they are dealing with memory management when Java objects are being used from Swift
It uses Swift macros to add a `JavaObjectHolder` property to Swift types annotated with `@JavaClass`[0]. `JavaObjectHolder` is a Swift class that takes a global JNI reference to the Java object, and releases it when the holder is destroyed[1].
The result is that a codegen utility emits Swift structs[2] that wrap the JNI values, and the JNI glue code for method invocation is applied at compile-time when the macros are expanded.
Professional Clojure dev for some time. Here is what prevents me from using Datomic.
- no Docker image; still distributed as a tarball. Although com.datomic/local exists, it only provides the Client API, so it's mostly suited towards mocking Datomic Cloud.
- Datomic Cloud is designed around AWS; applications wanting to use Datomic Cloud must also design themselves around AWS
- Datomic On-Prem does not scale the same way Datomic Cloud does (e.g. every database has an in-memory index; the transactor and *all peers* need to keep them all in-memory)
- No query planner whatsoever. In databases like XTDB, the order of :where clauses doesn't matter since the engine is able to optimize them. In Datomic, swapping two :where clauses can transform a 10ms query into a 10s query.
In addition to the above four points, I strongly believe the following points prevent others from using Datomic.
- Writing Datomic queries outside of Clojure (e.g. Java) requires writing everything in strings, which feels awful no matter what.
- If you are not using a JVM-based language, then there is no choice but the REST API for interaction. The REST API is orders of magnitude slower than the official Clojure and Java clients.
- Too many tooling exists around the pgwire protocol and various dialects of SQL. Datomic obviously does not fit into either of these categories of tooling.
- Applications like DBeaver do not support Datomic at all. The best you can do is access the datomic_kvs table from a database using JDBC storage engine.
> In databases like XTDB, the order of :where clauses doesn't matter since the engine is able to optimize them
Rich's observation was that query optimizers often get things wrong in ways that are hard to predict or control, but he's not fundamentally opposed to their use. That said, building a decent optimizer is a huge undertaking and I think they took the right decision to not attempt to bundle that sort of complexity into the original vision for Datomic otherwise they might never have shipped.
The state-of-the-art commercial engine for query optimization and execution algorithms in this 'triple' space is probably https://relational.ai/
As I see it, Rich's stance is that of an expert in the database that doesn't need to deliver business features using the database. New users are not experts and even experienced users that work for companies have pressure to deliver features. You can get initial popularity by targeting these types of expert users working on more experimental products. However long term growth and popularity requires targeting the other 99.9% of users. I've seen one company adopt Datomic due to this type of user and then a couple years latter rip it out because as it grew it's developers were no longer of this type.
The original RDBMS vision was very explicitly for the users (both developers and analysts) to not have to be experts in their own database in order to achieve useful work, and without needing to think about procedural/3GL code from the get-go. In the intervening years query optimization has gotten a lot better, and hardware shifts have only worked in favour of this vision, but there's still a lot of work to be done before databases are truly "self-driving": https://www.cs.cmu.edu/~pavlo/blog/2018/04/what-is-a-self-dr...
Until that's the case I can understand why people are tempted to bypass this traditional RDBMS wisdom, especially if they have a very strong conception about their data models, access patterns, and need for scale (e.g. see also Red Planet Labs 'Rama').
In my experience, structuring a query to execute efficiency requires some basic software-engineering thinking about what's going on, while convincing a query planner to do the right thing requires deep expertise in the query planner.
I kind of agree, I find it was never that easy to set up and use. I also found the documentation to be quite limited on specific points I wanted to know.
They showed of a JOOQ like Java API for Clojure once but as far as I can see, this was never released. That is crazy to me, using it amazingly well from Java and friends would seem to me to be an absolute no brainer. That alone made it basically impossible to be adopted. Going from SQL/JOOQ to Strings was just not gone happen.
They focused so much on Datomic Cloud, and that just isn't where most people are gone deploy. Specially in the age of Kubernetes and Docker. Its kind of crazy that there were not official Docker images and things like that.
So even while I love Datomic conceptually, and once you have it set up with Clojure its pretty awesome. I would hesitate to really use it for a larger project.
I would really love if NuBank simply open-sourced it.
>No query planner whatsoever. In databases like XTDB, the order of :where clauses doesn't matter since the engine is able to optimize them. In Datomic, swapping two :where clauses can transform a 10ms query into a 10s query.
Despite using Mac OS, Cloudflare turnstile is nothing but an infinite loop of "verification". I am using Firefox with basic privacy protections enabled. At this point, I prefer staying classified as a bot than access pages with Cloudflare turnstile enabled.
Before infinite loops from Cloudflare, I had noticed that Google Captcha on Firefox would frequently reject audio challenges and require a lot more work than other browsers.
Nitpick for the title: "go" should probably be edited to clarify it refers to the "Go programming language".
Seeing "go bot" and "Prolog" in the title made me think this article would discuss logic programming and Go (the board game). Instead, the article discusses a way to construct a sort of IRC bot.
I was about to make the same comment. We've got quite a funny amount of term overloading in the title. I was trying to remember if "ichiban" was the name of a common component of something baduk-tech related.
Ultralisp is Quicklisp but with frequently updating dists rather than monthly dist releases. Its popular is due to the fact Quicklisp, in comparison, takes lots of time for submitting and updating libraries.
CLPM is an interesting project but not used very often since projects rarely version anything in the CL ecosystem (not even branch tags anymore). Personally, I have never seen a library that suggests CLPM for installation.
Roswell is a CLI tool that manages Common Lisp installations, with Quicklisp set up automatically.
Never heard of Qlot or Docker being used.
My biggest gripe is the fact Quicklisp is widely used and no notion of version dependencies exist (not even lockfiles exist). So Common Lisp code with tons of Quicklisp dependencies tends to rot really fast. e.g. it's practically impossible today to build projects like https://github.com/akamai/cl-http2-protocol
Looks cool, but how is the Kubernetes support? One of the major reasons we use Docker Desktop at work is to host a local Kubernetes cluster with services deployed there. We also support Rancher Desktop since it uses k3s, and k3s is arguably a nicer Kubernetes distribution than the one set up by Docker Desktop.
With that said, I have recently tried OrbStack, and it is able to start up near instantly, while Kubernetes spends at most 2 seconds to start up. The UI is minimal, but it offers just enough to inspect containers, pods, services, logs, etc. It also is very lightweight on memory usage and battery. I personally cannot return to either Docker or Rancher Desktop after having tried OrbStack.
OrbStack also allows using Kubernetes service domains directly on the host. So no need to use kubectl port-forward, and applications running on the host can use identical configuration to what's inside the Kubernetes cluster.
The battery savings, dynamic memory usage, fast startup time, and QOL of OrbStack is pretty much my standard for a Docker Desktop alternative. I am not sure if container-desktop satisfies all of these requirements. (Rancher Desktop certainly doesn't)
I'm a fan of k3s. Mostly because Rancher Desktop, but there are more useful features, like a full k3s distribution within a single docker container. It includes some nice QoL features, like pre-loading images from a mounted folder. Great for CI.
k0s is especially easy to deploy thanks to k0sctl, whether it's single node clusters, or multi node clusters. I haven't looked back ever since I started using it.
I mostly wanted to provide a software/hardware playground for my advisors who were working on their own thesis about algorithms for energy-aware IoT edge deployments.
The TLDR is that you can write algorithms to minimize various parameters within a Kubernetes cluster, like energy consumption.
I think the person is concerned with client-side compute, not just server-side compute. The article does not mention whether zstd has additional decompression overhead compared to zlib.
Client-side compute may sound like a contrived issue, but Discord runs on a wide variety of devices. Many of these devices are not necessarily the latest flagship smartphones, or a computer with a recent CPU.
I am going to guess that zstd decompression is roughly as expensive as zlib, since (de)compression time was a motivating factor in the development of zstd. Also the reason to prefer zstd over xz, despite the latter providing better compression efficiency.
though I always thought lz4 to be the sweet spot for anything requiring speed, somewhat less compression ratio in exchange for very fast compression and decompression
Anecdotally, many American universities and academic journal sites still use Shibboleth. Thus, in the United States, SAML is far from dead, whether we like it or not.
I guess Swift has a lot less run-time dynamism going on, so it may not be too hard to translate Swift semantics to Java. Definitely interested to see how this unfolds over the next year.
[1] https://developer.apple.com/library/archive/documentation/Co...
reply