936 karma · joined February 3, 2015
In short, no - from my understanding, it does actually fix the underlying issue, rather than special-casing the game. I wouldn't be surprised if there are a few edge cases like that which are special-cased, particularly for older games (when "abuse" of CPU/GPU quirks was more common to eke out extra performance).
GP’s point stands, you can’t enforce a time lock with cryptography primitives. That’s the fundamental issue with DRM - you’re trying to restrict someone from getting your ciphertext, while at the same time allowing them to get to it if they meet certain (non-cryptographic) conditions, which standard cryptography just can’t do.
In short, it's because Vercel invested engineer-years into piloting RSCs as part of a production framework and making Next the guinea pig. Next wasn't actually the first framework to try RSCs - Hydrogen (Shopify) and Gatsby both tried early versions of it and provided feedback, but Next is the first to implement it to the point that it can be considered stable.
The long-term goal is that RSCs aren't a Next-only concept - for example the Remix team said that they wouldn't implement them until they became more stable (https://twitter.com/ryanflorence/status/1678416472010260480), but are working on it now (https://twitter.com/ryanflorence/status/1697253955376722092). But the React team has always historically favoured trying new features in production to iterate on the API (this happened a lot internally at Meta), and this was an opportunity to do that.
To take a concrete example, I'm working on a codebase that houses both a Node.js server-side application and an Electron app that communicates with it (using tRPC [0]). The Electron app can directly import the API router types from the Node app, thus gaining full type safety, and whenever the backend API is changed the Electron app can be updated at the same time (or type checks in CI will fail).
If this weren't in a monorepo, you would need to first update the Node app, then pick up those changes in the Electron app. This becomes risky in the presence of automated deployment, because, if the Node app's changes accidentally introduced a breaking API change, the Electron app is now broken until the changes are picked up. In a monorepo you'd spot this scenario right away. (Mind you, there is still the issue of updating the built Electron app on the users' machines, but the point remains - you can easily imagine a JS SPA or some other downstream dependency in its place.)
[0]: https://trpc.io/
const items = [];
let runningTotal = 0;
for (const item of someArray) {
runningTotal += item;
items.push(<li>Item {item}; running total {runningTotal}</li>);
}
return (<ul>{items}</ul>);
In general in my experience, when you take away the constraint of inter-language interop, you get much smoother DX because you can take advantage of language features. A good example would be the lack of native date/time types in JSON - valuable for interop because different languages handle dates differently, but painful when you're going to/from the same language. Web applications are a special case, because the client-side is effectively constrained to either JavaScript or WebAssembly (except you'd still need at least some JS in the latter case), so it follows that you'll get the best DX if you have JS or TS on both sides of the stack, especially if you can set up your project in a way that lets you share code between both. Not always an option, but I've always felt more productive (as a full-stack dev) when I've been using TS on both the client and server, compared to TS on the client and another language on the backend.
[1]: https://phabricator.wikimedia.org/T337586#8932905 [2]: https://phabricator.wikimedia.org/T337586#8936483
Also interested in comparisons between WebRTC and SRT, in particular for low-latency high-quality streaming (the niche between traditional streaming like RTMP and more conventional WebRTC apps where latency trumps quality).
https://gds.blog.gov.uk/2020/09/22/introducing-gov-uk-accoun...
If you're alluding to "120% time", fair enough, but that's not what GP was referring to.
What you're referring to (voluntarily infecting people) are challenge trials, which are also being discussed, but are still somewhat ethically dubious.