sophiebits
sophiebits on Hacker News
People building applications that use AI do have longer contracts. Not sure how the split is vs Claude Code etc.
Collecting invoices is cash accounting, whereas revenue is realized only over the length of the contract and doesn’t care when the customer pays. (Of course sometimes you have a short-term contract including for professional services and such, but not to the point where a single day would likely be particularly inflated.)
This site isn’t affiliated with SCOTUS.
Presumably they mean they could make user code trigger a write out of bounds to kernel memory, but they couldn’t figure out how to escalate privileges in a “useful” way.
“30% of viewing” I think clearly means either time played or items played. I’ve never worked with a data team that would possibly write that and mean users.
If it was a stat about users they’d say “of users”, “of members”, “of active watchers”, or similar. If they wanted to be ambiguous they’d say “has reached 30% adoption” or something.
The endpoint is not whatever the client asks for. It's marked specifically as exposed to the user with "use server". Of course the people who designed this recognize that this is designing an RPC system.
A similar bug could be introduced in the implementation of other RPC systems too. It's not entirely specific to this design.
(I contribute to React but not really on RSC.)
ZDR is a risk thing for them. They want to make sure you're a legitimate company and have monitoring in place on your side to reduce the chance you're using them for illegal things.
“360 degree peer review” isn’t a thing, the whole idea is that a 360 includes feedback from both your manager and your peers, that’s what distinguishes it from a 180!
:)
Website says "Up to 27 hours video playback", which is apparently 7–8 hours more than the iPhones 13–15 and 4–5 more than the 13–15 Pro. Also normally their battery estimates are conservative.
Feldera, RisingWave, DeltaStream, Epsio, Decodable, Confluent all seem to have some offerings in this space. Probably others too!
TIL, thanks! I know Postgres and MySQL don’t include an equivalent.
These startups (and a handful of others) are what I meant!
Half factor authentication, then, since either one will work.
Comments are usually for explaining why code is doing what it’s doing. If you write just
// If the user triple-clicks this button, the click handler errors because [xyz]
then it’s less clear at a glance that this behavior is undesirable. Is this a bug, or is it supposed to be this way? “TODO” is a quick marker that (to me) means “here’s something that is not ideal and may be worth keeping in mind if you are working on this code”.
If you or your reviewers know that it’s not OK for the fix to never be implemented, then of course, track it somewhere where it will get done. My experience is that discouraging TODO comments leads to less-documented code, not better code.
This license with the custom clause seems equivalent to dual-licensing the product under the following licenses combined:
* Small companies may use it without attribution
* Anyone may use it with attribution
The first may not be OSI compatible, but if the second license is then it’s fair to call the offering open weights, in the same way that dual-licensing software under GPL and a commercial license is a type of open source.
Presumably the restriction on discrimination relates to license terms which grant _no_ valid open source license to some group of people.
In Safari you can hit the Share button at the bottom then pick News.
It’s fair, the docs could be better! And there are certainly subtleties with hooking up the router and bundler and everything. However I will say that really there is no funny business going on.
Basically the entire elaborate RSC apparatus just ultimately outputs a tree of plain React elements with promises and <Suspense> to make it streamy. Sounds like groundbreaking simplicity to me! I kid a bit but really I’m not sure that the RSC wire format is any easier as an output target than the existing public React client API.
Maybe I should make a little demo to show that.
But anyway the point is that the wire format is an implementation detail because the two sides of the wire are actually the same program. Even if they’re running on two different computers.
Nothing about the RSC format is privileged in the React client (i.e., react + react-dom). You can always make your own serialization format as long as it can represent React elements and promises somehow. You can of course also use the RSC wire format and pin to a specific client version (or vendor/fork it) but it’s not a stable format today because it’s not clear if many people would use one and we want to leave room to improve the format as new optimization opportunities arise.
Though you do lose a lot of the magic if you don’t have JS on the server at all. Part of the core proposition of RSC is that it’s easy to move logic across the boundary as your app evolves. What goes over the wire can be a performance decision instead of a “that’s too much of a pain to move to the other side I’ll just leave it” decision. For that reason I’d generally make a thin “backend for frontend” in JS that talks to an Erlang/Rust/etc backend. It’s conceptually part of the frontend but runs on your server.
For what it’s worth, the “normal” value of max-height is none, not inherit or 100vh.
Batched often means a higher latency option (minutes/hours instead of seconds), which providers can schedule more efficiently on their GPUs.
HN automatically recapitalizes words in submission titles so I think it’s possible this could have been submitted as “AIDemos by Meta”.
It may be that his does something important yours doesn’t, but yours is much easier to understand! Short and clear is good.
> other than backwards compatibility