speedstyle

(More precisely, doesn't have the reasoning from when the code was written)

It's not that apps should be websites, but that you should be able to load apps as freely as websites.

uBlock Origin has a built-in option for AI overviews (among other things). Settings > Filter lists > Annoyances > AI widgets

I'm British and I think it's quite different.

Leaflet is (generally) for streaming image tiles, OsmAnd renders a set of geographical features itself. But yes, it could do so more efficiently

Yes, we need abstraction. X being written in Y doesn't mean you can build the same systems, with the same adaptability, reliability, and performance, within the same time and cost.

Obviously there are also unnecessary differences between tools, and hiring shouldn't focus on easily transferred skills

Races can be memory safe (they are in Java and Ocaml), but in Go they can indeed cause UB.

https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...

https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)

Efficiency, output per input, is only relevant for similar inputs. An ICE being more efficient means proportionally lower costs and emissions, but like you said, an electric drivetrain being 90% efficient is less informative than a well-to-wheel comparison.

Similarly, I think it's unhelpful to just expand it to primary energy. What's the efficiency of a wind turbine? In 50 countries already, a 100% efficient ICE would emit more than an EV! The reason for efficiency here was costs and emissions, so compare those.

I for one would prefer to pay for services, than be psychologically manipulated into paying (more, on average) to other companies who are paying to make those services worse.

Much less than 100% of electricity is... still more efficient than ICE? I don't see how that changes things.

US electricity averages 384g CO2/kWh, so EVs emit 100-130g/mile, equivalent to 90-110mpg. And that improves year on year, while an ICE is at best as efficient as when it was produced

You can drive hundreds of miles, but you'd only be able to charge 40-50. If your typical daily use is within that, you can go further at the weekend, or make an unexpected trip, and catch up over a few days (or at a fast charger)

> The net change in accuracy does not show whether the same individual calls succeed with and without the watermark.

Why would that matter in the slightest? LLMs aren't deterministic, the same happens with a different seed, or whitespace in the prompt.

An AI-assisted rewrite can make sense, if you take the time to uphold semantics and code quality, as they suggested. In practice, the first file I looked in had unsound unsafe – in the Rust sense, that a safe caller could cause UB, not that any callers do so – in fact there are no callers, the functionality was removed from the C++ bindings in a 1400-file changeset but left in the associated Rust module.

Humans have the ability to consider things beyond their immediate incentives. Most find it difficult not to.

We don't know what benefits they received from defecting anyhow

'Best' is putting it strongly for an autonomous claudish summary of an autonomous claudish rebuttal to a claudish write-up of the finding

In Rust these specifically take `FnMut`, a function which can update internal/borrowed state, rather than `Fn` which can't easily. In `map` or `filter` you shouldn't rely on the iteration order so that's not often useful – maybe something 'logically' stateless but which needs a mutable connection/threadpool/cache, or eg a counter which is really an ancillary reduction. There's even `inspect` which is explicitly for such side effects. In `fold`, the order is guaranteed and you could use it for a state machine, a fiddly `zip` with other mutable iterators, etc – something you need to perform the reduction, but which isn't really an output, I think you could reasonably write either

    .fold(init, move |acc, x| {…})  // or
    .fold((state, init), |(state, acc), x| {…}).1

I think the authors above put their opinion well: "Developers of self-driving vehicles work with a particular idea of a possible and desirable future. Members of the public may not share the assumptions on which this is based … Many respondents present alternative representations of relationships between the technology, other road users and the future. Rather than accepting a dominant approach to public engagement, which seeks to educate members of the public away from these views, we instead propose that these views should be seen as a source of social intelligence, with potential constructive contributions to building better transport systems. Anticipatory governance, if it is to be inclusive, should seek to understand and integrate public views rather than reject them as irrational or mutable."

I don't have an issue with autonomous vehicles (though I think we should also reduce the overall proportion of trips by car) but yes, obviously you need societal buy-in. "People want this" into 'some don't but they'll die' is hardly a serious approach to policies that impact everyone.

Anyway, I don't think your interpretation is supported by that data. Every age group responded net negatively, and age wasn't the strongest factor – for instance, women were less than half as likely as men to be comfortable sharing roads with self-driving vehicles

Obviously that's not true, but moreover it's meaningless – what counts as an option?

US cities are spread out due to policies enacted only 50–60 years ago to improve connectivity by car. New policies can (and will) reshape them again in the next couple of decades. For example, building transit creates environments where people's trips are well served by transit.

> people want this.

Could you justify this? e.g. https://doi.org/10.1080/17450101.2024.2325386 (N=1890):

"What first comes to mind when you hear the term self-driving vehicles?" (coded free-text) 17% positive, 34% neutral, 49% negative

"How would you feel about riding in a self-driving vehicle instead of the existing ways you travel?" 28% comfortable, 15% neutral, 53% uncomfortable

"How would you feel about using the roads alongside self-driving vehicles?" 29% comfortable, 20% neutral, 49% uncomfortable

A 64-bit sum type can't magically combine an i64, f64, and several raw pointers, each of which carry a full 64 bits themselves. You have to change the semantics of the code. Some semantics could be expressed more easily with compiler improvements, allowing eg `Aligned<T>` like `NonNull<T>`, or `FiniteF64` like `NonZeroU64`, or even `#[range(0..1<<60)] u64`, but you still couldn't overlap two `Aligned`s in one enum, because only one can be stored unchanged, the others need masking off before usage. Even if the enum semantics allowed this, I'm not sure the compiler should do this kind of compute/memory tradeoff automagically. Which doesn't mean you can't write nice abstractions over it, there's a few tagged ptr crates which aim to do it for you

realloc is frequently O(n), ie CPython can avoid copying and immediately collecting the object but still copy the bytes. It's the same as calling reserve in a loop

I for one don't care about memory safety. Rust makes it easier to compose software by expressing everything in your function/module signature. This is what OOP aimed to do, but was quite prescriptive (a datatype often isn't the natural unit of encapsulation). It maximizes local reasoning, so you can make changes to a large codebase with less understanding of uses elsewhere, and reuse functionality in new ways without changes.

C#, Go, Swift are (mostly) memory safe, but I don't think they provide this level of modularity or broader reliability. Expressive interfaces/contracts are useful for all sorts of things, you can use them for memory management but for me that's almost a by-product. I certainly don't consider it a restriction on the kinds of program you can write

The point of the crate, the readme you quoted, is

> you can push to the vec even while holding references to elements that have already been pushed.

Expressing this in Rust (without leaking references to a dropped container) means taking &self. It's true that the container struct itself (chunk pointers, len) is mutated, but the compiler has no distinction between this and the pointee data, so you use ..Cell. It does allocate, there's no capacity limit, but it guarantees stable pointers to existing items.

> The data structure never moves an element once allocated

Yours will reallocate every so often, invalidating element references. append_only_vec requires only `&self` to push, and can also be used concurrently. Adding these abilities requires unsafe, so it wants its own module to uphold invariants on private members. Add an efficient well-tested impl and several other traits you might want, and a shared crate is entirely reasonable.

The standard library is not versioned, so any API*/behaviour there must be maintained forever. When you put it in a separate crate, you can make better interfaces or be displaced by a better crate, while old code still compiles against the version it was written for. So even code effectively maintained within rust teams (hashbrown, rand, regex) may be in separate crates, std is specifically for OS abstraction and a shared type vocabulary.

That doesn't mean you jump to importing nonsense or trivial dependencies. The top hundred are efficient, well-designed crates of the quality you'd expect in a large std like Go or Swift, sometimes even higher as people can write better implementations that they otherwise wouldn't (or wouldn't be used over std). And those languages make breaking changes! C++ is mostly stable, so it's full of junk like <regex> or just unordered_map. Rust managed to wholesale reimplement HashMap 6 months after SwissTable released, like it is also easier to express this level of encapsulation, but that's part of countless design/interface decisions made deliberately to not constrain forwards compatibility, including a smaller std.

However, that's no excuse to have a worse developer experience in this area. We need better tools to vet and communicate the quality of a crate and its supply-chain, like community-curated or even additional org-maintained crates, and maybe a handful delivered precompiled in the default rustup distribution which can change over time. I don't think they need to be added to std itself though

It's not because of the errors, it's clearly written by Claude. Although I doubt if they prompted it to make errors, just generated the majority and edited/wrote some parts themself.

I find it rather annoying that so many submissions on hn are LLM writing, but yes I don't generally find it worth discussing. except that this one explicitly claims not to be

or Tinfoil [0]? They serve open models with container integrity attested by Nvidia/AMD enclaves. Every cloud provider offers this of course, but not usually in a way that can be shared between distrusting users for economical inference. It still relies on the open-source containers being secure, and there's probably hardware sidechannels and stuff, but personally (ie privacy not liability) I trust it more than a contract

[0] https://tinfoil.sh

Would they disagree, new toolchains work great with old code? And even add 95% of the features to older editions, just not new keywords or inference defaults. I think in C++ people complain about the effort to migrate --std, rather than having to learn variants or concepts. It does add to the complexity of course, and it's useful to agree on a consistent style, I just mean Rust doesn't have the particular issues with everyone having to migrate in lockstep, or anyone needing to for new tools

Every 20k miles in the Porsche emits as much as producing a typical EV. Maybe 50k miles in an old hybrid. And it's not just emissions, significant resources and labour go into finding, extracting, refining, transporting fuel, compared to burning half as much in a CCGT, let alone renewables.

Obviously it would be even better to keep one EV longer (hard to say how much better, they do displace ICE vehicles in the used market) but they're almost certainly consuming less than you.