I'm tickled you asked ChatGPT but I think it misses the the forest for the trees somewhat.
1. Architecture - XTDB is designed to work with Kafka, but it also works with typical JDBC databases as a datastore. Datomic can use SQL databases, DynamoDB or Cassandra if you want distribution. I personally would think long and hard before I introduced a distributed database to my organisation "because it scales".
Part of the value proposition of Datomic is it easily scales read workloads horizontally and by isolating read and writes into separate processes it improves write performance significantly. The metric usually thrown around is 75% of CPU cycles in a traditional RDBMS are concurrency coordination, which is avoided by the Datomic model. That number is quite old now so I don't know if it's still accurate as of 2023.
2. Query language - both use Datalog and support the Datomic `pull` syntax. XTDB also supports SQL.
3. Datomic's EAVT quadruplets are a compelling feature because they are so generic and can be used/re-used in many contexts. A document database would have to fit your use case pretty directly.
4. Datomic has a single transactor process. Do you need distributed transactions? Does Datomic need distributed transactions? You'd have to find someone from say, Nubank, and ask them for war stories. :-)
5. Datomic is now free-as-in-beer.
In my unqualified opinion XTDB is appropriate to choose in the following situations:
- You need to model "valid time" as part of your domain.
- Do you want a document database and are happy with everything that entails?
- You need access to the source code of your database.
- Do you have existing analysts who know SQL but don't know or can't learn Datalog?
The following quote was written in 1930, in the New York Times:
"Some day no one will have to work more than two days a week... The human being can consume so much and no more. When we reach the point when the world produces all the goods that it needs in two days, as it inevitably will, we must curtail our production of goods and turn our attention to the great problem of what to do with our new leisure."
Given the advances in productivity over the last century, why do I have to work 5 days a week?
That's an interesting take. What makes you think diversity played a major role? Does this happen often in your country? Where I am "diversity" hiring would be regarded as dysfunctional at best.
To each their own! I feel the same way about Algol family languages, too many arbitrary design decisions that have been internalised for decades at this point for my liking.
I have no intention of being snarky and I'd like to engage in good faith, but I'm aware of how this will read:
How is it a useful metaphor? I don't understand how you can use it to extrapolate from a situation in which you vastly outmatch an opponent to one of equals or you being outmatched. It seems too general and abstract to be worth more than "that's neat" status.
Other HN responders seem to be using it to mean a variety of different concepts including tempo, having superior heuristics built via prior observation or simply "thinking then acting".
I may be mistaken but I think Electric Clojure renders HTMX unnecessary. Where HTMX still works by a developer specifying the network calls (albeit in a declarative manner), Electric Clojure hands over the same responsibility to the compiler.
As a security guy I would say this situation happens with reasonable frequency in REST web frameworks where developers are encouraged to use ORMs[0], and the design of Hyperfiddle/Electric is no more likely to fall victim to it.
I'd actually take a punt that it's less likely because of Clojure's data-orientation. Given that the above mentioned ORM-preferring frameworks typically have to define a whole new class and map the data from a server-side representation to a client-side representation, you're more likely to see developers not bother, forget or bungle the implementation aspect.
What I'm interested in is how Electric Clojure handles mass assignment (unconstrained deserialization)[1], sort of the flip side of excessive data exposure. If an (e/server) s-exp uses the symbol `is-admin?` will the server respect or discard values for `is-admin?` sent from the client?
* Predictability and convention are more important than totally clean design. Over the course of a language lifetime, code style best practice is going to change so you almost certainly won't have uniform interfaces. Your Clojure example of functions passing the input as first vs last is actually an example of this -- functions that work on sequences expect the last arg, and functions that work on datastructures expect the first arg. It's an official convention, check out different uses of the -> and ->> macros and you'll always see it.
* Some form of discoverability. Ideally there'd be good docs available explaining the behaviour of the library in human friendly language, with multiple code examples. Bonus points for making the library open source and linking directly to the implementation from documentation.
* No breaking changes. It's better to create a new library than try and shoehorn a significantly different release into semantic versioning for the sake of it.
* "Escape hatches" for effectful functions to override default behaviour. For example, a HTTP client library isn't going to be very useful if you can't override pretty much any configuration property.
* Being explicit about any side effects resulting from the code, either in naming or by documentation.
My recommendation is to use Portacle as your IDE and run through Practical Common Lisp by Peter Seibel over the course of a few days. Both are available for free online and very easy to get set up with. Practical Common Lisp provides a good foundation level of knowledge, which you can continue to use as a frame of reference for the other Lisp dialects and features as they come up (e.g., Lisp-1 vs Lisp-2, hygienic vs unhygienic macros). Once you have the fundamentals of Common Lisp down, I'd say you can then follow your interest and choose an appropriate Lisp dialect for the type of project you want to create.
1. Architecture - XTDB is designed to work with Kafka, but it also works with typical JDBC databases as a datastore. Datomic can use SQL databases, DynamoDB or Cassandra if you want distribution. I personally would think long and hard before I introduced a distributed database to my organisation "because it scales".
Part of the value proposition of Datomic is it easily scales read workloads horizontally and by isolating read and writes into separate processes it improves write performance significantly. The metric usually thrown around is 75% of CPU cycles in a traditional RDBMS are concurrency coordination, which is avoided by the Datomic model. That number is quite old now so I don't know if it's still accurate as of 2023.
2. Query language - both use Datalog and support the Datomic `pull` syntax. XTDB also supports SQL.
3. Datomic's EAVT quadruplets are a compelling feature because they are so generic and can be used/re-used in many contexts. A document database would have to fit your use case pretty directly.
4. Datomic has a single transactor process. Do you need distributed transactions? Does Datomic need distributed transactions? You'd have to find someone from say, Nubank, and ask them for war stories. :-)
5. Datomic is now free-as-in-beer.
In my unqualified opinion XTDB is appropriate to choose in the following situations:
- You need to model "valid time" as part of your domain.
- Do you want a document database and are happy with everything that entails?
- You need access to the source code of your database.
- Do you have existing analysts who know SQL but don't know or can't learn Datalog?