ChatGPT recommended this to me recently when I was trying to get some assistance with a usable Tailwind palette. I ended up not needing it right away but it's first in line next time I need to make one.
Any details about what problems you were having getting a usable Tailwind palette? There seems to be lots of different use case so I'd love to hear more.
That's awesome, I haven't kept up in what helps to get into AI recommendations. Guessing it's related to search result rankings? Not sure if the site would be in the training data. Curious if you asked about accessibility as that's my focus.
I suspect that the non-Rust improvements are vastly more important than you’re giving credit for. I think the go version would be 5x or 8x compared to the 10x, maybe closer. It’s not that the Rust parts are insignificant but the algorithmic changes eliminate huge bottlenecks.
> Composed resolvers are the headache for most and not seen as a net benefit, you can have proxied (federated) subsets of routes in REST, that ain't hard at all
Right, so if you take away the resolver composition (this is graph composition and not route federation), you can do the same things with a similar amount of effort in REST. This is no longer a GraphQL vs REST conversation, it's an acknowledgement that if you don't want any of the benefits you won't get any of the benefits.
There are pros & cons to GraphQL resolver composition, not just benefits.
It is that very compositional graph resolving that makes many see it as overly complex, not as a benefit, but as a detriment. You seem to imply that the benefit is guaranteed and that graph resolving cannot be done within a REST handler, which it can be, but it's much simpler and easier to reason about. I'm still going to go get the same data, but with less complexity and reasoning overhead than using the resolver composition concept from GraphQL.
Is resolver composition really that different from function composition?
Local non-utility does not imply global non-value. Of course there's costs and benefits, but it's hard to have a conversation with good-faith comparison using "many see it as overly complex" -- this is an analysis that completely ignores problem-fit, which you then want to generalize onto all usage.
My initial goal is to make a functional SillyTavern (AI roleplaying) replacement. SillyTavern builds prompts from a few rigid buckets (character, scenario, lore, system prompt, author's note...), which makes complex setups hard to manage. Content gets duplicated, settings have to be toggled in multiple places, and it’s easy to accidentally carry or modify state across conversations. Over time, it becomes difficult to tell what context is actually in effect.
I’m building an alternative that treats context as small, reusable pieces that can be composed and organized flexibly, rather than locked into fixed categories. Characters, settings, and behaviors can be mixed, reused, or temporarily enabled without duplication or manual cleanup, and edits preserve clear history instead of rewriting the past. The goal is to make managing complex context deliberate and controlled instead of fragile.
Although I’m trying to get the functionality required for roleplaying done first, the app is generic enough for other AI workflows where fine-grained, explicit context control is an improvement over existing chat interfaces. Think: start a new conversation with an assistant and start checking off rules, documents, and instructions to apply to the chat. Regenerate responses with clarifications or additional one-time context layers.
No, "honor system" is very frequently used and understood to refer to a system where there are explicit rules but where the rules are not enforced via active surveillance.
It sounds like you want to make a judgement call: "they're too small to enforce this license agreement," so you get to pretend it's an honor system and not a license agreement.
My question is what happened between when they went in the water and when they got off-site medical treatment. 7 hours seems like a long time. Is there on-site medical that would be doing something during that time?
Anecdote: My house mate in grad school was working in a national lab when an experiment caught fire and the fire consumed a certain amount of radioactive material. (Tiny little buttons used for calibrating detectors). He was on shift and was the person who discovered the fire and pulled the alarm.
Among other things, he had to sit inside an enclosure made of scintillator material for a period of time, to make sure he wasn't contaminated. Then he also got blood tests for heavy metals etc. They pretty much went by the book for all of these tests.
Also, the facility is the only place that's equipped for this kind of situation.
It’s a process to come into a high radiation area, as well as, a process to come out; I’m sure the worker was not injured so they processed he/she out and decontaminated the individual and did a whole body count. Then release him to medical for evaluation…which in itself is a process.
I have to agree. My experience working on a team with mixed levels of seniority and coding experience is that everybody got some increase in productivity and some increase in quality.
The ones who spend more time developing their agentic coding as a skillset have gotten much better results.
In our team people are also more willing to respond to feedback because nitpicks and requests to restructure/rearchitect are evaluated on merit instead of how time-consuming or boring they would have been to take on.
> My experience working on a team with mixed levels of seniority and coding experience is that everybody got some increase in productivity and some increase in quality.
Is that true? There have been a couple of papers that show that people have the perception that they are more productive because the AI feels like motion (you're "stuck" less often) when in reality it has been a net negative.
reply