1. 0

    So far I’ve only found one solution that is actually robust. Which is to manually check that the value is not nil before actually using it.

    This seems reasonable to me. If anything, I’d consider knowing how and when to use this kind of check a part of language competency knowledge as it is how Go was designed.

    1. 9

      We expect people to be competent enough to not crash their cars, but we still put seatbelts in.

      That’s perhaps a bad analogy, because most people would say that there are scenarios where you being involved in a car crash wasn’t your fault. (My former driver’s ed teacher would disagree, but that’s another post.) However, the point remains that mistakes happen, and can remain undiscovered for a disturbingly long period of time. Putting it all down to competence is counter to what we’ve learned about what happens with software projects, whether we want it to happen or not.

      1. 9

        I wish more languages had patterns. Haskell example:

        data Named = Named {Name :: Text} deriving Show
        
        greeting :: Maybe Named -> Text
        greeting (Just thing) = "Hello " + (Name thing)
        greeting _ = ""
        

        You still have to implement each pattern, but it’s so much easier, especially since the compiler will warn you when you miss one.

        1. 3

          Swift does this well with Optionals

          1. 5

            You can even use an optional type in C++. It’s been a part of the Boost library for a while and was added to the language itself in C++17.

            1. 4

              You can do anything in C++ but most libraries and people don’t. The point is to make these features integral.

              1. 1

                It’s in the standard library now so I think it’s integral.

                1. 4

                  If it’s not returned as a rule and not as an exception throughout the standard library it doesn’t matter though. C++, both the stdlib and the wider ecosystem, rely primarily on error handling outside of the type-system, as do many languages with even more integrated Maybe types

            2. 2

              Yep. Swift has nil, and by default no type can hold a nil. You have to annotate them with ? (or ! if you just don’t care, see below).

              var x: Int = nil // error
              var x: Int? = nil // ok
              

              It’s unwrapped with either if let or guard let

              if let unwrapped_x = x {
                  print("x is \(x)") 
              } else {
                  print("x was nil")
              }
              
              guard let unwrapped_x = x else {
                  print("x was nil")
                  return
              }
              

              Guard expects that you leave the surrounding block if the check fails.

              You can also force the unwraps with !.

              let x_str = "3"
              let x = Int(x_str)! // would crash at run-time if the conversion wouldn't succeed
              

              Then there’s implicit unwraps, which are pretty much like Java objects in the sense that if the object is nil when you try to use it, you get a run-time crash.

              let x: Int! = nil
              
          2. 7

            Hey, I’m the author of the post. And indeed that does work, which is why I’m doing that currently. However, like I try to explain further in the post this has quite some downsides. The main one is that it can be easily forgotten. The worst part of which is that if you did forget, you will likely find out only by a runtime panic. Which if you have some bad luck will occur in production. The point I try to make is that it would be nice to have this be a compile time failure.

            1. 1

              Sure, and that point came across. I think you’d agree that language shortcomings - and certainly this one - are generally excused (by the language itself) by what I mentioned?

          1. 2

            I own two of the motherboards mentioned (the second ASRock Rack one - actually, the variant with a C2750 CPU) and have suffered 100% failure rate. More, actually depending how you want to factor in the one that was DOA. FWIW, Intel had a defect in their C2000 series CPUs and my boards were manufactured during this time, but I don’t actually know what the failure cause was.

            ASRock has also failed to keep the Java-based IPKVM client up to date and signed in a way where Java is able to run it. I forget the specifics but for some time it was completely unusable due to applet signing issues.

            1. 5

              Funny to mention nested functions. GCC does allow them, and people passionately hate their existence because they require making the stack executable which is highly detrimental for security.

              1. 1

                Doesn’t this mention of feature vs security loop back to the author’s original point?

              1. 20

                I was in the middle of a long-winded comment, but I don’t have the time to point out all the problems. Quite simply, the article doesn’t make any sense. There is a term for this: it’s not even wrong.

                In order to be “wrong”, arguments have to be based in some sort of reality, but just reach the incorrect conclusion. None of the author’s arguments make any sense, so the article cannot be judged as being “right” or “wrong”, because it’s not based in reality.

                1. 7

                  I somewhat agree with this but maybe not for the same reasons. Many of the points ignore obvious reasons that are still valid today. Such as:

                  Regarding print statements:

                  Oh, wait a minute, this is still the only way we can get anything done in the world of programming!

                  But what about debuggers? Tcpdump-like tools? These are much better than debugging via printing.

                  Our ancestors bequeathed to us cd, ps, mkdir, chown, grep, awk, fsck, nroff, malloc, stdio, creat, ioctl, errno, EBADF, ESRCH, ENXIO, SIGSEGV, et al.

                  What technical field is not besieged by jargon with meaning not obvious to the unfamiliar? Likewise, all of these can be alised to more obvious terms, anything you desire, for only the cost of character space in your code or configs. So why don’t we see more of this? The author suggests it it because keyboards were physically painful to type on in the past.

                  You know what hurts? RSI. Silly point aside, the time savings are absolutely still relevant today.

                  The big problem with text-as-ASCII (or Unicode, or whatever) is that it only has structure for the humans who read it, not the computer.

                  Is this really a problem? Haven’t we solved inefficiencies relating to this with various types of preprocessing such as, well, code preprocessing? Not to mention compilation? Code aside, is the minimal overhead of parsing a config file when your daemon happens to restart that big? Maybe I’m being pedantic but aren’t scripting languages generally “slow” to execute yet quick to write, and the inverse for binary programs?

                  I feel that the author ignores obvious reasoning (obvious in that the alternative is, while not sugar-coated, certainly more modern than 70s Unix. This seems to fit every point in this article and, at the risk of ad hominem, paints a picture of a naive computer enthusiast.

                1. 15

                  I’m using 1Password with local sync over the built-in web server. 1Passwords also supports syncing via Dropbox, iCloud and, most recently, 1Passwords’s own servers. I want nothing of that but it means that I can’t use 1Password on Linux. What’s great about 1Password is that it is highly polished - using it adds very little friction. I understand that I could manage all passwords encrypted in Git but the integration would never be as good and there is a lot of risk that this would somehow not be as secure as it sounds.

                  1. 5

                    I recently switched to Enpass, which is a conceptual clone of 1Password. Reason for switching was Linux support.

                    1. 7

                      This is a closed-source app that has not yet received a lot of scrutiny. Using it for truly sensitive information requires quite a bit of trust. They claim to use sqlite with encryption – which I would trust but of course, there is a lot of code around it that would have to be trusted as well.

                      1. 2

                        The first thing it tried to do when I ran it was reach out to Google Analytics. I said enough of that, and promptly uninstalled it.

                      2. 2

                        1Password (at least the hosted version) has linux support via both 1password-x and 1password-cli. I quite enjoy the CLI and generally find that it has a better user experience than LastPass.

                    1. 1

                      HLS is a wonderful protocol, from both the client and server perspective. I’m sure ffmpeg supports this too, but I’ve had great luck with the seemingly lesser-known GStreamer project, which can export HLS chunks as well.