augustl

A few milliseconds per query adds up if you're doing one query per item in a list with 100s or 1000s of elements :)

Indeed, it depends a lot on the domain. Datomic only has "technical" database time, and doesn't have any built-in way of modelling domain time. You can set the transaction timestamp manually when you write, but you can't set it to be earlier than the latest transaction that was committed. So, if you want your domain modelling to piggyback on Datomic time travelling, you can only do things like delaying writes for, say, an hour, and hope you have all the data by the time you commit to db.

Datomic already sort of does this :) You configure a storage backend (Datomic does not write to disk directly) which can be dynamodb, riak, or any JDBC database including postgres. You won't get readable data in PG though, as Datomic stores opaque compressed chunks in a key/value structure. The chunks are adressable via the small handful of built-in indexes that Datomic provides for querying, and the indexes are covering, i.e. data is duplicated for each index.

Because of the reasons I list :) Anything in particular that wasn't clear/relevant?

The main difference between event sourcing and datomic are the indexes and the "schema", which provides full SQL-like relational query powers out of the box, as well as point-in-time snapshots for every "event" (transactions of facts).

So, "events" in Datomic are structured and Datomic uses them to give you query powers, they're not opaque blobs of data.

I agree, I mostly phrased it that way for effect. My "analysis" is 100% subjective, opinionated and anecdotal :)

Good question! I don't have any personal experience in that regard. I would probably have paid up for enterprise support (or bought the entire company ;))

It's definitely a trade-off! If you have 10s or 100s of app servers that has the exact same working set in memory, it's probably not worth it.

But if you have a handful of app servers, it's much more reasonable. The relatively low scale back-office systems I tend to work with typically has 2, max 3. Also, spinning up an extra instance that does some data crunching does not affect the performance of the app servers, as they don't have to coordinate.

There's also the performance and practicality benefits you get from not having to do round-trips in order to query. You can now actually do 100 queries in a loop, instead of having to formulate everything as a single query.

And if you have many different apps that operates on the same DB, it becomes a benefit as well. The app server will only have the _actual_ working set it queries on in memory, not the sum of the working set across all of the app servers.

If this becomes a problem, you can always architecture your way around it as well, by having two beefy API app servers that your 10s or 100s of other app servers talks to.

Datomic's is perfect for probably 90% of small-ish backoffice systems that never has to be web scale (i.e. most of what I do at work).

Writing in a single thread removes a whole host of problems in understanding (and implementing) how data changes over time. (And a busy MVCC sql db spends 75% of its time doing coordination, not actual writes, so a single thread applying a queue of transactions in sequence can be faster than your gut feeling might tell you.)

Transactions as first-class entities of the system means you can easily add meta-data for every change in the system that explains who and why the change happened, so you'll never again have to wonder "hmm, why does that column have that value, and how did it happen". Once you get used to this, doing UPDATE in SQL feels pretty weird, as the default mode of operation of your _business data_ is to delete data, with no trace of who and why!

Having the value of the entire database at a point in time available to your business logic as a (lazy) immutable value you can run queries on opens up completely new ways of writing code, and lets your database follow "functional core, imperative shell". Someone needs to have the working set of your database in memory, why shouldn't it be your app server and business logic?

Looking forward to see what this does for the adoption of Datomic!

Maybe we'll finally get a music app where classical music isn't categorized by Album/Artist :)

Classical doesn't really fit that well into a schema, since you have composers, performers, and then under performers there's soloist, or multiple soloists, which orchestra, which conductor, and so on.

And it would also be nice to have things like "show most popular recordings of Beethoven's 5th".

What is the better http client? I thought most HTTP clients piggybacked on libcurl :)

It works on iOS, you just have to add the proxy manually via settings.

You have to distribute it yourself, there's no automatic distribution on Signal's part.

Thanks for the detailed explanation! You folks have actually tried to implement an ABI compatible Linux kernel, so I'll definitely take your word for it :)

It's a shame they essentially deprecated WSL1 and is doing everything in WSL2 now, where exactly this kind of memory allocation and the performance issues that entails is an issue.

Not that I think it's a bad decision, but I wish they somehow managed to break Conway's Law and enhance Windows itself by fixing the file system speed issues as well as somehow making NT/Windows processes fork instantaneously just like on Linux :)

Ah, thanks, that's useful! I didn't know the iPhone 8 was such a large jump in hardware specs.

Apparently, the reason Apple dropped support for iPhone 7 is performance on the new lock screen. Pretty lame if that's the case, Apple has usually been good with supporting all devices as long as the hardware allows it (for example, hardware level secure enclave was required at a certain version of iOS)

Thanks for the real-world numbers! This is good for my emotional state, as I've switched from Windows to a MB Pro solely because of the battery life and performance of the M1 Pro chip.

How is 12th gen compared to 10th gen, in your experience? My XPS 13 on a 10th gen i7 just becomes absolute syrup on battery, even if I put it in high performance mode.

This is why I don't understand why Datomic isn't more popular. Pretty much every system I've worked on never needed to scale past 100s of writes per second due to hard limits on the system (internal backoffice stuff, fundamenally scoped/shardable to defined regions, etc etc). And since Datomic is built with that in mind, you get the trade-off of full history, first class transactions and being able to query for things like "who changes this attribute to its current value, when, and why" is such as super power!

The current rumor is that Apple is open to Microsoft doing it, and that Microsoft has an exclusive license with Qualcomm for ARM windows. This license expires soon.

> "that's really up to Microsoft," [Craig Federighi] said. "We have the core technologies for them to do that, to run their ARM version of Windows, which in turn of course supports x86 user mode applications. But that's a decision Microsoft has to make, to bring to license that technology for users to run on these Macs. But the Macs are certainly very capable of it."

From: https://arstechnica.com/gadgets/2020/11/we-are-giddy-intervi...

Exclusivity deal rumor: https://www.xda-developers.com/qualcomm-exclusivity-deal-mic...

You're definitely an early adopter if you're on WSL now. I'd say it's probably not prime time until 2024 or so.

Hmm, that's interesting. I suppose more cloud providers could do something like that, for the benefit of customers and GDPR?

E.g. Amazon already bills me through some Norwegian entity of some kind, to get VAT done right etc.

If they had servers in Norway, I suppose it would have been possible to proxy everything - not just billing - in AWS Norway through this sub operator?

I'd love to read more about this, in all aspects of astrophysics!

It's not that I doubt that astrophysicists take this into account, I'm sure they do! But when we see an "image of a black hole", that's really a gazillion data points from a multitude of different observatories, processed by human made algorithms with human made models and biases, and it happens to look just like we expected - how do we know it's not just our assumptions that made it into the processing and modelling?

Again, I'm sure every astrophysicist ever has thought about this and knows how it's handled, so it's not a criticism. I'd just love to read more about it, as a layperson :)

These sorts of images always makes me wonder about how many of the images of the universe we see, are how they look from our perspective, vs how they look from "above" etc.

I suppose this one is from our perspective?

How we know that the arms of the milky way are bent when viewed "from above"? Imagine if they were straight lines when viewed from above. From our perspective, they would appear to be spiraling arms, since the light at the far end of the arm would take longer to reach us.

I'm not doubting astrophysics here, I'm just a layperson that wonders how these things are properly taken into account.

For me, the takeaway is pretty deep:

Other peoples world views are valid.

It's so easy and so human to criticize other people's views, filtered through my own world view. But then I'm really only criticizing own interpretation of their view.

For me, this is a lesson that almost can't be repeated enough, because I tend to slip into forgetting about it.

But good for you if you find it obvious and banal :)

Note that this is just a new syntax for the existing querying capabilities. If you query something that's not in the hash/sort key, you still need to filter on the "client" after the 1mb data set size limit etc.

I have no direct experience with scaling DynamoDB in production, so take this with a grain of salt. But it seems to me that the on-demand scaling mode in DynamoDB has gotten _really_ good the last couple of years.

For example, you used to have to manually set RCU/WCU to a high number when you expected a spike in traffic, since the ramp-up for on-demand scaling was pretty slow (could take up to 30 minutes). But these days, on-demand can handle spikes from 10s of requests a minute to 100s/1000s per second gracefully.

The downside of on-demand is the pricing - it's more expensive if you have continuous load. But it can easily become _much_ cheaper if you have naturally spiky load patterns.

Example: https://aws.amazon.com/blogs/database/running-spiky-workload...

He said this on Twitter, and I believe Coinbase employees are allowed to say whatever they want on Twitter?

> no direct reads of another team’s data store

This reminds me of how App Store used to ban game emulators interpreting ROMs downloaded from the internet, while at the same time allowing XML parsing.

Does it really matter if the interface you're talking to over the network is code written by another team, or data written by another team? I suppose implementation details are often hidden away in data stores, but does it have to be that way?