> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved.
I would argue that if flipping a feature flag isn't faster than doing a rollback, your feature flags are not functional. They should be essentially instantaneous and the first thing to reach for as soon as you've identified a problem.
> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved.
This I totally agree with. Using feature flags well requires some discipline on the team's part to stay on top of them and remove them once they've served their purpose.
The other thing that I think people tend to forget is that there are plenty of situations where N+1 queries just aren't that big a deal. Not every view in every application that every developer builds needs to handle massive amounts of traffic with low latency and high cardinality tables. I've built so many apps where there's one or two users, small amounts of data, etc. And even on apps that do have a lot of traffic, there are often internal/admin/maintenance views that don't have the same requirements and no one will notice an N+1 where N = 5 in the worst possible case.
Every time ORMs get discussed, it seems to be dominated by people who are like "but my app has 5 billion concurrent users doing 2 million requests per second and if there's an extra 5ms on my requests, it will all explode!" and can't comprehend that not everyone is building the same kind of systems all the time. Great, maybe an ORM isn't appropriate for your situation.
As someone who's used Django since 0.97 and loves it, Content Types are one of those features that I recommend avoiding. It looks amazing at first but you will eventually regret it.
> Having that in mind, the next project was entirely in Pylons. All was good, until we were asked to add Unicode support.
How long ago was this? I feel like unicode has kind of been a solved problem in Python since python3 came out. In the python2 days it was, indeed, miserable.
And if you had to email someone in Italian, would you really do it with poor grammar? Or would you write it in English and translate it, or use a tool to ensure it's correct?
I'm not telling him to stop writing on his own and instead just let AI write for him, but there's no shame in letting an NLP tool do what it's made for and correct the mistakes you made writing in a language you aren't native to.
Not every application uses LLMs the same way. For some use-cases, price per 1M tokens is absolutely meaningful. Eg, we do a lot of pretty basic classification/entity-extraction/summarization type work on large inputs (100k tokens per request being very common). It's pretty easy stuff; Gemini 2.0 Flash was perfectly adequate, quite fast, and cost $0.10 per 1M tokens (and even less when we could make use of the batch API). Every newer more powerful model obviously can handle the same work but costs significantly more. When we're deciding what model to use, price per 1M tokens is definitely a meaningful metric.
Have you looked at the W3C's SOLID standard? I haven't looked deeply into what you're doing, but it sounds like a less interoperable version of what SOLID already does. https://solidproject.org/TR/protocol
Yes I've checked it out recently. From my understanding of the solid project it is focused on end users while linkedrecords is focused on enterprise collaboration scenarios.
Here is a small piece of text regarding this I've pulled from my notes:
Both the Solid project and LR share a foundational vision: decoupling data storage from software vendors and enabling interoperability across applications. In both approaches, data is stored in a vendor-independent backend.
However, the two systems differ in their focus and technical priorities. Solid is primarily concerned with personal data sovereignty. It empowers individual users to host their own “data pods” and control access on a per-resource basis using access control lists. In contrast, the LR architecture is tailored to enterprise-level SaaS scenarios, where data collaboration across roles and teams is essential. It supports fine-grained, logic-based access control policies embedded directly in a triplestore backend, enabling rich authorization scenarios without requiring domain-specific backend logic.
Solid prioritizes decentralized identity and personal agency, aiming to let users choose where their data is hosted and who can access it—typically across diverse web applications. LR, on the other hand, assumes a centralized or semi-centralized backend under customer control (e.g., an organization’s IT department or a trusted third party), while still preserving vendor independence.
LR provides a flexible API that enables single-page applications (SPAs) to dynamically query all resources a user has access to, based on the authorization logic encoded in the triplestore. In contrast, the Solid project addresses this challenge through the use of typed indexes—explicit data records maintained by each application to list identifiers (URLs) of resources relevant to the user. While this mechanism enables some level of resource discovery, it introduces overhead: applications must create, update, and sync these index records manually. This approach becomes particularly cumbersome in multi-user scenarios where different users have access to different subsets of resources.
They are enterprise customers but I see a lot of use cases where the end user is private person. From what I understand the recurring pattern is: A private person stores data and then specifies who can access this data. Mostly the amount of data records per person is quite small, so the discovery of the records is not that sophisticated.
I think where linkedrecords might be better suited are groupware apps like notion, google docs, airtable, github, where a group of people collaborate on the same large body of data records.
Interesting to read the comments and see the reaction here.
I didn't use Fable (just Opus and Gemini) but I recently ported the `djlint` Python library to Rust, also relying heavily on LLMs (but not trying to one-shot it). `djlint` is a library to lint and reformat HTML and Django template files (and some other formats but I haven't tackled them yet as I don't really have any need). It's currently unmaintained (for a couple years at least) but was part of our CI/CD and the reformat in particular is very slow on a large codebase with thousands of templates. For our code, it took about 4 minutes to run. I generated a Rust port in a similar way, aiming for byte-for-byte output compatability. The Rust version runs on the same code in a fraction of a second; fast enough to put in a pre-commit hook. Some of that was the raw Python->Rust conversion, but a lot was some optimization work that I did afterwards. The Python version was heavily regexp-based, basically running a big slow regexp for every rule that it implements, sometimes running the regexp in a loop starting with each tag it encounters as it goes through each file. For the Rust version, I switched it to properly tokenize the files and then match rules on the AST in a single (or relatively few in some cases) pass. Honestly, there's still a lot of low hanging fruit to make it faster but it's already such a big improvement that I'm pretty happy with it. I'm sure those optimizations could've been done in Python but if I'm the one maintaining the code now, I'd much rather deal with Rust than Python with or without LLM assistance.
I took his Introduction to Cryptography class when he was a visiting professor at Columbia. Absolute master of an old-school chalkboard lecturer. They don't make them like that any more.
I took his Computability class in the Hebrew University. He got angry that students were often late to class, and said that this never happened in Harvard...
For those interested in searching for more here's a Hebrew search string you can use: "פרופסור מיכאל רבין הרצאה" interesting enough Google and YT search yield results in English and Hebrew but possibly different ones than just searching in English.
No. Right now I'm upset that Google has removed (or at least is in the process of removing) the Gemini 2.0 flash model. We use it for some pretty basic functionality because it's cheap and fast and honestly good enough for what we use it for in that part of our app. We're being forced to "upgrade" to models that are at least 2.5 times as expensive, are slower and, while I'm sure they're better for complex tasks, don't do measurably better than 2.0 flash for what we need. Yay. We've stuck with the GCP/Gemini ecosystem up until now, but this is kind of forcing us to consider other LLM providers.
this is one of the reasons im hearing more and more people are using open/locally hosted models. particularly so we dont have to waste time to entirely redo everything when inevitably a company decides to pull the rug out from under us and change or remove something integral to our flow, which over the years we've seen countless times, and seems to be getting more and more common.
products entirely disappearing or significantly changing will be more and more common in the llm arena as things move forward towards companies shutting down, bubbles deflating, brand priorities drastically reshifting, etc...
i think, we're at or at least close to a time to really put some thought into which pieces of your flow could be done entirely with an open/local model and be honest with ourselves on which pieces of our flow truly needs sota or closed models that may entirely disappear or change. in the long run, putting a little bit of thought into this now will save a lot of headache later.
Yeah. Back when Gemma2 came out we benchmarked it and were looking at open models. For our use case though, while the tasks are pretty simple, we do need a pretty large context window and Gemini had a big lead there over the open models for quite a while. I'll probably be evaluating the current batch of open models in the near future though.
Thanks. Yeah, for now we're moving to 3.1 flash lite as that's the new cheapest at $.25/1M and is also still "good enough". 2.5 flash is more expensive at $.30/1M (looks like Deep Infra charges the same as GCP/VertexAI for it). I might check them out for Gemma though. We benchmarked Gemma2 when that came out and it wasn't remotely usable for us largely because the context window was way too small. It looks like 3 or 4 might be worth evaluating though.
I would argue that if flipping a feature flag isn't faster than doing a rollback, your feature flags are not functional. They should be essentially instantaneous and the first thing to reach for as soon as you've identified a problem.
> Also sometimes flipping feature flags can be faster than doing a rollback, especially if multiple systems are involved.
This I totally agree with. Using feature flags well requires some discipline on the team's part to stay on top of them and remove them once they've served their purpose.
reply