You know, I always wondered what the original image looked like, and even trusty Know Your Meme doesn’t show it. It looked like this:
It works and is a pile of jank - Python
It doesn’t work and is a pile of jank - C++
You violated gods laws with how bad your code is and it still runs (right through the wall) - C
a compile-time error is highly preferable to a run-time error
In bigger projects, you tend to miss type safety really bad, really fast. Rust has it built in, Python can have it bolted on. That’s simply one of the many aspects to consider when choosing your programming language.
But don’t worry about it too much. If one thing’s for sure, it’s that you will regret that choice in any case.
It’s like learning Perl back in the day, then needing to learn use strict;
Perl is a write-only language.
I used to love it, it could look a lot like c, or you could do crap like
$_=<<'';y;\r\n;;d;$_=pack'b*',$_;$_=eval;$@&&die$@;$_Admittedly, they’re trying to obfuscate it, but even unpacking it a bit, it looks alien.
Or you can get a different kind of weird.
Yes! That was the other thing I wanted to include, but I couldn’t remember the name or search for it, so I wrote it off as a fever dream!
Rust is completely correct to be a dick about it as well. Type safety is there for a reason.
I’d like it better if things were designed to work together better.
Right now, I’m working on a password storage system using the
password_hashcrate. You need to provide the salt yourself; this is already a bit silly for not providing a simple default that just gives you 16 bytes from a CSPRNG, but let’s continue.You read the Salt struct documentation, and it talks about UUIDs being pretty good salts (well, using v4, anyway). So that pushes you toward the
uuidcrate, right? Except no. That crate doesn’t produce formats that the functions on the Salt struct will accept, like base64. So maybe theuuid_b64crate will do it? I don’t think so, because that crate uses a URL-safe version of base64, and it’s not clear Salt will take that, either.You’re now forced to use a cumbersome interface from the
randcrate to make your salt. I’m still working through some of the “size not known at compile time” errors from this approach.All of which would work better if there was a little thought into connecting the pieces together, or just providing a default salt generator that’s going to do the right thing 90% of the time.
Don’t get me started on how Actix hasn’t thought through how automated testing is supposed to work.
Am I correct in saying that you’re used to languages that aren’t type safe? Or at least not as strict about it.
Everything you’re describing sounds more like you’re struggling with type safety in general and I wouldn’t say any of those packages are at fault, in fact I’d even go further and say they’re like that by design.
The reason you don’t actually want any of those separate packages to be more interoperable out of the box is because that would couple them together. That would mean dependencies on those packages, it would mean if it wanted to use something else then you’d be a bit stuck.
Like I’d question using a uuid as a salt, like it’s fine and I get why they’re suggesting it, but you can use anything as a salt so why couple yourself to a specific uuid library? Why couple yourself to uuids at all.
Side note: I’m guessing the reason the crate expects you to supply your own salt is because you need to also store the salt next to the password hash, if it generated the salt for you there’s a chance you might ignore the salt and suddenly not be able to validate passwords.
Anyway…
The only way you could make these separate packages work dramatically together and without coupling them would be to use a universal type - probably a byte array - and at that point you lose most of the benefits of a strong type system. What are currently compile errors become runtime errors, which are much worse and harder to diagnose.
My suggestion to you would be to reframe your thinking a little, think less about how you can make different crates speak to each other and more about how you convert from one type to another - once you crack that, all of these integration problems will go away.
Yeah, gotta newtype it up to make it even more relentless.
Hey at least it’s not JavaScript which is perpetually high on crack with Object object
1 + 1 = “11”.
Well, that happens when you don’t override the
toStringmethod. Not worse than Java’s 0xf00cuHey, javas default toString gives you two informations:
- type, not that the class names in many java projects are informative
- identity, while the pointers are gibberish you can see if they are the same gibberish
You wouldn’t typecast a car.
I may be on the wrong side of history but I can’t see what other role a car could get in the film industry except vehicle.
What about typecasting to a car?
For our American friends: the Opel Corsa is a car.
Debatable.
Calling it a car may be an exaggeration
For the Brits, it’s a Vauxhall Corsa.
For everyone : it’s a sh’tbox (never again)
Does it also under-steer like crazy? (https://www.youtube.com/watch?v=2HhhWzrR3Wg)
A connoisseur. You have my upvote.
Ok now how do you cast the spell “float” on it
C when I cast a
char * *to achar * * const: okC when I cast a
char * *to achar * const *: okC when I cast a
char * *to achar const * *: WTFC when I cast a
char * *to achar const * const *: okThe WTF case isn’t allowed because it would allow modification of the const. From https://en.cppreference.com/w/cpp/language/implicit_conversion
int main() { const char c = ‘c’; char* pc; char** ppc = &pc; const char** pcc = ppc; // Error: not the same as cv-unqualified char**, no implicit conversion. *pcc = &c; *pc = ‘C’; // If the erroneous assignment above is allowed, the const object “c” may be modified. }
Please stop, I have CPTSD.
Do we need any more proof Python is superior?
(I’m ^joking, ^I ^love ^Rust)
And that’s why I don’t use Python for anything more than simple scripts
Look at mister “Sometimes I write programs that have more than a single niche function” over here
This is a post about growing disappointment with Python
You don’t even need to cast in Python, a reference is a reference.
If it’s loud, moving, can chase you and honks at you, then it’s
an obnoxious goosea car
Perl when I iterate over an object and treat the result as a hash reference: “fine, whatever. Fuck you, tho”
Just wait until you come across an XS library that uses a scalar reference for its objects (like LibXML).
Yeah this was a good one to wake up to.
as long as you can shift it
