I've been thinking about this and using Rust for my next backend. I think we still lack a true "all in one" web "batteries included" framework like Django or RoR for Rust.
Maybe someone should use AI to write the code for that...
Sugar free coke is not as bad as sugar-ful Coke but it's still bad. Many of the cheap sweeteners have been linked to cancer. They still fuck with the brain and hormones and make you want salty foods and/or more sweet tasting things.
So yea, how about drinking water as your primary source of hydration?
If you are poor, the last thing you need is Diabetes, Cancer, Hypertension, Cardiovascular disease, etc.
The problem also is there is a huge amount of fraud with SNAP with people claiming benefits for multiple people and then reselling their SNAP cards to just make cash. The people buying the endless cases of Mountain Dew often have just bought a 50% discounted SNAP card off some other person who isn't starving at all.
"Linked" to cancer at outrageous consumption levels. No artificial sweetener on the market is remotely as dangerous as sugar. Risk should never be examined in isolation, but only in comparison with the alternatives.
And where is the evidence of widespread fraud? The MAGA crowd keep pretending everything government is full of fraud, but they keep faring abysmally at finding said fraud. The problem is not fraud, but wasted effort. Most things government involve a lot of duplication of effort because everyone wants a piece of the pie. And all too often they spend a dollar to save a dime. A pair of examples illustrates the problem:
1) My wife tried to buy what turned out to be a 31 pound watermelon. Oops, has to be weighed on a properly certified scale to be allowed to sell it--and every such scale they have only goes to 30 pounds. Once the problem was identified the manager proposed a simple solution: sell it to us for the price of 30 pounds of watermelon. Not even a minute.
2) DMV. They made a field too short, two people used different abbreviations to fit into the field, the registrations didn't match and the unused portion of the old registration that should have transferred over didn't. By the time it was fixed IIRC 4 people had been involved, something like an hour passed. Over what turned out to be $6. (Not that I knew the number when I squawked.) The vast majority of that time was spent trying to document to the system that it was proper. Nobody with the authority to simply say moving this money is proper, do it.
And the related problem of politicians always wanting to visibly do something. Lots of duplicated effort because of this. Locally, several professional type fields require a separate business entity for every licensee even if they are part of something else that is licensed. A few hundred dollars a year per person for absolutely no benefit to society.
You're going to get very bored just drinking water all day every day. Why can I buy coffee to make my water more interesting? Why can I buy Kool-Aid and pour 12 tablespoons into a glass, but I can't buy a Coke? What about a diabetic who is out and needs a quick sugar fix?
Might as well tell people they also just need to eat plain rice for every meal too.
I get there is some fraud on SNAP. I know people on SNAP. Most of them use every single cent on decent food. I've seen fraud, though. In Chicago I would place a bet that most non-chain convenience stores will sell you cigarettes on SNAP. Some of them absolutely sell weed on SNAP.
But the bottleneck is generating embeddings either way.
memchunk has a throughput of 164 GB/s. A really fast embedder can deliver maybe 16k embeddings/sec, or ~1.6GB/s (if you assume 100 char sentences)
That's two orders of magnitude difference. Chunking is not the bottleneck.
It might be an architectural issue - you stuff chunks into a MQ, and you want to have full visibility in queue size ASAP - but otherwise it doesn't matter how much you chunk, your embedder will slow you down.
It's still a neat exercise on principle, though :)
It doesn't matter if A takes much more time than B, if B is large enough. You're still saving resources and time by optimising B. Also, you seem to assume that every chunk will get embedded - they may be revisiting some pages where the chunks are already present in the database.
Amdahl's law still holds, though. If A and B differ in execution times by orders of magnitude, optimising B yields minimal returns (assuming streaming, vs fully serial processing)
And sure, you can reject chunks, but a) the rejection isn't free, and B) you're still bound by embedding speed.
As for resource savings.... not in the Wikipedia data range. If you scale up massively and go to a PB of data, going from kiru to memchunk saves you ~25 CPU days. But you also suddenly need to move from bog-standard high cpu machines to machines supporting 164GB/s memory throughput, likely full metal with 8 memory channels. I'm too lazy to do the math, but it's going to be a mild difference at O($100)
Again, I'm not arguing this isn't a cool achievement. But it's very much engineering fun, not "crucial optimization".
I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.
We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.
We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).
Everyone was a team working together towards the same goal of making these tools the best for our internal audience.
It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...
So are photos that are edited via Photoshop not art? Are they not art if they were taken on a digital camera? What about electronic music?
You could argue all these things are not art because they used technology, just like AI music or images... no? Where does the spectrum of "true art" begin and end?
They aren't arguing against technology, they're saying that a person didn't really make anything. With photoshop, those are tools that can aid in art. With AI, there isn't any creative process beyond thinking up a concept and having it appear. We don't call people who commission art artists, because they asked someone else to use their creativity to realise an idea. Even there, the artist still put in creative effort into the composition, the elements, the things you study in art appreciation classes. Art isn't just aesthetically pleasing things, it has meaning and effort put into it
GraphQL was created to solve many different problems, not just overfetching.
These problemes at the time generally were:
1) Overfetching (yes) from the client from monolithic REST APIs, where you get the full response payload or nothing, even when you only want one field
2) The ability to define what to fetch from the CLIENT side, which is arguably much better since the client knows what it needs, the server does not until a client is actually implemented (so hard to fix with REST unless you hand-craft and manually update every single REST endpoint for every tiny feature in your app). As mobile devs were often enough not the same as backend devs at the time GraphQL was created, it made sense to empower frontend devs to define what to fetch themselves in the frontend code.
3) At the time GraphQL was invented, there was a hard pivot to NoSQL backends. A NoSQL backend typically represents things as Objects with edges between objects, not as tabular data. If your frontend language (JSON) is an object-with-nested-objects or objects-with-edges-between-objects, but your backend is tables-with-rows, there is a mismatch and a potentially expensive (at Facebook's scale) translation on the server side between the two. Modeling directly as Objects w/ relationships on the server side enables you to optimize for fetching from a NoSQL backend better.
4) GraphQL's edges/connections system (which I guess technically really belongs to Relay which optimizes really well for it) was built for infinitely-scrolling feed-style social media apps, because that's what it was optimized for (Facebook's original rewrite of their mobile apps from HTML5 to native iOS/Android coincided with the adoption of GraphQL for data fetching). Designing this type of API well is actually a hard problem and GraphQL nails it for infinitely scrolling feeds really well.
If you need traditional pagination (where you know the total row count and you want to paginate one page at a time) it's actually really annoying to use (and you should roll your own field definitions that take in page size and page number directly), but that's because it wasn't built for that.
5) The fragment system lets every UI component builder specify their own data needs, which can be merged together as one top-level query. This was important when you have hundreds of devs each making their own Facebook feed component types but you still want to ensure the app only fetches what it needs (in this regard Relay with its code generation is the best, Apollo is far behind)
There's many other optimizations we did on top of GraphQL such as sending the server query IDs instead of the full query body, etc, that really only mattered for low-end mobile network situations etc.
GraphQL is still an amazing example of good product infra API design. Its core API has hardly changed since day 1 and it is able to power pretty much any type of app.
The problems aren't with GraphQL, it's with your server infra serving GraphQL, which outside of Facebook/Meta I have yet to see anyone nail really well.
Please please please, if you have young kids learning to read or who will need to soon, educate yourself by listening to the "Sold a Story" podcast from NPR (it's on Spotify and other places).
There is so much bullshit out there about how kids should be taught to read, and too many schools unfortunately still use wrong methods disproven by science.
What works is phonics, old, tried and true. If your school isn't teaching it, you need to do it yourself at home or your kids risk never being good readers.
reply