That's AI getting an example of replicating the state that shows the bug which is exactly what I'm talking about. It does that far more than humans do, and it's ace. That's how you should be debugging a system - replicate the issue, understand why it breaks in that given state, and then make a code change to fix it.
Sometimes you can do that mentally and fix the code. Often your fix will be right especially in a relatively simple part of the code. However, equally often you'll fix a different problem (or something that wasn't a problem at all), and the original bug will remain but you'll believe you corrected the issue. This is why you should always replicate a bug to understand it, and why you should always add a test whenever you fix a bug to prove you actually fixed it as well as preventing future regressions.
Your site has a bunch of marketing copy, trademark symbols, and a link to pay you $2k/mo, but zero technical detail and is broken on mobile. It gives vibe coded.
The benchmark of 2m black-scholes evals/sec is meaningless without additional context. Also seems a couple orders of magnitude slower than what I’d expect even for a single core. What exact transformations are being done, and what’s the throughput in GB/sec? Is it multi threaded? Benchmark against the equivalent query in kdb+ and ClickHouse?
What additional technical detail would you be interested in?
> Also seems a couple orders of magnitude slower than what I’d expect even for a single core.
1) it's more than 2m/s on a MacBook AIR
2) Most of the latency is networking. This was a preliminary setup with a client / server over websockets where the book of 1m contracts combination of (strike, exp_date). Each insert only after a corresponding query has been returned (over the wire) from the previous insert. I can agree the eval isn't great; as in, the throughput is much higher.
The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.
ORMs do not inherently build queries. They only provide data transformations between relations (i.e. rows and columns) and objects. Hence the literal name: Object relation mapping. You can absolutely have ORM without query building just as much as you can have query building without ORM.
Sometimes ORMs and query builders are combined into a higher order system, such as what is described by the active record pattern. This might be what you are actually thinking of instead?
User {
name
friends: List<Friend>
posts: List<Post>
}
Let's say we have a "MappedUser" which is derived from this type by this ORM.
I now do:
user = get_mapped_user()
for post in user.friends[0].friends[0].posts {
...
}
Ignoring "get_mapped_user()" how does our user object work?
What happens when I access `.friends`?
Does it give me an empty list, because I didn't ask for it?
I am not aware of anything that calls itself an ORM which merely does:
user: User = map_from_relational_to_user(query_user())
Not only is it difficult to conceptualise how this operation would ever meaningfully work for any non-trivial query, it's also difficult to see how it would even work for trivial queries.
ORMs, at their core, try to abstract away something like `user.friends[0].friends[0].posts` more or less into some underlying queries against a relational database. The main distinction between them being in the availability and first-class nature of the escape hatches when this operation inevitably becomes slow.
> Does it give me an empty list, because I didn't ask for it?
That depends on the rest of your code. If you are using something like the active record or data mapper pattern then it would reach out and fetch more results. If you don't have such mechanics in place then an empty list is possible. We don't have enough information here to say what happens.
> I am not aware of anything that calls itself an ORM which merely does
When your code merely does that, what do you call it?
> ORMs, at their core, try to abstract away something like `user.friends[0].friends[0].posts` more or less into some underlying queries against a relational database.
Active record/data mapper tries to abstract that. ORMs are a necessary piece of active record/data mapper, but one part of a larger system. You also need things like a query builder. ORM alone is not sufficient for these patterns.
> into some underlying queries against a relational database.
Unlikely. SQL is mentioned in the headline for a reason. Nobody uses relational databases in the real world. The only remaining relational database engines that are still maintained really only exist for educational purposes. I understand why you might think a relational database is necessary given that ORM stands for Object Relational Mapping, but as ORM operates on data, not databases, the data can be relational even if the backing database isn't. It simply becomes another mapping step to see them become compatible.
No, I am asking about your hypothetical "bare bones" "ORM" which explicitly _doens't_ have anything beyond "object mapping".
> When your code merely does that, what do you call it?
Certainly not _object_ mapping. It's something between regular "data mapping" and "completely worthless." If the thing you get out of it is not something representing an object from your object model.
> ORM alone is not sufficient for these patterns.
You are talking about a definition of ORM which is at odds with any definition of ORM that I am personally aware of.
Classical ORMs focus almost entirely on providing proxy objects which represent your object model and which back accesses with additional queries.
> Unlikely. SQL is mentioned in the headline for a reason. Nobody uses relational databases in the real world.
SQL is a query language for relational databases. Unless you have another definition for "SQL" or "relational database" which is at odds with common parlance.
> I understand why you might think a relational database is necessary given that ORM stands for Object Relational Mapping, but as ORM operates on data, not databases, the data can be relational even if the backing database isn't. It simply becomes another mapping step to see them become compatible.
While certainly an ORM maps between an object model and a relational model, the fact that this could be done with something other than a relational database seems completely irrelevant to anything in this discussion.
You seem to be taking the term "Object Relational Mapping" splitting it into its constituent parts, looking at the definitions of those terms, and then assuming that the definition for the whole term is just a simple combination of the individual terms.
This is akin to me claiming that OOP doesn't require a programming language or computers, and can merely involve me buying or otherwise procuring a bunch of things (objects) and then setting them up (programming) in the form of a Rube Goldberg machine in order to perform calculations.
My earlier statements regarding the example code existed to point out that the mere act of taking some relational data and somehow converting it to objects in your object model is not "mapping" in any meaningful sense because the resulting objects would be incomplete, and in some cases would not even be able to be constructed from arbitrary relational data.
The mere act of instantiating a partial object graph from relational data is _not_ "ORM", in the same sense that writing and calling functions is not functional programming.
> I am asking about your hypothetical "bare bones" "ORM"
What does "bare bones ORM" mean? That seems like saying "bare bones sort", but like sort it seems to me like it is either something that happens or something that doesn't happen. You either map objects and relations or you don't. Are you imagining that there is some way to partially map relations and objects but somehow not go all the way? I admittedly cannot picture what that would look like. What would the purpose be?
> SQL is a query language for relational databases.
No. SQL is not for relational databases. This is most obviously observed by the fact that SQL is centred around tables instead of relations. That naming isn't just a marketing gimmick. Tables are technically different from relations. Codd, inventor of the relational model, spent a lot of time writing about why SQL isn't relational if you want a more in-depth technical explanation, but suffice to say that ORMs and SQL are not directly compatible. Although obviously they can work together if you layer in additional functionality. You can make any data shape work with another if you provide some kind of mapping between them.
> Are you imagining that there is some way to partially map relations and objects but somehow not go all the way? I admittedly cannot picture what that would look like. What would the purpose be?
I am asking _you_ what _you_ are trying to claim here.
If you have a class such as:
@dataclass(frozen=True)
class User
name: str
friends: set[User]
I am trying to figure out how your described model maps it from partial information such as:
"user" (user_name) subset:
("Fred")
("Jeff")
("Bob")
"friend" (user_name, friend_name) subset:
("Fred", "Jeff")
("Fred", "Bob")
Because to "map" this to the object model, your relational mapper would presumably need to do this:
fred = User("Fred", { User("Jeff", set()), User("Bob", set()) })
But from the above partial information, you don't know if Jeff or Bob have friends.
This breaks down further when you add more to the users tuple set, e.g. let's add a required "surname" field.
Unlike with the empty "friends" set case, there's _nothing_ you can put in the names which is correct unless you force those fields to be nullable. This is basically unmappable.
I am asking how _your_ idea of an ORM which doesn't handle querying (or if you want to use relational terminology, evaluating relational algebra expressions) works. Presumably you will claim that it will only map data which is mappable, which is wonderfully useless. But then you're just describing the concept of mapping, and not "an ORM" which is a tool which handles this concept for you.
> No. SQL is not for relational databases. This is most obviously observed by the fact that SQL is centred around tables instead of relations.
This is a weird argument. Relational data doesn't centre around relations, it centres around sets of tuples, the relations are an external concept which makes interpreting the dataset useful.
> Codd, inventor of the relational model, spent a lot of time writing about why SQL isn't relational if you want a more in-depth technical explanation
E. F. Codd complained that SQL databases aren't a faithful representation of the relational model, and that's accurate. His complaints were with the following (cited verbatim):
"
* Flaw No. 1: it permits duplicate rows in relations;
* Flaw No. 2: it supports an inadequately defined kind of nesting of a query within a query;
* Flaw No. 3: it does not adequately support three-valued logic, let alone four.
"
Regardless, their use of "tables" has nothing to do with whether they're relational or not. Codd's complaints are to do with the fact SQL databases use bags instead of sets, that SQL doesn't perfectly represent certain relational semantics because the language was rushed and half-assed, and that they handle MAYBE (NULL) half-assedly and lack support for "inapplicable" values.
The thing to note here is that these flaws, if fixed, would have no impact on the OR impedance mismatch, or the ORM problem.
> but suffice to say that ORMs and SQL are not directly compatible.
You are making an appeal to definition here, specifically the definition of the words "Object", "Relational", and "Mapper". "ORM" is itself a marketing term which was coined at some point in the 90s. This was to describe an approach people were taking to trying to map objects in languages such as C++ to _tables_ in "relational databases" of the time.
The relational databases which were being mapped had tables because that's what the papers of the time[^1] talk about.
The earliest paper I can find that talks about "mapping" describes it in terms of query generation and proxy objects[^2]. Although it does describe a "Light Object Mapping" approach which distinctly doesn't model relationships or use query generation, and uses "basic objects" (which do not actually represent an object model, and are instead just data transfer objects (DTOs)). But what "Light Object Mapping" means here is specifically: "just write your own SQL and map it to DTOs by ahnd" rather than describing any automated approach for the problem, which is precisely how it's the only option that gets away with not having a query generator.
It's kind of funny seeing how far back the "impedance mismatch is imaginary" mindset reaches, because it's present in this paper too. A paper which then goes on to explain the significant complexity of this problem and brushes over many of the even harder parts.
> I am asking _you_ what _you_ are trying to claim here.
I claim nothing about "bare bones", so, again, you must clarify what you mean by it before I can do anything with it.
> I am trying to figure out how your described model maps it from partial information...
That's up to the implementation to figure out. ORM isn't a specific algorithm. Is that the source of your confusion?
> it centres around sets of tuples
Whereas SQL does not. You can, of course, map SQL structures onto relations, which may be why you see SQL as being relational, but that's true of any database. You can take a document database and map it to sets of tuples too. Calling a document database a relational database because it can be mapped to sets of tuples is a stretch, however. Relational databases are natively relational, not just able to represent relations.
Look, it's pretty clear to me that you're either not reading half of what I write, or choosing to ignore it. I am not particularly interested in speaking to a wall.
> I claim nothing about "bare bones", so, again, you must clarify what you mean by it before I can do anything with it.
I shouldn't need to spell this out, but I am not insinuating anything negative or positive about your approach by calling the description you gave initially as "bare bones". I am simply using "bare bones" as a shorthand to refer to your definition of ORM.
You are claiming that implementing an ORM doesn't require query building, I am claiming that it does. I am calling your proposed ORM that doesn't require query building "bare bones", just as a shorthand to avoid saying "ORM that doesn't do any query building". I hope this makes things clear for you.
> That's up to the implementation to figure out. ORM isn't a specific algorithm. Is that the source of your confusion?
We are talking about _an_ ORM. As I clearly stated in my original comment, and as is being described in TFA. _An_ ORM is a tool which presents a "relational" database's (e.g. PostgreSQL, SQLite, MariaDB, ...) contents as an object graph. With the _external_ relationships (as in the relational model) modelled as _internal_ relationships (as in object graphs).
I am not talking about abstract "object <-> relational mapping" in a vacuum, I am talking about the specific thing that people mean when in 2026 they say "I am using an ORM".
> Whereas SQL does not.
SQL centres around bags of tuples, so you are indeed right that it's not quite truly relational, as was Codd, as I acknowledged. But that doesn't make any impact on what people mean when they say "ORM" in modern day programming parlance. So please stop appealing to an irrelevant definition.
> Relational databases are natively relational, not just able to represent relations.
What do you think this even means? The fact that SQL has bags of tuples just means that if you want it to follow a relational model, you must merely ensure that you enforce these bags to be sets. At this point the remaining complaints by Codd don't have an impact on the fact that, insofar as you don't hit those specific niche limitations, you are faithfully representing a relational model at least in your data.
Relationships in the relational model are not internal, they are external. This is one of the reasons for the OR mismatch. It's counterintuitive that object graphs represent relations internally, and relational models do so externally, at least when phrased like that, but it's inherently true.
The fact that graphs represent relationships also doesn't make graph databases or object databases relational. I would have assumed this was clear from what I wrote so far, but as I already established, I suspect you're not actually reading half of what I am writing, so it maybe isn't so surprising that you think I am ignorant of these things.
If I only read select paragraphs of what Codd wrote, I might also think that he was ignorant of his own model, but instead I kept reading what he wrote until I was confident in my understanding of it. I suggest you do the same if you wish to have a productive conversation on any topic online.
Autocomplete is making me lazy. If I don't see what I'm about to type within two or three characters, I feel like the IDE isn't doing its job of helping me. So being able to type `db.Cust` and autocomplete Customers is really nice. I do know SQL, but yes, the language servers usually have a harder time connecting the SQL to my backend code, whatever language it's in, without quite a lot of config fiddling that pretty much obviates any time savings I would have gained from autocomplete.
In my database[0] you get an SDK generated from your schema. Typescript is the default and man, the autocomplete works so well.
I recently added support for SDK generation in Rust and Go, just do `disc codegen —rust` (double dash, my iPad is autocompleting the wrong dash) and you’re good to go.
I'm firmly on the ORM side of things, despite knowing SQL very well -- but your IDE/editor can fix this with bare sql. Try using Jetbrains Datagrip or the DB integration in Idea or one of the other language-specific IDEs.
It's not that different. I'd rather have a different way to do UPSERTs or a different window function here and there [1] than figure out every ORM's join syntax or its sneaky ways to SELECT N+1 me into oblivion.
I mean the easiest explanation would be that the model harness doesn't always take the most likely token but does top-k sampling or similar. temperatur just means that probabilities get more and more equalized, boosting the chance that an unlikely token gets picked. but even with temp 0 you could have 0.8 T1, 0.19 T2, ... and sometimes sample T2
No, this can't happen at temperature 0. The formula defining temperature-adjusted softmax isn't strictly defined at 0, but taking the limit (in the case where all logits are distinct) results in probability 1 being placed on the largest logit. Samplers will typically special case temperature 0 and pick the most likely token at each step.
This is a very authoritative answer that should be more nuanced and caveated as implementation-dependent. In some cases, repetition penalties take precedence over sampling; top_k and top_p can also be handled before or after the temperature step. In other cases, `0` is turned into like 1e-10 or some super tiny float value (which can drift if you do any arithmetic with it). Routing, quantization, etc. can also have an effect on sampling. And yes, in some cases, setting temperature to 0 can mean "pure greedy decoding" which makes the decoder about as deterministic as it can get.
> One of the great drawbacks of "Cloud Native Computing" as it now exists is that it's really, really complicated. It is often more complicated than the old, non-cloud, sort of computing. In order to deploy your app outside of Minerva you now need to know something about k8s, or Cloud Formation, or Terraform.
Highly agree with this. I think it's very underappreciated in startups that if you want people to deploy a lot of small services you have to make that really super easy. I always thought that the value of things like Spark is that you can run "things" without having to worry about how they run. K8s is similar but much more complex. AWS Lambda is nice but also comes with a lot of baggage at scale. I always wanted to try something like Dapr, which seems to provide a very opinionated happy path for application development.
OP wanted to set up a nested copmany structure. Instead of Person -> LLC it goes Person -> Limited Partnership --> LLC. The in between company is only for tax-efficiency and has nothing to do with limited liability.
The question is, is that really only due to data center geo? I am always amazed how low latency and high quality Facetime between Europe <-> Australia is. Seems like good engineering can overcome less optimal geographics.
I find that hard to believe. Are you implying that Apple is running their own fiber network providing low-latency connection between Europe and Australia? Or what kind of "good engineering"?
I can vouch for GP's exact experience. Facetime does feel much smoother than other videocalling apps for Aus<>Europe. Of course they don't run their own fiber network. The good engineering is making it feel smooth and good despite that. At its core, nothing about computing is smooth. Everything is based on making it feel that way, using countless techniques.
What "techniques"? Audio/video over high-latency connection is not a computer game where there all all kinds of latency compensation techniques - several meeting participants start speaking at the same time, realize they do only after RTT, stop, then awkwardly wait for a moment and repeat hoping for no "collision", rinse-repeat. Everyone who often has meetings with participants connecting from different continents knows what I'm talking about. But you can have this in beautiful high-definition "smooth" 4K if bandwidth is high enough, yes.
the reply here is .. any software can really perform badly.. it takes some effort to not perform badly. the default gravity is to be buggy and bad performance. The parent-post is right there are hundreds of small parts and they all have to do well to accomplish "live video and audio across half the globe"
If this works `git clone me@github.com:me/mine.git release_01 && ln -s release_01 /var/www/me/mine/current` then your Docker builds should also be extremely quick. Where I have seen extremely slow docker builds is with Python services using ML libraries. But those I reallly don't want to be building on the production servers.
"ECS would have worked for 99% of these apps, if they even needed that."
I used to agree with that but is EKS really that much more complicated? Yes you pay for the k8s control plane but you gain tooling that is imho much easier to work with than IaC.
