Patryk27

I’m pretty sure they meant the “post death” copyright, considering the context.

> And even if he changed his mind about some things, he cannot admit it, as that is not what his followers want to hear from him.

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.

So you’re saying the modules have a suboptimal design for non-Framework laptops.

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

I don’t follow - how are modules based on USB-C proprietary?

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

> If you really think that switching language is the main driver to get safe programs [...]

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.

> They claim it is better just because of the language

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.

Regular expressions are not Turing-complete.

There are no comment-based directives in Rust, are there?

> [...] it catches logic errors like this

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

Not the parent commenter, but -- days of week in Polish are a nice example, IMO.

`Ś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 <Wednesday> is 2018-01-03. = Najbliższa <środa> przypada na 2018-01-03.

- This event happens on <Wednesday>. = 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:

- <this> Wednesday = <ta> środa (Wednesday is a "she")

- <this> Monday = <ten> poniedziałek (Monday is a "he")

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

- <This> Wednesday is crazy. = <Ta> środa jest szalona.

- <This> Thursday is crazy. = <Ten> czwartek jest szalony.

- I'm busy <this> Wednesday. = Jestem zajęty w <tę> środę.

- I'm busy <this> Thursday. = Jestem zajęty w <ten> czwartek.

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

This was also covered by 3blue1brown, highly recommend: https://www.youtube.com/watch?v=gB9n2gHsHN4.

Code blocks use Iosevka (slightly configured - https://codeberg.org/pwy/website/src/commit/721438bc7d14789c...).

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

> Worrying about things like this without profiling can cause a lot of unnecessary complexity when planning abstractions in Rust.

:+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<RefCell<_>>, 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.

ACLs are more like a binary function, right?

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

In that case evaluating the function once is enough to know whether the packet should be let through or not, there's no way to sort of "differentiate" this function, no way to step through it.

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

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

In this case you'd be looking for a fixed-point, evaluating this function until new-packet = packet (or you exhaust some time and give up). Not sure on the potential utility, though - just a random thought.

> Shouldn't the nearest 12th day of the month after the 14th of January be 2018-02-12 ?

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()),

... yielding this calculation:

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

Since the actual next occurrence is on 2018-03-31, 2018-03-03 is a valid guess (just a suboptimal one).

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

> that is the lamest joke imaginable and your content is good enough that it doesn’t need “dunks”

Hah - fair enough!

Gotta leave something for others to discover!

Curiously enough, I've used to work in hospitality! (https://pwy.io/posts/mimalloc-cigarette/ & https://pwy.io/posts/memory-for-nothing/)

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!

I've redacted that part (https://github.com/Patryk27/website/commit/818c27967d7e6332c...), since it doesn't quite make sense if you think about it for longer than a couple seconds; it's 23:02 for me at the moment, maybe the night will bring me a new joke!

Ah, you're right - I wanted to include a dunk, but forgot to actually fact-check it! -- gotta figure out something better.

fwiw, Option already implements iterator (well, IntoIterator) - calling .into_iter() on an Option will get you an iterator, no need to create anything custom.

Per-request arenas are a nice idea, yeah - we haven't pursued the optimizations more, because we're satisfied with the current speed, but certainly there are some things that could be improved.

Yeah, the example is not representative - in reality there's a couple of smaller vectors (base prices, meal prices, supplements, discounts, taxes, cancellation policies, ...) + lots of vectors containing indices (`for 2018-01-01, match prices #10, #20, #21`, `for 2018-01-02, match prices #11, #30`, ...), and they can't be actually updated in-place, because that would require using `RwLock`, preventing the engine from answering queries during refreshing.

(which is actually how it used to work a couple of years ago - ditching `RwLock` for `ArcSwap` and making the entire engine atomic was one of the coolest changes I've implemented here, probably worth its own post)

Sure, it is producer-consumer - we use Postgres' LISTEN/NOTIFY mechanism (mostly because we have no other use cases for queueing, so "exploiting" an already existing feature in Pg was easier).

The example in article shows all hotels getting refreshed, but that's just because that's the quickest way to reproduce the problem locally. In reality we refresh/reindex only those hotels which have changed since the last refresh - over day(s) this accumulates and the OOM was actually happening not immediately on the first refresh, but after a couple of days (which is part of what made it difficult to catch).