Comment on Golang be like

Draces@lemm.ee ⁨10⁩ ⁨months⁩ ago

• devfuuu@lemmy.world [bot] ⁨10⁩ ⁨months⁩ ago

  People are scared of monads and think this is better.

  source

  • serenity@lemmy.world ⁨10⁩ ⁨months⁩ ago

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

    source

    • nick@campfyre.nickwebster.dev ⁨10⁩ ⁨months⁩ ago

      Having a Result monad that could represent either the data from a successful operation or an error. This can be generalised to the Either monad too.

      source

      • serenity@lemmy.world ⁨10⁩ ⁨months⁩ ago

        [deleted]

        source

        • -> View More Comments
    • psilocybin@discuss.tchncs.de ⁨10⁩ ⁨months⁩ 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 (nearly) all the time.

      source
    • Nevoic@lemmy.world ⁨10⁩ ⁨months⁩ 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
      

      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 err
        }
      
        validatedAge, err = validateAge(age)
        if err != nil {
          return err
        }
      
        return User(Name: validatedName, Age: validatedAge)
      }
      

      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
      

      source
• arc@lemm.ee ⁨10⁩ ⁨months⁩ 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.

  source

  • barsoap@lemm.ee ⁨10⁩ ⁨months⁩ 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.

    source

    • arc@lemm.ee ⁨10⁩ ⁨months⁩ 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

      source
    • Nevoic@lemmy.world ⁨10⁩ ⁨months⁩ ago

      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 <&> 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
          (?.) = (<&>)
      
      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
          (?.) = (<&>)
      
      instance Chainable a b (Maybe b) where
          (?.) = (>>=)
      

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

      source

      • barsoap@lemm.ee ⁨10⁩ ⁨months⁩ 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.

        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 :)

        source
    • m_f@midwest.social ⁨10⁩ ⁨months⁩ 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.

      source

      • barsoap@lemm.ee ⁨10⁩ ⁨months⁩ 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 ?

        source
• christophski@feddit.uk ⁨10⁩ ⁨months⁩ ago

  Can anybody explain the rationale behind this?

  source

  • fkn@lemmy.world ⁨10⁩ ⁨months⁩ ago

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

    source

    • planish@sh.itjust.works ⁨10⁩ ⁨months⁩ 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.

      source
    • msage@programming.dev ⁨10⁩ ⁨months⁩ ago

      Hahaha, fuck no, I’ve dealt with exception-less code enough in my life, kthxbye

      source

      • GlitchSir@lemmy.world ⁨9⁩ ⁨months⁩ ago

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

        source
  • ennemi@hexbear.net ⁨10⁩ ⁨months⁩ 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) and treating errors as values like in C. Rob Pike attempts to explain why it’s not a big deal here.

    source
  • silent_water@hexbear.net ⁨10⁩ ⁨months⁩ 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.

    source
• vox@sopuli.xyz ⁨10⁩ ⁨months⁩ ago

  btw lua handles error in exactly the same way

  source