1. 23

  2. 12

    What a coincidence, just the other day I noticed this bug:

    ~/source/mpv-build$ cloc .
        9094 text files.
        8818 unique files.                                          
    Can't use an undefined value as an ARRAY reference at /usr/bin/cloc line 1498.

    Good to see a replacement in a language that automatically rules out such problems.

    Two days ago there was a heated discussion on static typing. The article made this claim:

    People keep claiming that is because of bad choices of language, but it’s mostly not and static typing will not even slightly help fix it.

    (Note: I’m getting a lot of people saying this is a strawman and that’s not what static typing advocates say. This post is in fact a response to several specific comments from specific people, but I didn’t want to name and shame. It’s not a strawman if the people I’m arguing against actually exist).

    I submit that the existence of this bug, and the fact that it wasn’t caught by cloc’s testsuite, is evidence enough that

    static typing will not even slightly help fix it.

    is false. Especially given that the author chose to emphasize “slightly” and put a disclaimer stating that they meant exactly that.

    1. 4

      One caveat, I’ve bitten the dust on Rust libs using .unwrap(), which is really not a good idea. Haskell community’s been sweeping up cases of unnecessary termination/bottom for awhile now and it’s been very much worth it.

      That said, definitely an improvement when something is written with the benefit of a type system.

      1. 9

        “unwrap is okay in applications, but terrible in libraries, and is really only okay in applications until you’ve got the basics down and want to switch to writing error handling code” is a pretty big meme in the Rust community at large. Of course, not every single person who writes Rust will pick up on this stuff, but most widely used libraries will follow this.

        1. 1

          unwrap is perfectly fine to use in libraries as an assert to catch logic errors and other bugs in the library’s code. It’s not appropriate to use in a library when dealing with “expected” runtime errors (like file not found or whatever).

          1. 1

            Yes, I agree. That run-on was already getting a bit long…. you worded it better than I did when I tried to squeeze that additional caveat in.

        2. 3

          Yeah, clippy has lints to check for uses of unwrap() on both Option and Result types, but they are set to be allowed by default. This is probably because people complained about the number of errors clippy was throwing for them, but part of me wishes the clippy team had kept them set to deny anyway.

          1. 4

            It’s because using unwrap is a perfectly sensible thing to do when the only way it can fail is if there’s a bug in your code.

            1. 1

              I agree. The concern is that programmers new to Rust will make libraries that use unwrap in inappropriate contexts. A lint is a good guard against that.

            2. 1

              part of me wishes the clippy team had kept then set to deny anyway

              Only part? Well I guess I’ll see y'all in 20 years when you figure out unnecessary implicit partiality sucks. Now I have to run strict-clippy on all my deps :\

              1. 2

                I’ve opened an issue for clippy to address this problem.

        3. 4

          Oh nice, I posted that I was polishing this up in the “what are you working on this week thread”. Really happy to see it pop up here on its own.