Announcement

Collapse
No announcement yet.

Go 1.18 Released With Generics, Fully Integrated Fuzzing, ~20% Performance Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by andrebrait View Post
    bug77 it's still a mich less elegant solution than exceptions, even if exceptions have their issues. And sure, very trivial code is mostly fine, but put together a couple of these functions and suddenly your code will become anything but clean.
    So, a case of grass being greener on the other side?

    Comment


    • #12
      Originally posted by bug77 View Post
      So, a case of grass being greener on the other side?
      What do you mean? I only ever wrote one service n Go, and occasionally interact with it trying to find out what went wrong on Minikube.

      Nowadays I do Java 90% of the time, followed by Python and C. I only mentioned exceptions are not perfect because nothing really is, but it's by far a lot better than Go's ad nauseum if else for anything that isn't trivial.

      Comment


      • #13
        Originally posted by Ironmask View Post
        Did they fix their horrifically broken package management and public naming scheme yet?

        There's a reason Discord of all companies replaced all their Go code with a far better language.
        Yeah, I like Go far better than Rust, but Go's package management and naming is.. a complicated mess. Also, it doesn't even have an easy self update mechanism like "rustup update".

        And yeah, Go's if/else mandatory usage is archaic.

        Comment


        • #14
          I'd say their "if error" handling was intentional to keep things simple and make error handling explicit. I hated it at start, but I must admit that for web service development, it does make coding a bit less error prone.

          Comment


          • #15
            Originally posted by andrebrait View Post

            What do you mean? I only ever wrote one service n Go, and occasionally interact with it trying to find out what went wrong on Minikube.

            Nowadays I do Java 90% of the time, followed by Python and C. I only mentioned exceptions are not perfect because nothing really is, but it's by far a lot better than Go's ad nauseum if else for anything that isn't trivial.
            I would say: veto (my opinion, obviously). I have been bitten far more often by exceptions than by Go's error handling. Missing to handle an error in Go is practically nonexistant. Missing to catch an exception in Java on the other hand happens all the fucking time. "Oh hey, one of the underlying libraries suddenly doesn't just throw an IOException, but sometimes now also some IFuckedUpBadly runtime exception."

            Of course I can try...catch on the outer-most layer, but then actually dealing with the error is ugly (since I don't know for sure at which point of the code it happened). If I want it more precise, I now have to wrap _every_ function call in try...catch. Which is much more ugly than checking the return value of a simple function as in Go.

            Comment


            • #16
              Originally posted by LubosD View Post
              I'd say their "if error" handling was intentional to keep things simple and make error handling explicit. I hated it at start, but I must admit that for web service development, it does make coding a bit less error prone.
              I'd say that this way of handling error is the opposite of being explicit and very error prone.

              it IS error prone because one can simply "forget" checking errors and this is exactly because errors are NOT explicit.
              In Java (for instance) errors are explicit and the compiler will force you to handle them.

              that said, I love both Go and Java

              Comment


              • #17
                Originally posted by cynic View Post
                In Java (for instance) errors are explicit and the compiler will force you to handle them.
                Only checked exceptions. Not every exception is checked.

                Comment


                • #18
                  Originally posted by aksdb View Post

                  Only checked exceptions. Not every exception is checked.
                  that is for a precise design principle.
                  Unchecked exceptions are for errors you can do anything to recover from.

                  Comment


                  • #19
                    Originally posted by aksdb View Post

                    I would say: veto (my opinion, obviously). I have been bitten far more often by exceptions than by Go's error handling. Missing to handle an error in Go is practically nonexistant. Missing to catch an exception in Java on the other hand happens all the fucking time. "Oh hey, one of the underlying libraries suddenly doesn't just throw an IOException, but sometimes now also some IFuckedUpBadly runtime exception."

                    Of course I can try...catch on the outer-most layer, but then actually dealing with the error is ugly (since I don't know for sure at which point of the code it happened). If I want it more precise, I now have to wrap _every_ function call in try...catch. Which is much more ugly than checking the return value of a simple function as in Go.
                    Go's approach is like if every exception was a checked Exception in Java and every method has to be enclosed in a one line try-catch block, even if the exception is ignored.

                    I do agree it's not perfect, but it's far better for me to have readable, easily parseable code than to have 100% certainty of errors being handled in a mess of if-else blocks, just like I could be enclosing every methof call in a try-catch, but I don't. Except in Go that's not an option if I ever want to handle errors. It makes writing any form of clean code simply impossible because I always have to check if I got an error.

                    Something as simple as "get the user from database, apply this transformation and respond to the request" and letting an exception handler handle it becomes "get the user from the database, if we got an error respond with 500, or else apply this transformation, if we got an error, respond with 500, then finally return it". And it gets worse the more complex it gets.

                    Comment


                    • #20
                      Originally posted by aksdb View Post

                      Only checked exceptions. Not every exception is checked.
                      And what shitstorm we had about those, too...

                      Comment

                      Working...
                      X