• HexesofVexes@lemmy.world
    link
    fedilink
    arrow-up
    19
    ·
    1 day ago

    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

  • Kushan@lemmy.world
    link
    fedilink
    English
    arrow-up
    108
    ·
    2 days ago

    Rust is completely correct to be a dick about it as well. Type safety is there for a reason.

    • frezik@midwest.social
      link
      fedilink
      arrow-up
      5
      arrow-down
      2
      ·
      1 day ago

      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_hash crate. 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 uuid crate, right? Except no. That crate doesn’t produce formats that the functions on the Salt struct will accept, like base64. So maybe the uuid_b64 crate 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 rand crate 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.

      • Kushan@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        15 hours ago

        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.

        • frezik@midwest.social
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          10 hours ago

          None of this has much to do with type safety at all. A dynamically typed language might have a Salt object that has a constructor that takes a base64 string. If its common uuid library doesn’t output base64, then you can’t use it directly.

          Nor does a specific uuid library matter much. It just needs to be able to output base64 strings, which is an uncommon uuid encoding, but it’s out there.

          Nor does type safety prevent providing a sensible default implementation.

          The crate uses phc strings, which store the salt together with the hashed password, so no, it can handle it all on its own.

          There was just no thought into how components work together.

          • BorgDrone@lemmy.one
            link
            fedilink
            arrow-up
            2
            ·
            3 hours ago

            Why even bother with things like strings for a salt? I would expect it to just take a byte array. Just create some random bytes and provide that.

            • frezik@midwest.social
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              1 hour ago

              Yeah, that’s my thinking, too. But the library only takes b64.

              Edit: also, if anything, this system reduces the benefit of strong typing. You can feed whatever string you want into it and the compiler will say it’s OK, even if it would fail at run time. If it were a Vec<u8>, then the compiler can check things. Especially if you do something to let the compiler enforce the length (if possible).

              Or hand over a UUID object directly. Yeah, it ties it to a specific library, but it’s either that or you’re not taking full advantage of strong typing.

              Or just have a sensible default implementation.

  • UnfortunateShort@lemmy.world
    link
    fedilink
    arrow-up
    40
    ·
    edit-2
    2 days ago

    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.

    • myxi@toast.ooo
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      8 hours ago

      Yeah I usually love Python but right now I’m working on a paid project where I need to deal with tasks that are critical to mostly work on first try. Now, if it would be a different matter if my code was just completely idiotic and still worked but Python doesn’t error even when there is obvious typo that any statically compiled language could’ve picked up on a breeze at compile time.

      I am scared to even implement a better logging system in my program because sometimes I forget to sanitize the arguments and my program fucking crashes at runtime because I added a new fucking logging statement.

      I so fucking wish I had static type checking right now. The libraries I am using doesn’t have types (via annotations) so unless I spend days fixing their shit, I will have to continue with these shitty runtime crashes for the shittiest small mistakes. I also can’t trust these annotations because even if they are “wrong” their code coul perfectly work fine and they could even ship the wrong types. I would have the burden of dealing with their shitty annotations if that happens.

    • rumba
      link
      fedilink
      English
      arrow-up
      3
      ·
      edit-2
      1 day ago

      It’s like learning Perl back in the day, then needing to learn use strict;

        • rumba
          link
          fedilink
          English
          arrow-up
          3
          ·
          1 day ago

          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.

  • mlg@lemmy.world
    link
    fedilink
    English
    arrow-up
    68
    ·
    2 days ago

    Hey at least it’s not JavaScript which is perpetually high on crack with Object object

  • Limonene@lemmy.world
    link
    fedilink
    arrow-up
    75
    ·
    2 days ago

    C when I cast a char * * to a char * * const: ok

    C when I cast a char * * to a char * const *: ok

    C when I cast a char * * to a char const * *: WTF

    C when I cast a char * * to a char const * const *: ok

    • Juice@midwest.social
      link
      fedilink
      arrow-up
      5
      ·
      1 day ago

      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

  • Moc@lemmy.world
    link
    fedilink
    arrow-up
    9
    ·
    2 days ago

    Do we need any more proof Python is superior?

    (I’m ^joking, ^I ^love ^Rust)

  • neidu3@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    12
    ·
    2 days ago

    Perl when I iterate over an object and treat the result as a hash reference: “fine, whatever. Fuck you, tho”

    • frezik@midwest.social
      link
      fedilink
      arrow-up
      1
      ·
      1 day ago

      Just wait until you come across an XS library that uses a scalar reference for its objects (like LibXML).