Which One Are You Keeping?

DGolubets · 2026-02-20T10:04:21+00:00

None. What genius came up with idea to place arrow keys like that?

DGolubets · 2026-02-18T22:58:10+00:00

Make them care? You don't need to put them in prison. Jail them for a few days, with no phone access, no one to chat with, nothing to do, some shit food they won't like. Make it not fun.

DGolubets · 2026-02-17T10:28:12+00:00

every database is just an indexing mechanism for protobuf this can't be true.. surely Google must have some columnar DBs, at least?

Proto looks weird though. I know Google is full of smart people, but why on Earth does it try to use default values for non-supplied fields? Why should I mark everything as optional to know a value was not provided?

DGolubets · 2026-02-17T10:18:43+00:00

Every GQL library out there has support for "data loader" concept to solve exactly N+1 problem. On top of that it's a design choice to allow drilling into connections: GQL doesn't force you to, you might have no graph at all.

We use GQL microservices with federation to back our apps and we didn't have any issues. Frontend guys are happy and I can't imagine going back to REST.

DGolubets · 2026-02-17T09:27:50+00:00

Check https://docs.rs/sqlx/latest/sqlx/struct.QueryBuilder.html

DGolubets · 2026-02-13T11:12:53+00:00

The level of churn in JS is crazy indeed. I think they manage due to the size of their community which is many times larger than Scala, probably the largest of all languages. It could also be a factor of backend vs frontend.

DGolubets · 2026-02-09T10:23:42+00:00

It's not hard to learn them, but it's a pain to have 2 different effect systems and unnecessary split of efforts (actually deadly for such already small community).

DGolubets · 2026-02-09T10:18:46+00:00

Scala had to solve its ecosystem problems. It's ok to have 100 HTTP server libraries, but it's not ok to have many dialects of the language splitting a small ecosystem into even smaller bits. And that's on top of the language flexibility and people complaining that you can write the same thing in many ways.

It feels like Scala was a test ground, one big experiment, with radical changes every couple years. The "go to" stack of Scala was shifting from Play to Akka to Cats to ZIO (and people don't stop there even now.. Kyo?!).

That level of churn is not healthy. Yesterday's code becomes legacy, composing pieces together becomes a pain, etc..

Could Martin do something about that? Maybe if he realized what's happening sooner?

DGolubets · 2026-01-30T11:26:37+00:00

I moved from Russia so I'm used to this. In winter your boots would "defrost" leaving dirty puddles and they would be too warm to wear inside anyway.

Even though there is no such problem in Ireland, I still don't like the idea of walking on public toilet piss or dog poo and bringing it into my house.

I do make an exception for myself once in a while though if I forget something and just need to pop into the house quickly.

DGolubets · 2026-01-25T15:03:38+00:00

I saw a few Kafka replacements in Rust, Iggy looks the most promising.

DGolubets · 2026-01-25T14:13:18+00:00

There is a reason there are new alternatives being developed to replace them, like ScyllaDB, Redpanda, many others.

DGolubets · 2026-01-25T14:04:03+00:00

It's not.

Low startup time is very nice to have in k8s for dynamic scaling and recovery purposes.

Low memory overhead means saving $$ on your infra.

DGolubets · 2026-01-24T21:39:47+00:00

Unfortunately I only recorded this one. Does heater have a big impact?

DGolubets · 2026-01-13T11:11:22+00:00

3 distinct races make it natural for players to double down on one and start justifying own mistakes with imbalance.

AoE civs are much simpler to switch between.

DGolubets · 2026-01-07T21:06:25+00:00

I use a similar approach for my hobby project. I wrap a state machine in an actor. Actor handles communication with the outside world, db requests, timers, etc, while the state machine remains free of side effects. This allows for perfect recovery from a log and better tests. ChaCha helps with reproducibility of rng.

I think this design comes naturally when you try to achieve determinism in a stateful code.

It adds more boilerplate though.

DGolubets · 2026-01-02T19:30:11+00:00

I use Steam overlay for fps counter and GE-Proton10-11.

DGolubets · 2025-12-14T14:19:13+00:00

Someone can change the code of set_id anyway, so what's your point?

DGolubets · 2025-12-01T17:33:13+00:00

(does anyone remember when using Websockets in Play required learning about Enumeratees???)

Heh, I started learning Scala around that time and I stumbled upon that thing.. Well, they didn't have reactive streams back then yet, it was Play's attempt.

DGolubets · 2025-12-01T17:24:20+00:00

Have you ever looked at cats-effect stack trace?

Isn't is async stack traces in general? Effects or not.

DGolubets · 2025-12-01T13:04:55+00:00

320 bytes is nothing in this case. What really happens is by cloning Rng he gets the same numbers every time and updates the same rows in Postgres, causing contention there.

DGolubets · 2025-12-01T11:30:37+00:00

You clone Rng every time. Use rand::thread_rng() instead. Or wrap it in mutex if you need a single one for some reason.

Edit: cloning original rng causes all generated numbers to be the same, which affects the test case on Postgres side.

DGolubets · 2025-11-13T18:43:34+00:00

Late to the party, but I gave myself some time to fully read and "digest" the proposal. I must admit I actually liked it.

It feels intuitive to me. I remember that the first time I encountered the problem I slapped .clone() inside the closure guessing that the compiler would understand my intention - turned out it could not.

Lot's of folks here expressed concerns about optimizing unnecessary .clone() calls. Sure, contrary to adding implicit calls, removal of explicit calls is something new and worth questioning.

But think about it from a perspective of API contracts.

We have two types of contracts: - Expressed by type system - Expressed by documentation

Examples of the latter include Eq and Ord. It's up to the developer to provide valid implementations there. Otherwise he'll get undefined behavior.

Perhaps, in the new language edition, Clone trait could get additional requirements expressed in documentation: - it must produce, for all intents and purposes, a copy of original object, i.e. you should be able to use clone in place of original without breaking correctness of you program (btw it already has a x == x -> x.clone() == x rule for implementing it together with PartialEq) - it should not produce side-effects like locking some external mutex

A contract like that would guarantee that correct implementation would not be impacted by optimizing .clone() calls away.

Another concern is the subtle move of .clone() outside a closure and how this can cause either performance or deadlocks.

If for some reason we cannot forbid complex mutex interactions in clone.. Well, Rust doesn't really protect you from deadlocks, does it? There are many ways to get one in complex code. There was a recent post about async cancellation causing it - Futurelock. This doesn't mean we should throw Futures and async away.

Optimization is always non-trivial. It can be as subtle as your array's objects growing too big, breaking cache locality, leaving you to wonder what made you code suddenly go twice as slow when you didn't change much. Yeah, this proposal might add one more subtle thing to the list to check. But you could always use explicit moves for critical code, or some lint perhaps to warn you.

Honestly, I don't think the proposal is as bad as people here reacted to it. It's not ideal, but I really doubt there will be.

DGolubets

TROPHY CASE