In practice I think a lot of engineers would do this. My recommendation would be to avoid this at all costs. In my opinion, the way to scale a codebase with AI is to have some part of the codebase that is reserved only for human hands. You need to be able to look at something written, and to know that it expresses human intent. Once you deviate from that constraint, then you might be even worse off than before, because now you have 2 sets of generated source code to sift through, not 1.
While excessive screen time can certainly be a problem and the specific content matters there is nothing inherently wrong with a small amount of age-appropriate YouTube content consumption.
Also, in my experience, LLMs seem to love to say something went "dark" or "silent", to mention a "generation" of people, and to say something "matters". "no corporate filter" also seems like a strange thing to say.
Em-dashes were in common use long before LLMs existed — anyone saying that’s a sign of LLM use should not be listened to. They’re used by LLMs because they were trained on good writing and we shouldn’t avoid using them any more than we should stop using correct punctuation for the same reason.
> anyone saying that’s a sign of LLM use should not be listened to
You don't need to believe me. You can read the studies about its statistically higher occurrence in LLM writing vs human writing (https://arxiv.org/pdf/2603.27006) or you can do the analysis yourself.
Also, no one said you should stop using them. But overusing them, along with emulating some of the other common traits of LLM generated writing, will give people the impression that you didn't bother to write something yourself.
You’re misunderstanding the problem: LLMs using emdashes more than the average human still doesn’t tell you that the poster you’re interacting with now is an LLM and not one of the many humans who used emdashes before LLMs existed and are the reason why LLM training picked that up as a good trait. Humans shouldn’t stop writing well just because bots were trained to mimic them.
One other problem with this as a heuristic is technical: they used to be hard to enter on Windows so mostly only professionally-edited text there had em-dashes while the ease of entry on Mac, iOS, Android, and to a lesser extent Linux meant that they were more common there. I suspect that this list disproportionately lists Mac users:
Honestly, I simply owned the domain name and think it's mildly amusing. I wouldn't necessarily say I think it's better by any means. Not yet, at least.
There are several things I dislike about some of the existing services though:
1. Most are extremely invasive in regards to personal data and reading their terms makes it clear what their goal is (selling your data either directly or via buyout).
2. Everything constantly tries to push you through their loop: internal messaging, apps, whatever. I'm tired of it. This allows a recruiter to email a person directly.
It's all hosted on free tiers at the moment, so It's really no consequence to me one way or another.
Some changes certainly can be. If the model produces the exact same output for a fixed seed across a variety of inputs after a code change, I think it's reasonable to expect that the change is correct. There are also mathematical transformations that can be applied in some cases that are provably correct. (Not suggesting there's necessarily anything of this nature that will lead to 1,000x improvement though.)
Worth noting if it wasn't obvious from the article that Cloudflare did not develop QuePaxa. It's from an SOSP paper back in 2023[0]. The article is discussing what is the first known large-scale public deployment of the protocol.
Right. But given that the entire point revolves around QuePaxa, it's strange to see no discussion on it. If that weren't the point, the article would be "Why Cloudflare implemented and deployed Paxos".
Which would also be a good read, but this article also isn't that. It doesn't discuss their experience deploying the protocol, aside from the following statement:
> Meerkat is not deployed to production, but we have run multiple proofs-of-concept with up to 50 replicas distributed around the world, to great success. Leaders in our proof-of-concept clusters constantly fail, and the cluster keeps operating with no increase in error-rate.
I think it would've been more interesting to read why Cloudflare chose the specific algorithm they did, see an example of a pathological but common situation Cloudflare sees at their scale that makes other protocols unsuitable for them, therefore they made X choice and this led to Y gains in production (or on dummy workloads, or whatever). As it stands, there's nothing here actually specific to Cloudflare's workload or deployment. It doesn't even state their use-case beyond "small pieces of control plane state (e.g., leadership for replicated databases)"
But it's not a large-scale public deployment yet either. The article says towards the end that they just ran a proof of concept.
Maybe the blog post is just premature. It would be much more valuable if they posted it after actually having run it in production and validated the strengths and weaknesses with real world data.
The tool looks very cool! But IMO you can't get an ER diagram from SQL since entities are fundamentally different from tables. They are certainly very similar, but SQL alone doesn't give you enough information to create an ER diagram.
That's not to say that the tool is useless or that diagrams of this sort are unhelpful. I'll admit I'm being pedantic and others will probably disagree.
> entities are fundamentally different from tables
Isn't the fact that they are _mostly_ interchangeable the foundational principle of hundreds of ORMs? Of course the DDL doesn't say much about the entity's lifecycle, but if the bar is set at representing its relationships, fields and cardinality as a graph, it seems sufficient?
I think most successful ORMs have an additional layer of semantics beyond what can be directly expressed in SQL. For example, Active Record has multiple types of associations (belongs_to, has_one, has_many, etc.) that I would argue align more closely to the ER model than the relational model. Of course you can come up with a set of conventions to go from ER to relational when everything is fed through the ORM, but you are losing some semantic information in the process. (That is, if you just look at the SQL table definitions, you don't have the same information about relationships).
I don't see a problem with the tool either really, it's just a pet peeve of mine to call what it produces an ER diagram when it's really a diagram of the relational model defined by the SQL.
To make parent’s point more exact: from Chen’s definition, these ER diagrams derived from SQL are the “physical” (most low-level) diagrams, you cannot recreate the “logic” or “conceptual” diagrams from it.
I guess nowadays few people care about this difference.
the use case for sql to er, is to study a database new to you
so the db already exist, but they have no er, and maybe even little docs
so it act more like an exploratory tool, ideally, it should allow you to create views and add notes, so you dont have to look at the full er at once, especially if the number of table is huge, and if many of those tables are missing foreign keys
Can you please elaborate on the differences? They are practically interchangeable, but conceptually there might be another layer on top of entities and relationships for somewhat richer semantics (like describing a relation, or additional annotations on the entity)
One example is that in ER cardinality is specified on the relation. In SQL cardinality is implemented and can be largely reversed to ER by looking at where foreign keys are.
Many to many will lead to an extra table (which can have additional properties, requiring this table to be modelled as an entity), one to many leads to the inclusion of a foreign key to another unique key (referring all columns of that key, _id is an implementation decision, compound primary keys are possible). One to one can be implemented in multiple ways, like one to many with a uniqueness constraint by the referring table or even by merging entities to a single table.
The raw SQL can be revealing but when entities have merged into one table it’s harder to tell what is what, unless a certain set of columns appears over different tables.
Aside from what else is mentioned in the sibling comment, inheritance is another big one. Inheritance is not explicit in SQL and in fact, when going from ER to SQL, there are multiple choices you can make about how to materialize the inheritance hierarchy.
Another is that in ER diagrams, relationships themselves can have attributes. Personally I think it tends to make more sense to convert relationships to entities in this case most of the time, but it can be useful.
Finally, relationships in ER diagrams can be N-ary and connect more than two entities while foreign keys in SQL always reference one other table. Of course you can have multiple foreign keys on a table to represent this, but not without some loss of semantics.
Inheritance is one case. In an ER diagram, you may have Employee and Client entities which both inherit from a Person entity. You could choose to have these represented as a single table (with nullable fields where not relevant). They could be three completely separate tables with common fields duplicated across the tables. Or there could be three tables where one table has the common fields from Person with Employee and Client having foreign keys to this table along with whatever unique fields they have.
I think it's moreso you lose all the users who don't realize anything outside the walled garden even exists.
reply