![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
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 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
I would do that… If CI wouldn’t be set to -D warnings
Who even does that? Oh wait, it was me.
Joke aside, it does help to keep the code clean, even more for open source projects where multiple separate people may all have their own codding style, and it helps make it easier to organise.
But I do agree that it can be really, really annoying.
Nah. They are supposed to not care about stuff and just roll with it without any regrets.
It’s just like the wojak crying with the mask on, but not crying behind it.
There’s plenty of cases of memes where the giga chad is just plainly wrong, but they just don’t care. But it’s not supposed to be in a troll way. The giga chad applies what it believes in. If you want a troll, there’s troll face, who speak with the confidence of a giga chad, but know he is bullshiting
My attempt to explain was squashed by this comment
It’s the second time I see it on a programmer humor community. I get you want to advertise, but we already told you that this isn’t the place for that
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
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
It’s not that bad. It definitely helps in long functions.
I’m an advocate for code commenting itself, but sometimes it’s just better to comment on what you’re doing, and in those cases it helps to over commentate.
Instead of letting the reader interweave code reading and comment reading, I think it’s better to do either. Either you go full self describing code, letting the reader parse it as code,m, or you abstract everything, making it more of an explanation of your reasoning, and abstract lines that may look too complicated.
Not every comment needs to be useful, but I still write them to not have this switch between reasoning and thinking in code. It can also double as rubber duck debugging too!
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.