I don't think that's true - over the years he's changed his mind from "LLMs are useless slop machines" to "LLMs can be useful when applied wisely".

For instance in "The AI Hater's Manifesto" he says:

> It just came to me — the problem that I have with most people using LLMs is the delineation between outsourcing work and outsourcing thought. Those using LLMs to write little scripts or BQL code on a Bloomberg Terminal are inoffensive. [...] A tool being used as a tool to do tool things — in many cases involving the LLM writing a little 30-line Python script! — is not a problem, though it’s also not a trillion-dollar industry that needed to steal everybody’s art and writing.

Similarly, in "The More You Buy, The More You Lose":

> Sidenote: The only truly useful use case I’ve found is on the Bloomberg Terminal’s ASKB feature, which takes natural language and turns it into BQL code to make requests of Bloomberg’s datasets. It’s genuinely useful!

You can perhaps say that he underestimates what the technology is capable of (or, conversely, that other people overestimate LLMs) - but that's a different kind of conversation.

Sure. But this does not make them proprietary, they work fine with non-Framework laptops as well.

My Framework ethernet dongle works perfectly fine with a Mac that I use for work, for instance.

I didn't write that.

> [...] the you are on the list of people replaceable by LLMs.

lol, love a high quality discussion

> Memory management is just a part of the problem.

Sure, then using Rust is a step forward, because that's one less thing you have to worry about. Seat belts don't save all people, but a car equipped with seat belts is - on average - safer than a car without seat belts.

I mean, it clearly is better (in certain contexts), see e.g. https://blog.google/security/rust-in-android-move-fast-fix-t...

> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.

but Rust's type system did catch this error - and then author decided it's fine to panic if this error happens

> You won't see Go or Java developers making such strong claims about their preferred languages.

yess no Java developer ever said that OOP will solve world hunger

`Środa` means `Wednesday`, but depending on the grammatical case it's going to be translated either to `środa` or `środę` (or five more, but somewhat less likely to appear in UI [1]).

- Next is 2018-01-03. = Najbliższa <środa> przypada na 2018-01-03.

- This event happens on . = To zdarzenie ma miejsce w <środę>.

If you mix the variants, it's going to sound very off (but it will be understandable, so there's that).

What's more, days of week have different genders, which affects qualifiers:

- Wednesday = środa (Wednesday is a "she")

- Monday = poniedziałek (Monday is a "he")

... together with the grammatical cases affecting the qualifiers:

- Wednesday is crazy. = środa jest szalona.

- Thursday is crazy. = czwartek jest szalony.

- I'm busy Wednesday. = Jestem zajęty w środę.

- I'm busy Thursday. = Jestem zajęty w czwartek.

[1] https://en.wiktionary.org/wiki/%C5%9Broda

Screenshots use Berkeley Mono (my "daily driver" font).

:+1: - it was mostly about "damn, it _feels_ like there should be a better way".

> You might be able to get away with the lock approach and you may even be able to use Rc>, which would get a little speed up.

In this particular case that'd be a bit more awkward, because in the actual game the UI is driven by async fn (the rendering itself is sync, of course, but waiting for input is async, and both happen as a part of the same function).

`spawn_local()` could be a good enough solution for that, though.

Comments URL: https://news.ycombinator.com/item?id=45124165

Points: 67

# Comments: 14

    f(packet, time, ...) = { reject, allow }

But this got me thinking about cases where policy _modifies_ the packet, like:

    f(packet, time, ...) = ({ reject, allow }, new-packet)

You're right, thanks - fixed! Small typos like those are the hill I'll die on.

> But I would expect curr.last_of_month().tomorrow().unwrap(), to return 2018-03-01 ???

This case actually matches the `Ordering::Less` branch (14 < 31), so it hits this arm:

    Ordering::Less => curr + Span::new().days(day - curr.day()),

    2018-02-14 + (31 - 14) = 2018-03-03

I've rephrased this section in the article to show the calculation more clearly now.

Hah - fair enough!

Our dataset wasn't so large as to warrant experimenting with GPUs - `cost(extraCpu) < cost(developerExperimentingWithGpus)` - but the CPU implementation got a lot of love; it was mostly engineering-based work, though ("how to load stuff from the disk effectively", "how to make it multi-threaded" etc.), not math-based work ("if we represented prices using $someFancyStructure, we could ...").

I like when seemingly engineering-oriented problems turn out to be way more approachable once you apply / invent / adjust some math foundations, e.g. like with Feldera (https://sigmodrecord.org/publications/sigmodRecord/2403/pdfs...) - wouldn't figure something like this myself in a hundred years, I'd just probably apply maps on top of caches on top of whatever else I could pile until it works!