> I like how Google AI Studio allows one to delete sections and they are then no longer part of the context. Not possible in Claude, ChatGPT or Gemini, I think there one can only delete the last response.
I have the same peeve. My assumption is the ability to freely edit context is seen as not intuitive for most users - LLM products want to keep the illusion of a classic chat UI where that kind of editing doesn't make sense. I do wish ChatGPT & co had a pro or advanced mode that was more similar to Google AI Studio.
the trouble with compact is that no one really knows how it works and what it does. hence, for me at least, there is just no way I would ever allow my context to get there. you should seriously reconsider ever using compact (I mean this literally) - the quality of CC at that point is order of magnitute significantly worse that you are doing yourself significant disservice
if you actually hit the compact (you should never be there no matter what but for the sake of argument) more often than not you'll see CC going off the rails immediately after compacting is done. it even doesn't know what it did let alone you :)
I've been using Valkey simply because after I updated to the latest Fedora version, it dropped redis and pointed me to Valkey instead. I assume as more distros do this and more people update their systems, the Valkey user base will grow. But perhaps with the AGPL redis that will no longer be the case.
Yeah Pix lets you choose limits. There's decent granularity for those, you can pick max $ per day, per transfer, per period, and per device. There's a caveat that when you increase a limit it takes a day or two to come into effect (basically to avoid people being forced to increase their limits by criminals).
It was a few months ago, but when X was banned in my country I tried Bluesky for a while. It took a lot of effort (adding blocklists, muting words and blocking individual accounts) to cleanse the timeline of k-pop and furry content. I am not interested in either type of content and didn't follow any such accounts, but still, the "Discover" feed kept showing that stuff to me. It was the strangest onboarding experience I've ever had in social media.
Life in that planet evolved to essentially hibernate during their long winter. Presumably the processes that resulted in the very earliest life forms happened countless times until some surfaced that had that feature.
> All of the code is OOP-based, and they mount DOM nodes the old-school way (which is what React was supposed to solve..)
I don't know about VS Code, but I remember Atom was refactored to use manual DOM updates because the performance penalty of using React wasn't worth it.[1] By the way, isn't OOP by far the most popular paradigm for building desktop UIs? I imagine VS Code is a difficult codebase to work with that has a lot of intricate code (as is usually the case with large software projects), but that's a strange piece of criticism :-)
I have spent a great deal of time wading through the VS Code codebase and it takes OOP to the extreme. There are mile long inheritance chains, everything is a class, and it is a giant bowl of spaghetti. To some extent, I understand why they used that development approach. It doesn't use a UI framework, just DOM APIs, so classes make sense in lieu of components, but it's still bonkers.
> By the way, isn't OOP by far the most popular paradigm for building desktop UIs?
Yes, but I wish it wasn't. My day job is desktop development (with Electron), and I avoid OOP as much as I can and try to use a functional approach. After jumping all over the VS Code codebase to try to understand how some of this stuff works, and seeing how hard it is to navigate, I think heavy OOP is a bad idea.
Always interesting to hear such claims when graphic editors like Penpot, which have much tighter perf requirements than editors, are so fast while using React.
I think a lot of people don't consider how complex text editors are and then there are the complexities of an IDE, or extensions, to be able to interact with it.
I became aware of Intertia from a Ruby shop some time in 2022, who had good things to say, along the lines of "We could not ship as fast as we do without it." At work we are exploring Inertia to migrate parts of a long-lived Rails application quickly-but-gradually into an SPA. Have not gone live with the first feature yet, but so far a proof-of-concept and our exploration have been positive.
By "quickly-but-gradually", I mean that some pages will remain server rendered, and gradually more migrate to being browser-rendered, but each new page or slice of functionality is very quick to port over. If you have any sort of viewmodel, presenter, or form object abstraction in your server-rendering architecture, it is much faster to just turn that into JSON and use Interia than it is to convert everything into pure JS/TS and generalize a set of APIs to serve the frontend. Of course YMMV depending on your existing architecture and needs.
