Starfox had similar dialogue and predated it and MGS was contemporaneous, so the claim it makes it "modern" is weird. It's just "Zelda OoT if a different team made it".
You comment on this subject regularly in this way, but opinions do vary. Rob Pike says Go is not purely memory safe under concurrency. I as someone who has written multiple languages would describe it as "memory safe except for a pointer-skew hole undermining concurrency" or maybe say "race-free Go is memory-safe".
Seeing a correctness issue that makes Go not memory safe in some circumstances warrants questioning whether it is memory safe. On balance, you might say it is, but to constantly tell people they are wrong for saying otherwise is policing a shared term.
> The new simd package hides these differences by removing fixed-size vectors from the type system, and by only supporting those operations that are in the intersection of all the different platforms, and fills gaps in the intersection with efficient emulation in terms of other SIMD instructions.
The intersection would be the operations supported by all platforms and so would not have gaps.
This argument comes up a lot. It would turn everyone whose device became part of a botnet into a criminal. There's a reason that intent is important in law.
You're referring specifically to tracing garbage collection. When a reference count reaches zero, that garbage is collected, often recursively. Among programming language designers, ARC is considered a GC strategy.
So someone used lower() from an unspecified version of Unicode when the standard was very specific about which to use. And they say "There's also a database of Unicode 3.2.0 data available on every version of Python (unicodedata.ucd_3_2_0) specifically for the StringPrep and IDNA algorithms", so the right version is available.
And then the fix is to hardcode a bunch of special cases which again depend on exactly which version of Unicode is in use, and so will break again in the same way in future, rather than just using the right version?
Regular expressions aren't an algorithm. DFA/NFA-based matching and backtracking are both valid implementation strategies, with different performance characteristics. Backtracking is arguably the most intuitive direct implementation. You and the other poster are confusing the mathematical definition with algorithms used to perform matching.
In common usage, "regex" means patterns accepted by regex engines like PCRE. Police the formal term "regular expression" if you like, but ordinary usage does not honour that distinction.
Also, it's not guaranteed that an engine implementing regular expressions will have O(n) time complexity - a backtracking engine can still have much worse performance on formal regular expressions.
Every optimisation like this increases the chance of other optimisations/vectorisations being able to usefully fire, and sometimes these very specific cases are themselves from optimisations or type/range restrictions.
Do you posit that there are enough examples of 30x8 ellipses encoded in braille online for ChatGPT to learn from but not 31x7 or 31x9 ellipses? That seems unlikely.
They lost me a little before then - Claude Code's regressions were so very obvious and there's no sign they've learned their lesson in this article or in the comments of those who work on Claude Code on HN. They'll continue to tweak and generally mess around with a product people are using, altering the behaviour without notice in ways that can severely impact use, for months! GPT5.4 has been remarkably consistent and capable, as a replacement. I've cancelled my max plan.
In the video in question, he doesn't seem able to choose a good scoring function for the stochastic solver (even over multiple weeks), seemingly choosing a linear sum of distances (see 8:50) between simulation and reality. That's a mistake that not even an undergraduate should make. He needs some domain experts.
Partly, it's simply that words matter. An interpreter is not a compiler, even if partial evaluators and Futamura transforms are very cool. Posting about them in a context that isn't a confusion about what interpreters are may have been more fruitful.
Yes, that's another great example of the same kind of thing - creating a JIT from an interpreter. It remains true that interpreters do not directly generate machine code.
This is still incorrect. A bytecode interpreter, as its name indicates, interprets a bytecode. Typically, compiling a bytecode to native machine code is the work of a JIT compiler.
True, but that’s using “effects” in a broader sense than people seem to mean here. The discussion seems to be about the visible effects the audience experiences as effects, and whether those age well, not invisible digital cleanup, compositing, or set extension.
A common misconception is that git works with diffs as a primary representation of patches, and that's the implied reading of "stores diffs". Yes, git uses diffs as an optimisation for storage but the underlying model is always that of storing whole trees (DAGs of trees, even), so someone talking about it storing diffs is missing something fundamental. Even renames are rederived regularly and not stored as such.
However, context would matter and wasn't provided - without it, we're just guessing.
The comments on this site (HN) may be what most people are talking about. Youtube comments are too easily censored, so they probably will never manage to stick around.
I would probably see text quality issues on that setup. It depends on how far away the monitor is. PPI on phone screens tends to be much higher than PPI on laptops which tends to be higher than PPI on monitors, because each is typically used at a different distance.
If you're not using text around 9 pixels tall, as in the article, you're probably going to be okay. On a 27 inch screen at a typical office screen distance, I'd probably want 6k, but 4k is pretty good and 1080p is terrible.