I got nothing against other types. Just numbers/misleading types.

Although, enum variants shall have a label field for identification if they aren’t automatically inferable.

This is understandable in that use case. But it’s not everyday that you deal with values in the range of overflows. So I mostly assumed this is fine in that use case.

This isn’t even an issue of middle ware sometimes. It’s just… Knowing the DB. And I rather not spend time learning when you can just make docs

As if I had a choice. Most of the time I’m only on the receiving end, not the sending end. I can’t just magically use something else when that something else doesn’t exist.

Heck, even when I’m on the sending end, I’d use JSON. Just not bullshit ones. It’s not complicated to only have static types, or having discriminant fields

The schema is this SQL statement

If a item can have different type, those label fields are actually quite useful. So I don’t see the problem

You guys have docs?

Sadly it doesn’t fix the bad documentation problem. I often don’t care that a field is special and either give a string or number. This is fine.

What is not fine, and which should sentence you to eternal punishment, is to not clearly document it.

Don’t you love when you publish a crate, have tested it on thousands of returned objects, only for the first issue be “field is sometimes null/other type?”. You really start questioning everything about the API, and sometimes you’d rather parse it as serde::Value and call it a day.

To whoever does that, I hope that there is a special place in hell where they force you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.

Sincerely, a frustrated Rust dev

See edit

See edit

This one isn’t even an XKCD. This is just a shitpost

Edit: I meant that it doesn’t have the XKCD vibe. Not that it isn’t an XKCD.

Usually, XKCDs are extremely nerdy and touch scientific subjects. But here, the joke is something I’d see in the local meme community.

My attempt to explain was squashed by this comment

I do push often as I’m often switching between two devices. And I do make draft PR so I got an easy git diff that I can live reference with

NGL I 'm a bit like that. I often do “work” commits so that my working tree is a bit more clean/I can go from working state to working state easily.

But before a PR, I always squash it, and most times it’s just a single commit

I don’t see how making noise is good. I live in a street that doesn’t get much traffic, but even one car is loud enough to be bothering.

I don’t want to pause my music and conversations just because someone decided that vroom vroom sounds were more important than me hearing literally anything else.

Even more that noise pollution is definitely a thing, and affect both mental health and physical one.

Well until you are deep into trait/future/generic territory. Because then you’ll go in big fuck (full type being in a separate file) not being correct somewhere in this shit.

Don’t get me wrong, I love rust. But those area really need some love

• Cut all the episodes to have snippets that keep the same timeframe, then watch those in order
• If two clips are supposed to be the same time, splitscreen
• TARDIS scenes would make sense to keep before they arrive to their destination. And TARDIS episodes should be kept in the “”“present”“”
• If the time happens all at once, play all the frames of the clip at once. Preferably stretched to be in the background of all the Chronological Dr. Who Marathon™
• False realities and bubble universe should either be split screen or inserted in between the start and end of that part.
• We go in the time’s order. We don’t care about the love birds.
• If there’s a cliff hanger, just play the next chronological clip
• Cyclic story can be split screened.

They created it. The compiler says the jump function is in src/main.rs

Sad we don’t see more of it, but it just didn’t catch on.

At the same time the industry does a lot of bait and switch, so I understand