I drag a tiny fetch wrapper around with error/json handling, timeouts and basic interceptor support. It doesn't cover everything axios does but it's nice enough and I haven't had to touch it in a couple years.
I often do similar... though most of the time the past couple years, I'm generating the client from OpenAPI integration on the backend that uses fetch as its' base.
When the vulnerability was announced, it took me two minutes to one-shot convert an entire legacy project from axios to fetch (it already wrapped api calls neatly), react cra to vite, update all dependencies, convert to deep imports to reduce bundle size and get zero npm warnings while fetching coffee. There is just no excuse to use it.
Move from a tested library where when a vulnerability is discovered everyone in the world is made aware to an untested one shot llm output that if a vulnerability is discovered will never come to light .
What's the reason to switch to something less stable short/long term? Because its older and newer code is always better?
That's like saying rpad is well tested. Axios isn't exactly rocket science, it is trivial to replace. So much so that even a SOTA llm does it reliably. I'd say good riddance.
I think there is more here: Anthropic's whole market positioning is based on trust. It's literally their reason for being.
The Claude constitution has a major section about not being deceptive. Now this is GTM, not the model, but there is clearly a coherence problem here... and if anyone should realize the important of their market positioning it's GTM.
Agreed that it’s 100% marketing. In some ways Anthropic is more of a for-profit corporation than OpenAI which is at least partially owned by a non-profit.
I use pglite for unit/integration tests and it's been fantastic.
Note that it uses "single user mode." This means a single connection at a time, and thus no concurrent transactions. That takes you a little bit closer to SQLite's single-writer.
It’s terrific to see this. I’m definitely going to give it a whirl. I’ve been working on a specific JavaScript isolate[^1]. This is great source of inspiration for it.
GraalVM is genuinely great -- Native Image and the polyglot story are impressive.
I was put off by the earlier licensing - it was confusing, which wasn't great in a license. The GraalVM Free Terms and Conditions "GFTC" now seems better (curious if people agree?), but I wonder if it came too late.
The decoupling from Java SE was good in many ways, but it also made the future a little less clear too.
Apparently there tends to exist some attrition between both teams, now OpenJDK is having a Python and JavaScript support project, but by integrating CPython and V8, not by reaching out to GraalVM, Project Detroit.
Licensing was why I didn't adopt it, so glad to hear it's improved. Would sure love a non-custom license though. Will have to dive deeper into the GFTC
Just in case you were unaware, there is and was a 100% open source variant of the GraalVM referred to as the "Community Edition (CE)"¹. RedHat built their own distribution based on that source tree called Mandrel². The closed source version is faster in many cases, but the CE release in very capable.
reply