• ddh@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    207
    arrow-down
    13
    ·
    1 year ago

    As your future colleague wondering what the hell that variable is for, thanks Go.

    • Willem@kutsuya.dev
      link
      fedilink
      arrow-up
      69
      arrow-down
      1
      ·
      1 year ago

      I prefer for it to be just a warning so I can debug without trouble, the build system will just prevent me from completing the pull request with it (and any other warning).

    • Nioxic@lemmy.world
      link
      fedilink
      English
      arrow-up
      27
      arrow-down
      1
      ·
      1 year ago

      Isnt the syntax highlighting it as mever used?

      So why would they wonder?

      • Camilo@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        arrow-down
        3
        ·
        1 year ago

        If it is a pure value, I’d assume yes, but if it is tied to a side effect (E.g. write its value to a file), then it would be not used but still could break your app if removed.

        I’m not familiar with rust language specifically, but generally that’s what could happen

    • MJBrune@beehaw.org
      link
      fedilink
      English
      arrow-up
      27
      arrow-down
      2
      ·
      1 year ago

      A quick “find all references” will point out it’s not used and can be deleted if it accidentally gets checked in but ideally, you have systems in place to not let it get checked into the main branch in the first place.

    • ennemi [he/him]@hexbear.net
      link
      fedilink
      English
      arrow-up
      25
      arrow-down
      3
      ·
      edit-2
      1 year ago

      If only there was some way the compiler could detect unused variable declarations, and may be emit some sort of “warning”, which would be sort of like an “error”, but wouldn’t cause the build to fail, and could be treated as an error in CI pipelines

      • CoderKat@lemm.ee
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        2
        ·
        edit-2
        1 year ago

        Let’s not pretend people acknowledge warnings, though. It’s a popular meme that projects will have hundreds of warnings and that devs will ignore them all.

        There’s a perfectly valid use case for opinionated languages that don’t let you get away with that. It’s also similar to how go has gofmt to enforce a consistent formatting.

        Honestly, I’ve been using Go for years and this unused variable error rarely comes up. When it does, it’s trivial to resolve. But the error has saved me from bugs more often than it has wasted my time. Most commonly when you declare a new variable in a narrower scope when you intended to assign to the variable of the same name (since Go has separate declare vs assign operators).

        • ennemi [he/him]@hexbear.net
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          1
          ·
          edit-2
          1 year ago

          You can, if you want, opt into warnings causing your build to fail. This is commonly done in larger projects. If your merge requests builds with warnings, it does not get merged.

          In other words, it’s not a bad idea to want to flag unused variables and prevent them from ending up in source control. It’s a bad idea for the compiler to also pretend it’s a linter, and for this behaviour to be forced on, which ironically breaks the Unix philosophy principle of doing one thing and doing it well.

          Mind you, this is an extremely minor pain point, but frankly as with most Go design choices there is a better way to solve the problem.

      • iammike@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        Some people simply ignore warnings, that’s the main issue. Trust me, I saw this way too often.

        If you cannot compile it than you have to fix it, otherwise just mark unused variables as ‘not an error’ via _ = someunusedvar.

      • Serenity@lemmy.world
        link
        fedilink
        arrow-up
        7
        ·
        1 year ago

        My brain is too smooth to imagine a solution to this using monads. Mind sharing what you got with the class?

        • nick@campfyre.nickwebster.dev
          link
          fedilink
          arrow-up
          13
          arrow-down
          1
          ·
          edit-2
          1 year ago

          Having a Result[T, Err] monad that could represent either the data from a successful operation or an error. This can be generalised to the Either[A, B] monad too.

            • oessessnex@programming.dev
              link
              fedilink
              arrow-up
              11
              ·
              edit-2
              1 year ago

              Nope. Monads enable you to redefine how statements work.

              Let’s say you have a program and use an Error[T] data type which can either be Ok {Value: T} or Error:

              var a = new Ok {Value = 1};
              var b = foo();
              return new Ok {Value = (a + b)};
              

              Each statement has the following form:

              var a = expr;
              rest
              

              You first evaluate the “expr” part and bind/store the result in variable a, and evaluate the “rest” of the program.

              You could represent the same thing using an anonymous function you evaluate right away:

              (a => rest)(expr);
              

              In a normal statement you just pass the result of “expr” to the function directly. The monad allows you to redefine that part.

              You instead write:

              bind((a => rest), expr);
              

              Here “bind” redefines how the result of expr is passed to the anonymous function.

              If you implement bind as:

              B bind(Func[A, B] f, A result_expr) {
                 return f(result_expr);
              }
              

              Then you get normal statements.

              If you implement bind as:

              Error[B] bind(Func[A, Error[B]] f, Error[A] result_expr) {
                 switch (result_expr) {
                     case Ok { Value: var a}:
                         return f(a);
                     case Error:
                         return Error;
                 }
              }
              

              You get statements with error handling.

              So in an above example if the result of foo() is Error, the result of the statement is Error and the rest of the program is not evaluated. Otherwise, if the result of foo() is Ok {Value = 3}, you pass 3 to the rest of the program and you get a final result Ok {Value = 4}.

              So the whole idea is that you hide the if Error part by redefining how the statements are interpreted.

            • barsoap@lemm.ee
              link
              fedilink
              arrow-up
              4
              ·
              edit-2
              1 year ago

              “Some generic class” with specific methods and laws, Monads are an algebraic structure and you want those laws included same as if you enable some type to use + you want to have a 0 somewhere and x + 0 == x to hold. Like "foo" + "" == "foo" in the case of strings, just as an example.

              In Rust, Result and Option actually are monads. Let’s take Option as example:

              • pure x is Some(x)
              • a >>= b is a.and_then(b)

              Then we have:

              • Left identity: Some(x).and_then(f)f(x)
              • Right identity: x.and_then(Some)x
              • Associativity: m.and_then(g).and_then(h)m.and_then(|x| g(x).and_then(h))

              Why those laws? Because following them avoids surprises like x + 0 /= x.

              Rust’s type system isn’t powerful enough to have a Monad trait (lack of HKTs) hence why you can’t write code that works with any type that implements that kind of interface. Result names >>= and_then, just like Option does so the code reads the same but you’ll have to choose between Option or Result in the type signature, the code can’t be properly generic over it.

        • psilocybin@discuss.tchncs.de
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          1 year ago

          Someone else and not an expert. But Maybe types are implemented with Monads, Maybe is a common monad.

          Its how rust does error handling for example, you have to test a return value for “something or nothing” but you can pass the monadic value and handle the error later, in go you have to handle the error explicitly (almost) all the time.

        • Nevoic@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 year ago

          Here’s an example (first in Haskell then in Go), lets say you have some types/functions:

          • type Possible a = Either String a
          • data User = User { name :: String, age :: Int }
          • validateName :: String -> Possible String
          • validateAge :: Int -> Possible Int

          then you can make

          mkValidUser :: String -> Int -> Possible User
          mkValidUser name age = do
            validatedName ← validateName name
            validatedAge  ← validateAge age
            pure $ User validatedName validatedAge
          

          for some reason <- in lemmy shows up as &lt;- inside code blocks, so I used the left arrow unicode in the above instead

          in Go you’d have these

          • (no Possible type alias, Go can’t do generic type aliases yet, there’s an open issue for it)
          • type User struct { Name string; Age int }
          • func validateName(name string) (string, error)
          • func validateAge(age int) (int, error)

          and with them you’d make:

          func mkValidUser(name string, age int) (*User, error) {
            validatedName, err = validateName(name)
            if err != nil {
              return nil, err
            }
          
            validatedAge, err = validateAge(age)
            if err != nil {
              return nil, err
            }
          
            return User(Name: validatedName, Age: validatedAge), nil
          }
          

          In the Haskell, the fact that Either is a monad is saving you from a lot of boilerplate. You don’t have to explicitly handle the Left/error case, if any of the Eithers end up being a Left value then it’ll correctly “short-circuit” and the function will evaluate to that Left value.

          Without using the fact that it’s a functor/monad (e.g you have no access to fmap/>>=/do syntax), you’d end up with code that has a similar amount of boilerplate to the Go code (notice we have to handle each Left case now):

          mkValidUser :: String -> Int -> Possible User
          mkValidUser name age =
            case (validatedName name, validateAge age) of
              (Left nameErr, _) => Left nameErr
              (_, Left ageErr)  => Left ageErr
              (Right validatedName, Right validatedAge) => 
                Right $ User validatedName validatedAge
          
    • arc@lemm.ee
      link
      fedilink
      arrow-up
      24
      arrow-down
      4
      ·
      1 year ago

      Swift and Rust have a far more elegant solution. Swift has a pseudo throw / try-catch, while Rust has a Result<> and if you want to throw it up the chain you can use a ? notation instead of cluttering the code with error checking.

      • barsoap@lemm.ee
        link
        fedilink
        arrow-up
        7
        arrow-down
        1
        ·
        1 year ago

        The exception handling question mark, spelled ? and abbreviated and pronounced eh?, is a half-arsed copy of monadic error handling. Rust devs really wanted the syntax without introducing HKTs, and admittedly you can’t do foo()?.bar()?.baz()? in Haskell so it’s only theoretical purity which is half-arsed, not ergonomics.

        • m_f
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          It’s not a half-arsed copy, it’s borrowing a limited subset of HKT for a language with very different goals. Haskell can afford a lot of luxuries that Rust can’t.

          • barsoap@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            It’s a specialised syntax transformation that has nothing to do with HKTs, or the type system in general. Also HKTs aren’t off the table it’s just that their theory isn’t exactly trivial in face of the rest of Rust’s type system but we already have GATs.

            It actually wouldn’t be hard writing a macro implementing do-notation that desugars to and_then calls on a particular type to get some kind of generic code (though of course monomorphised), but of course that would be circumventing the type system.

            Anyhow my point stands that how Rust currently does it is imitating all that Haskell goodness on a practical everyday coding level but without having (yet) to solve the hard problem of how to do it without special-cased syntax sugar. With proper monads we e.g. wouldn’t need to have separate syntax for async and ?

        • Nevoic@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          Note: Lemmy code blocks don’t play nice with some symbols, specifically < and & in the following code examples

          This isn’t a language level issue really though, Haskell can be equally ergonomic.

          The weird thing about ?. is that it’s actually overloaded, it can mean:

          • call a function on A? that returns B?
          • call a function on A? that returns B

          you’d end up with B? in either case

          Say you have these functions

          toInt :: String -> Maybe Int
          
          double :: Int -> Int
          
          isValid :: Int -> Maybe Int
          

          and you want to construct the following using these 3 functions

          fn :: Maybe String -> Maybe Int
          

          in a Rust-type syntax, you’d call

          str?.toInt()?.double()?.isValid()
          

          in Haskell you’d have two different operators here

          str >>= toInt &lt;&amp;> double >>= isValid
          

          however you can define this type class

          class Chainable f a b fb where
              (?.) :: f a -> (a -> fb) -> f b
          
          instance Functor f => Chainable f a b b where
              (?.) = (&lt;&amp;>)
          
          instance Monad m => Chainable m a b (m b) where
              (?.) = (>>=)
          

          and then get roughly the same syntax as rust without introducing a new language feature

          str ?. toInt ?. double ?. isValid
          

          though this is more general than just Maybes (it works with any functor/monad), and maybe you wouldn’t want it to be. In that case you’d do this

          class Chainable a b fb where
              (?.) :: Maybe a -> (a -> fb) -> Maybe b
          
          instance Chainable a b b where
              (?.) = (&lt;&amp;>)
          
          instance Chainable a b (Maybe b) where
              (?.) = (>>=)
          

          restricting it to only maybes could also theoretically help type inference.

          • barsoap@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            I was thinking along the lines of “you can’t easily get at the wrapped type”. To get at b instead of Maybe b you need to either use do-notation or lambdas (which do-notation is supposed to eliminate because they’re awkward in a monadic context) whereas Rust will gladly hand you that b in the middle of an expression, and doesn’t force you to name the point.

            Or to give a concrete example, if foo()? {...} is rather awkward in Haskell, you end up writing things like

            foo x y = bar >>= baz x y
              where
                baz x y True = x
                baz x y False = y
            

            , though of course baz is completely generic and can be factored out. I think I called it “cap” in my Haskell days, for “consequent-alternative-predicate”.

            Flattening Functors and Monads syntax-wise is neat but it’s not getting you all the way. But it’s the Haskell way: Instead of macros, use tons upon tons of trivial functions :)

        • arc@lemm.ee
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          You can say it’s half-arsed if you like, but it’s still vastly more convenient to write than if err != nil all over the place

      • fkn@lemmy.world
        link
        fedilink
        arrow-up
        19
        arrow-down
        5
        ·
        1 year ago

        Exceptions don’t exists and ask errors must be handled at every level. It’s infuriating.

        • planish@sh.itjust.works
          link
          fedilink
          arrow-up
          5
          arrow-down
          1
          ·
          1 year ago

          I actually kind of like the error handling. Code should explain why something was a problem, not just where it was a problem. You get a huge string of “couldn’t foobar the baz: target baz was not greebleable: no greeble provider named fizzbuzz”, and while the strings are long as hell they are much better explanations for a problem than a stack trace is.

          • GlitchSir@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            I think you missed a memo. Exceptions are bad and errors as values are in… I’ll have Harold forward it to you

      • ennemi [he/him]@hexbear.net
        link
        fedilink
        English
        arrow-up
        12
        arrow-down
        1
        ·
        edit-2
        1 year ago

        The language was designed to be as simple as possible, as to not confuse the developers at Google. I know this sounds like something I made up in bad faith, but it’s really not.

        The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike

        "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike

        The infamous if err != nil blocks are a consequence of building the language around tuples (as opposed to, say, sum types like in Rust) and treating errors as values like in C. Rob Pike attempts to explain why it’s not a big deal here.

      • silent_water [she/her]@hexbear.net
        link
        fedilink
        English
        arrow-up
        8
        arrow-down
        2
        ·
        1 year ago

        a desperate fear of modular code that provides sound and safe abstractions over common patterns. that the language failed to learn from Java and was eventually forced to add generics anyway - a lesson from 2004 - says everything worth saying about the language.

  • HiddenLayer5@lemmy.ml
    link
    fedilink
    English
    arrow-up
    84
    arrow-down
    2
    ·
    edit-2
    1 year ago

    Sometimes I think Go was specifically made for Google to dictate its own preferences on the rest of us like some kind of power play. It enforces one single style of programming too much.

    • space_comrade [he/him]@hexbear.net
      link
      fedilink
      English
      arrow-up
      20
      ·
      1 year ago

      From what I’ve heard from Google employees Google is really stringent with their coding standards and they usually limit what you can do with the language. Like for C++ they don’t even use half the fancy features C++ offers you because it’s hard to reason about them.

      I guess that policy makes sense but I feel like it takes out all the fun out of the job.

      • frezik
        link
        fedilink
        arrow-up
        18
        ·
        1 year ago

        As far as C++ goes, that’s probably the only sane way to use the language.

      • Sloogs@lemmy.dbzer0.com
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        1 year ago

        Just about any place I know that uses C++ also does that with C++ so that’s nothing unusual for C++ specifically. It’s too big of a language to reason about very well if you don’t, so you’ve gotta find a subset that works.

        • skeletorsass [she/her]@hexbear.net
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          Too many patterns. If you do not do this every author will have a different use of the language and you will have to read a book of documentation each time you change files.

    • philm@programming.dev
      link
      fedilink
      arrow-up
      18
      ·
      1 year ago

      Is this a hard error? Like it doesn’t compile at all?

      Isn’t there something like #[allow(unused)] in Rust you can put over the declaration?

      • flame3244@lemmy.world
        link
        fedilink
        arrow-up
        27
        ·
        1 year ago

        Yes it is a hard error and Go does not compile then. You can do _ = foobar to fake variable usage. I think this is okay for testing purposes.

          • flame3244@lemmy.world
            link
            fedilink
            arrow-up
            2
            arrow-down
            1
            ·
            1 year ago

            Worse than not having a unused variable check at all? Dunno, the underscore assignment are very visible for me and stand out on every code read and review.

            • AeonFelis@lemmy.world
              link
              fedilink
              arrow-up
              13
              arrow-down
              2
              ·
              edit-2
              1 year ago

              Yes, worse, because now if you want to use the underscore assignment to indicate that you really want to discard that variable - it gets confused with underscore assignments that were put there “temporarily” for experimentation purpose.

              • merc@sh.itjust.works
                link
                fedilink
                arrow-up
                9
                ·
                1 year ago

                Exactly.

                Say I’m having some issue with a function. I comment out half the function to see if that’s where the weirdness is. Golang says “unused variable, I refuse to compile this dogshit!” I completely fool Golang by just using _ = foo. Yes, I was correct, that’s where the problem was. I rewrite that section of the code, and test it out, things work perfectly. Only now, it turns out I’m not using foo anymore, and Golang has no idea because I so cleverly fooled it with _ = foo.

                Now, something that could be caught by a linter and expressed as a warning is missed by the language police entirely, and may make it into production code.

                Police the code that people put into a repository / share with others. Don’t police the code that people just want to test on their own.

        • nomadjoanne@lemmy.world
          link
          fedilink
          arrow-up
          8
          ·
          1 year ago

          Ew, that’s awful. Go is not one of my programming languages but I had always held it in high esteem because Ken Thompson and Rob Pike were involved in it.

          • merc@sh.itjust.works
            link
            fedilink
            arrow-up
            6
            arrow-down
            1
            ·
            1 year ago

            That’s the main reason it has had any success. It’s not that it’s a good language, it’s just that it has good references.

          • flame3244@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Honestly, it does not happen often that I have a ln unused variable that I want to keep. In my mind it is the same thing when wanting to call a function that does not exists. Also my editor is highlighting error Long before I try to compile, so this is fine too for me.

        • AstridWipenaugh@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          edit-2
          1 year ago

          The underscore is used in production code too. It’s a legitimate way to tell the compiler to discard the object because you don’t intend to use the pointer/value.

      • HiddenLayer5@lemmy.ml
        link
        fedilink
        English
        arrow-up
        12
        ·
        edit-2
        1 year ago

        Never really coded in Go outside of trying it out, but as far as I know it’s a hard error.

    • flame3244@lemmy.world
      link
      fedilink
      arrow-up
      8
      ·
      1 year ago

      I think this is a good thing. The styles are just opinions anyway and forcing everyone to just follow a single style takes a lot of bikeshedding away, which I really like.

  • CodeBlooded@programming.dev
    link
    fedilink
    arrow-up
    107
    arrow-down
    57
    ·
    edit-2
    1 year ago

    If this language feature is annoying to you, you are the problem. You 👏are 👏 the 👏 reason 👏 it 👏 exists.

    I worked in places where the developers loaded their code full of unused variables and dead code. It costs a lot of time reasoning about it during pull request and it costs a lot of time arguing with coworkers who swear that they’re going to need that code in there next week (they never need that code).

    This is a very attractive feature for a programming language in my opinion.

    PS: I’m still denying your pull request if you try to comment the code instead.

    ❗️EDIT: A lot of y’all have never been to programming hell and it shows. 🪖 I’m telling you, I’ve fixed bayonets in the trenches of dynamically typed Python, I’ve braved the rice paddies of CICD YAML mines, I’ve queried alongside SQL Team Six; I’ve seen things in production, things you’ll probably never see… things you should never see. It’s easy to be against an opinionated compiler having such a feature, but when you watch a prod deployment blow up on a Friday afternoon without an easy option to rollback AND hours later you find the bug after you were stalled by dead code, it changes you. Then… then you start to appreciate opinionated features like this one. 🫡

    • m_f
      link
      fedilink
      arrow-up
      87
      arrow-down
      4
      ·
      1 year ago

      That’s 👏 what 👏 CI 👏 is 👏 for

      Warn in dev, enforce stuff like this in CI and block PRs that don’t pass. Go is just being silly here, which is not surprising given that Rob Pike said

      Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods. I grew up and today I use monochromatic numerals.

      The Go developers need to get over themselves.

      • merc@sh.itjust.works
        link
        fedilink
        arrow-up
        20
        arrow-down
        1
        ·
        1 year ago

        Yeah, insisting on things like a variable being used will result in people using work arounds. It won’t result in people not doing it.

        Then, because people trust the language to police this rule, the work-arounds and debug code will get committed.

        func main() {  
            test := true  
        }  
        

        Oops, golang doesn’t like that.

        func main() {  
            test := true  
            _ = test  
        }
        

        Perfectly cromulent code.

        If they really wanted to avoid people having unused variables, they should have used a naming convention. Any variable not prefixed by “_” or “_debug_” or whatever has to be used, for example. Then block any code being checked in that still contains those markers.

      • WhyEssEff [she/her]@hexbear.net
        link
        fedilink
        English
        arrow-up
        18
        ·
        1 year ago

        reading my code after being up for 18 hours and having my eyes glaze over trying to parse the structure of my monochromatic code but then I remember Rob Pike said syntax highlighting is juvenile so I throw my head against that wall for another 3 hours

        • WhyEssEff [she/her]@hexbear.net
          link
          fedilink
          English
          arrow-up
          18
          ·
          edit-2
          1 year ago

          Prescription glasses are juvenile. When I was a child, I was prescribed visual aid to help my nearsightedness. I grew up and today I raw-dog the road.

      • spookedbyroaches@lemm.ee
        link
        fedilink
        arrow-up
        7
        ·
        1 year ago

        I agree that golang is being dumb when you don’t even have the option to tell it that this is a testing env or something. But the thing about syntax highlighting is not the same. One is about handholding the developer so much that it makes it even more difficult to develop, and the other is a completely optional feature that is so uselful and non intrusive that even wizardly editors like emacs use it.

      • FlumPHP@programming.dev
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        1 year ago

        What’s a situation where you need an unused variable? I’m onboard with go and goland being a bit aggressive with this type of thing, but I can’t think of the case where I need to be able to commit an unused variable.

        • m_f
          link
          fedilink
          arrow-up
          20
          arrow-down
          2
          ·
          1 year ago

          You probably wouldn’t be committing this, unless you’re backing up a heavily WIP branch. The issue is that if you’re developing locally and need to make a temporary change, you might comment something out, which then requires commenting another now-unused variable, which then requires commenting out yet another variable, and so on. Go isn’t helping you here, it’s wasting your time for no good reason. Just emit a warning and allow CI to be configured to reject warnings.

        • hare_ware@pawb.social
          link
          fedilink
          arrow-up
          10
          arrow-down
          1
          ·
          1 year ago

          I will need it two minutes tops. If I don’t use it by then, I’ll delete it, especially if it gives a warning like Rust does. But this? It just gets in the way.

        • jormaig@programming.dev
          link
          fedilink
          arrow-up
          8
          ·
          1 year ago

          Have you looked at the post? Use case: you are testing something or playing around and you want to try something. That’s supper common

        • ggppjj@lemmy.world
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          I have a use case in Powershell: my company has a number of scripts that are minimally but importantly customized per-location, and I have an otherwise unused “SiteId” variable where I keep the location name for that specific script for a quick sanity check when I’m looking them over for any reason. Not necessary, but useful to me. Probably wouldn’t do the same thing in a compiled program, but I can at least see where someone might want something similar.

    • Urik@lemmy.ca
      link
      fedilink
      arrow-up
      60
      arrow-down
      1
      ·
      edit-2
      1 year ago

      That’s a problem with your workplace, not the language nor OP.
      You could have a build setting for personal development where unused variables are not checked, and then a build setting for your CI system that will look for them. It gives you freedom to develop the way you want without being annoyed when you remove something just to test something, but will not merge your PR unless the stricter rules are met.

      • CodeBlooded@programming.dev
        link
        fedilink
        arrow-up
        6
        arrow-down
        3
        ·
        1 year ago

        I concur, it is a problem with that workplace. (In this case, OP is just sharing a funny meme. I wouldn’t suggest this meme means they’re a problem. I could have made this meme and I love the feature.)

        Developing on a team at a company is like the “Wild West.” What’s considered to be acceptable will not only vary from workplace to workplace, but it can also fluctuate as developers and managers come and Go. Each of them have their own unique personality with their own outlook on what “quality” code looks like. (And many of them do not care about code quality whatsoever. They just need to survive 1-2 years there, make management happy with speedy deliveries, and then they can move on to the next company with a 30% pay bump.)

        Having experienced working with developers who frequently filled with code base with unused code while having no control over who will leave or join as a contributor to the code base, I think features like this make for a more sane development experience when you’re developing with a team of seemingly random people that you never personally invited to contribute to the code base.

        will not merge your PR unless the stricter rules are met.

        This doesn’t fly when you work in big corporate and the boss doesn’t care about the code meeting stricter rules. “A working prototype? No it’s not- that’s an MVP! Deploy it to production now and move onto the next project!

      • LittleLordLimerick@lemm.ee
        link
        fedilink
        arrow-up
        5
        arrow-down
        11
        ·
        1 year ago

        Why in the world would you want to develop something that doesn’t follow the coding rules required by your org, just so you can go back and fix everything before submitting a PR? That’s just extra work.

        • planish@sh.itjust.works
          link
          fedilink
          arrow-up
          6
          arrow-down
          1
          ·
          1 year ago

          Because you want to know if the first half of the code works at all before you write the whole second half.

          Finding all the bits that will be used by the second half and changing the declarations to just expressions is a bunch of extra work. As is adding placeholder code to use the declared variables.

          • LittleLordLimerick@lemm.ee
            link
            fedilink
            arrow-up
            4
            arrow-down
            4
            ·
            1 year ago

            I’m having a hard time envisioning a situation where testing my code requires a bunch of unused variables. Just don’t declare the variables until you’ve started writing the code that uses them…

            • Urik@lemmy.ca
              link
              fedilink
              arrow-up
              3
              ·
              1 year ago

              Most of the time you don’t write the code, you change it.

              I had tons of situations where I wanted to test deleting a code block which just happened to use an imported library, which the compiler is now complaining about because it’s no longer being used.

              • LittleLordLimerick@lemm.ee
                link
                fedilink
                arrow-up
                1
                ·
                1 year ago

                If that’s the problem, then I would just use something like goimports to auto fix the imports every time I hit save. I never even see those errors so they don’t bother me.

    • AeonFelis@lemmy.world
      link
      fedilink
      arrow-up
      31
      arrow-down
      1
      ·
      1 year ago

      That’s what warnings are for. The jokes about programmers ignoring warnings are outdated - we live in an age where CIs run linters and style checkers on pull requests, there is no reason for a CI to not automatically reject code that builds with warnings.

    • pixeltree@lemmy.world
      link
      fedilink
      arrow-up
      24
      ·
      1 year ago

      I mean, yeah that kind of stuff absolutely should not be in production. However, it’s easy to see how it could be annoying while testing something while working on it. It being annoying doesn’t make it a bad feature, just as finding it annoying doesn’t make you a problem imo.

      • redcalcium@lemmy.institute
        link
        fedilink
        arrow-up
        8
        arrow-down
        1
        ·
        1 year ago

        It is VERY annoying when you’re hunting for a bug. For example, when you comment out a function call to debug an issue, the compiler might suddenly complains about unused variables, so you’ll need to comment them out as well. Repeat several times and you’ll start having an urge to smack the monitor.

    • redcalcium@lemmy.institute
      link
      fedilink
      arrow-up
      17
      arrow-down
      1
      ·
      1 year ago

      It costs a lot of time reasoning about it during pull request and it costs a lot of time arguing with coworkers who swear that they’re going to need that code in there next week (they never need that code).

      You should go to your team leader and ask them to enforce a coding standard. I agree with other commenters that said this should be a warning instead of an error.

    • fibojoly@sh.itjust.works
      link
      fedilink
      arrow-up
      11
      ·
      1 year ago

      I was working for a team that did quality control on the code of an entire financial group and it’s still amazing to me the shit we let through.
      I feel annoyed even having compiler warnings in my code and here we were downgrading errors into warnings so the code would go through, or adding rules exceptions for a program so the team responsible could push a hotfix to prod… It’s all shit. All the way down.

      I dream of working with such a strict language.

  • fkn@lemmy.world
    link
    fedilink
    arrow-up
    63
    arrow-down
    14
    ·
    1 year ago

    Also Go: exceptions aren’t real, you declare and handle every error at every level or declare that you might return that error because go fuck yourself.

      • fkn@lemmy.world
        link
        fedilink
        arrow-up
        39
        arrow-down
        6
        ·
        1 year ago

        Wow. I’m honestly surprised I’m getting downvotes for a joke. Also, no. It isn’t. It really isn’t.

        • gornius@lemmy.world
          link
          fedilink
          arrow-up
          3
          arrow-down
          1
          ·
          1 year ago

          It is better than in most languages with exceptions, except from languages like Java, that require you to declare that certain method throws certain error.

          It’s more tedious in Go, but at the end of the day it’s the same thing.

          When I use someone else’s code I want to be sure if that thing can throw an error so I can decide what to do with it.

          • fkn@lemmy.world
            link
            fedilink
            arrow-up
            4
            arrow-down
            1
            ·
            edit-2
            1 year ago

            Java doesn’t have to declare every error at every level… Go is significantly more tedious and verbose than any other common language (for errors). I found it leads to less specific errors and errors handled at weird levels in the stack.

      • r1veRRR@feddit.de
        link
        fedilink
        arrow-up
        21
        arrow-down
        1
        ·
        1 year ago

        It’s better than “invisible” exceptions, but it’s still the worst “better” version. The best solution is some version of the good old Result monad. Rust has the BEST error handling (at least in the languages i know). You must handle Errors, BUT they are just values, AND there’s a easy, non-verbose way of passing on the error (the ? operator).

        • theneverfox@pawb.social
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          Beyond a quick “hello world” when it came out, I’ve never used rust, but that sounds pretty great

      • herrvogel@lemmy.world
        link
        fedilink
        arrow-up
        2
        arrow-down
        4
        ·
        1 year ago

        There’s nothing sane and readable about how Go insists you format dates and time. It is one of the dumbest language features I’ve ever seen.

      • Nato Boram@lemm.ee
        link
        fedilink
        English
        arrow-up
        5
        ·
        1 year ago

        “Other people” are what’s wrong with me. People don’t use linters/formatters/type annotations when it’s optional and produce dogshite code as a result. Having the compiler itself enforce some level of human decency is a godsend.

  • ytrav@lemmy.world
    link
    fedilink
    arrow-up
    33
    arrow-down
    3
    ·
    1 year ago

    lints that underline unused vars as errors, and not notes or warns are the worst lints…

  • jeanma@lemmy.ninja
    link
    fedilink
    English
    arrow-up
    25
    arrow-down
    1
    ·
    1 year ago

    OP never said he/she commits such code but wants to iterate, test, explore.

    Of course, unused var should not be part of a commit.

  • fauxerious@lemmy.world
    link
    fedilink
    arrow-up
    18
    ·
    1 year ago

    you can assign it to itself and it’ll be just fine. can’t put a breakpoint right on it, but it works

  • Rednax@lemmy.world
    link
    fedilink
    arrow-up
    14
    ·
    1 year ago

    I hate this in C++ when it does this with parameters of an overidden function. I don’t need that specific parameter, but if I omit the variable name, I reduce readability.

  • Crashumbc@lemmy.world
    link
    fedilink
    arrow-up
    13
    ·
    1 year ago

    The best part of these threads is no matter what someone comments, at least 2 people will reply either correcting or “clarifying” the original commenter.

    Lol