This JEP is essentially about caching the JIT's generated code for later runs. The JIT is still free to discard the cache if it deems it worthwhile.
1,588 karma · joined June 12, 2013
From the article, at the end of the second paragraph:
> Could a team of agents pull it off? It only took about 2,000 pull requests but DoltLite going Beta proves a team of agents certainly could.
The first PR was merged March 17th.
"vibe coded" seems pretty fitting
Trading off total size with more network requests.
> does HTMX make fetches magically faster or what?
With backend rendering (htmx) you'd do all of that on the initial render, which would be faster than first fetching the app, then fetching the data, as you'd typically do in a single page app.
So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly.
If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.
Everything served under one domain doesn’t have to use one technology.
Use backend rendering when you can, use HTMX where you need a little bit more, use React on the actual bits where it matters.
As a side-benefit, the React bits might end up less complicated as React doesn’t need to handle every single use case.
I think I'm handling this as well, though. I have my own personal retrospective every once in a while where I evaluate the different things I work on and if they're worth continuing, or if there are other things (or just rest) I need to replace one of them with.
Got to admit, I stopped reading here.
In my experience, burnout isn't related to the amount of work, but to your confidence in being able to do your job and if you find your job meaningful (like, does it even matter?).
I'm probably doing twice as much work now compared to the period just before I burned out, but I'm also nowhere near a burnout. Part of that is general experience, but it's also because I feel like I know what I'm doing (so, no imposter syndrome) and because I've chosen my job based on what I find meaningful to do (is it ethical? does it make a difference in society? is it interesting?).
I understand why LLM assisted development can lead to burnout. You now have a machine that "does most of the work for you". It's a gateway to questions like "how good are you really at your job?" and "anyone could push these buttons, couldn't they?" and "is this what the rest of my life should be?". It probably also reduces how interesting or fulfilling the job is for many people. You've been reduced to a cog in the machine, and you might be questioning your ability to be anything but.
The new Mistral Medium 3.5 is also a big improvement over devstral-2
But yes, it tends to be soldered on.
I've personally never discovered projects through Github.
Also, my understanding is that ATProto is relatively centralized in practice, wheras in radicle every node is sort of equal.
Every user has their own node, and everyone's node talks to several seed nodes. Even if the official HardenedBSD seed is down, there's still going to be another node to sync with.
I work for money because I need food on the table and a place to sleep. It doesn't motivate me much more than that. In fact, I wouldn't even call it motivation. It's a requirement to live.
There have also been studies that have found that money stops making people happier or more motivated once their yearly salary exceeds a certain amount (the equivalent of 700.000NOK here in Norway).
Some people are primarily motivated by making as much money as possible, sure, but most people I've worked with have found someplace else to work once their current job stops being interesting.
Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in.
Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).
It's possible to setup CI: https://app.radicle.xyz/nodes/ash.radicle.garden/rad%3AzwTxy...
There's also a CLI for issues and pr's, which also get's stored in your git repo.
I've tried it with some of my projects and it seems promising, but I wonder what it'd be like to use it on one of my more successful projects.
Previously this would be problematic, as the new instance might miss changes made by the old server. Is this fixed by these new changes?
Sourcehut
> Startpage uses Google's index.
If they have enough users/make enough money, they'll make their own. Ecosia and Qwant (both european search engines) are working together to make their own index.
In any case, even if a european is a proxy for an american service, you need to prove that there is a market for an european equivalent for change to happen.
It all depends on your app, really. For some apps the above won't make sense, but maybe it would make sense to keep one db per org, or something like that.
I currently use Litestream (https://litestream.io/) for efficient SQLite backups to S3, and I'm happy with that.
For me, the main point to consider wrt SQLite is if you need high availability or not. And how easy it is to setup litestream and persistent storage.
Saves me from doing that extra commit, then.
> [...] it is suitable primarily for very short-lived tasks that prevent you from committing changes to a branch.
That's also a thing I like about jj. Nothing prevents me from committing changes. Even merge conflicts are commited, so I know I can always come back to it later.
I find I think less about when to commit my work in jj. In Git I find that I like to commit to avoid loosing work, in addition to commiting when I feel "done" with part of a change.
It's a small thing, really, but it feels quite big (for me).