Patryk27

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 }

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

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

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

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

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).

Not sure why all the hostility here - you haven't seen the code, know nothing about the domain and yet you're certain that our performance requirements are false and that "code base got sacrificed" (apparently by adding two lines of rather self-explanatory code?)

Feels like you've just read grugbrain.dev and decided to shoot your golden tips at everybody without actually trying to understand the situation.

Anyway, there's one good point here:

why is your allocator in this path, then?

Because those prices change 24/7/365, million times a day, and so refreshing happens pretty much all the time in the background, eating CPU time. What's more, calculating prices is much more complicated than a hashmap lookup - hotels can have dynamic number of discounts, taxes etc., and they can't all be precomputed (too many combinations).

You know, not all complexity is made up, a little trust in others won't hurt.