ghusbands

The announcement says "and the glasses decode them to text at the speed of speech."

From your other comments, the glasses do not decode them (that's done in the cloud) and there's noticeable delay that would prevent conversational use. Could you clarify what you meant?

The announcement says "and the glasses decode them to text at the speed of speech."

From your other comments, the glasses do not decode them (that's done in the cloud) and there's noticeable delay (500ms). What were you intending to communicate with those words?

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.

Isn't one of the bugs around ten years old, now? Isn't ten years enough to call something a feature of the language rather than a bug?

I like Rust, but with this bug existing for so long, I personally no longer think of it as memory-safe.

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.

https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

https://users.rust-lang.org/t/reference-counting-garbage-col...

It's even more fatiguing to see so many comments about whether something is LLM-written or human-written. I hope we get past this stage, soon.

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?

Refcounting is indeed a form of GC (and the languages that want to handle cycles then need an extra form of GC on top of it).

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.

So, on a news discussion site, active discussion gets penalised. There really should be a human in the loop on that one.

The article now says "[UPDATE, SATURDAY 8 AUGUST: Consider this entire story retracted for now. Details forthcoming.]"

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.

That's a partial evaluator, not an interpreter, and it converts an interpreter into compiler, which are different things.

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.

It has DEFLATE code, Snappy code, LZ4 code, ZSTD exploration, and describes many involved sub-algorithms, with diagrams - what more were you wanting?

I wonder why most of the "g" characters are cropped.

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.

Even with high effort, the adaptive thinking can just choose no thinking. See bcherny's post they were replying to: https://news.ycombinator.com/item?id=47668520

Steganography is (hopefully invisibly) hiding information in an image, not creating an image that so obviously encodes information.

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.

Yes, once you use 'unsafe' to bypass the safety model, you don't get safety.

Edit: If you reply with a reply, rather than edits, you don't get such confusion.