nickwitha_k (he/him)

  • 4 Posts
  • 203 Comments
Joined 1 year ago
cake
Cake day: July 16th, 2023

help-circle


  • So what it’s really like is only having to do half the work?

    If it’s automating the interesting problem solving side of things and leaving just debugging code that one isn’t familiar with, I really don’t see value to humanity in such use cases. That’s really just making debugging more time consuming and removing the majority of fulfilling work in development (in ways that are likely harder to maintain and may be subject to future legal action for license violations). Better to let it do things that it actually does well and keep engaged programmers.




  • I just wanted to offer some nuance to the table. After everything has been learned, enabling some (otherwise complex and obscure) features can be accomplished by a single line in your NixOS config. Like, this efficiency can not and should not be ignored.

    I really appreciate it. I really WANT to like NixOS. The level of efficiency and portability (ex. Nix as package manager) is incredible and, I think, well worth learning about both for users and distros - I hope we see the ideas propagate further. It’s just not in a place that I can be happy using it. But, it is going to tickle some people the right way and that is something that makes me happy.

    Fedora Atomic does deliver on those without requiring you to go into the deep and learn an entire new language that’s only used for managing your distro 😅.

    This right here is why I’m liking it so far. I’m like Alton Brown is to cooking gadgets when it comes to languages in computing, I really don’t like unitaskers. I get unreasonably resentful of software that forces me to use a DSL (this is a “me” problem).


  • Does it require you to climb through heaps of trash documentation? Absolutely.

    That’s why I think the previous commenter’s statement rings true. I’ve been using Linux exclusively for over a decade across multiple distros. NixOS is not intuitive for new or seasoned users, making good documentation vital.

    An example: I spent a good weekend day or so poking at NixOS. Live boot worked as expected. When I finished, I had a bootable system but no network stack, despite following the docs. This means that my only route forward would be going back to the live boot since there was no way to pull packages in that state.

    I decided to go with Fedora Silverblue as my next test. After dding the image to my USB, it took about 10 mins to get up and running. I was able to setup libvirt and other similar software quick and easy. And once I’m happy, I can write my config to a repo and have my base system wherever, whenever.










  • Kinda. nil is a weird value in Go, not quite the same as null or None in JS and Python, respectively. A nil value may or may not be typed and it may or may not be comparable to similar or different types. There is logical consistency to where these scenarios can be hit but it is pretty convoluted and much safer, with fewer footguns to check for nil values before comparison.

    I’m other words, in Go (nil == nil) || (nil != nil), depending on the underlaying types. One can always check if a variable has a nil value but may not be able to compare variables if one or more have a nil value. Therefore, it is best to first check for nil values to protect against errors that failure to execute comparisons might cause (anything from incorrect outcome to panic).

    ETA: Here’s some examples

    // this is always possible for a variable that may have a nil value. 
    a != nil || a == nil
    
    a = nil
    b = nil
    // This may or may not be valid, depending on the underlying types.
    a != b || a == b
    
    // Better practice for safety is to check for nil first
    if a != nil && b != nil {
        if a == b {
            fmt.Println("equal")
        } else {
            fmt.Println("not equal")
        }
    } else {
        fmt.Println("a and/or b is nil and may not be comparable")
    }
    




  • IIRC, a nil value can be checked against a literal successfully but not against another nil value. Say you want to check for equality of two vars that could be nil. You just need an extra if statement to ensure that you are not trying to compare nil and nil or nil and a non-nil value (that’ll give you a type error or NPE):

    var a *string
    var b *string
    
    ...
    if a != nil && b != nil {
      if a == b {
        fmt.Println("Party!")
      } else {
        fmt.Println("Also Party!")
    }