I want off Mr. Golang’s Wild Ride (2020)

Post by masklinn » Thu, Apr 28, 2022, 6:40 PM UTC

throw10920 wrote: post #104

the_common_man wrote: post #42

Earlier quoted context omitted.

> For example, Go error handling is shit What is bad about it?

Errors as return values is only acceptable for code that is so performance-sensitive that you aren't allowed to do dynamic memory allocations. For everything else, conditions+restarts are the correct answer, because errors-as-values restricts you to a single error-handling strategy and couples high-level code to low-level code as a result.

Post by throwaway894345 » Thu, Apr 28, 2022, 6:42 PM UTC

reedjosh wrote: post #193

throwaway894345 wrote: post #154

Earlier quoted context omitted.

I can't relate. Newline characters have never been burdensome to me, and they aid in visual structure (the control flow is represented by the visual structure of the program, not only for "good data" paths, but also for error paths). My programming problems are usually not related to localized keystroke boilerplate, but rather larger issues of abstraction and data modeling. > My current project is in the k8s ecosyste…

Well, if you don't know the structure of a resource ahead of time but know that it has a status.ready, I would think that would be a candidate for a generic? I haven't explored that much yet, but in retrospect I might even be able to convert all objects to a struct that has only status.ready without generics. I've only been in the ecosystem 6 months, but yeah larger abstractions are difficult too. I'm not a fan of th…

    type Resource interface {
        Status() Status
    }

    type Status interface {
        Ready() bool
    }

Post by dosethree » Thu, Apr 28, 2022, 6:42 PM UTC

jerf wrote: post #105

mcronce wrote: post #47

Earlier quoted context omitted.

It requires several additional lines of code just to bubble up an error, for starters, and there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data.

"there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data." In theory, this is a big deal. In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it. A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another fu…

Post by throwaway894345 » Thu, Apr 28, 2022, 6:45 PM UTC

reedjosh wrote: post #248

assbuttbuttass wrote: post #220

Earlier quoted context omitted.

Go's equivalent of sub-classing is embedding

Yeah, and I kind of did that. But I've found it annoying and not great. For example in the base struct I had an interface and a ton of methods that use it. Then when I declared the concrete struct, I have to manually point the concrete type that matches that interface to the base class's interface. Composition doesn't really allow the same thing as inheritance. Composition typically means you'll have a motor and whee…

    type Car struct {
        Motor Motor
        Wheels [4]Wheel
    }

    type Motor interface {
        Rev()
    }

    type KiaMotor struct { ... }

    func (kia *KiaMotor) Rev() {}

    func NewKiaCar() Car {
        return Car{Motor: &KiaMotor{ ... }}
    }

Post by lliamander » Thu, Apr 28, 2022, 6:45 PM UTC

zasdffaa wrote: post #238

lliamander wrote: post #210

Earlier quoted context omitted.

Then you wouldn't really be programming in Go. You'd be programming in whatever franenkstein's monster of a language your preprocessor is using. Preprocessors are a code smell, and indicate that the language you are using lacks the right abstractions for productive programming.

> and indicate that the language you are using lacks the right abstractions for productive programming. Indeed go did not have generics, in fact that's explicitly stated in the post I was responding to: "at the time the lack of generics made it so that you either had to use reflection - or implement the same function N times over to support the different numeric data types" So, you unthinking prat, what do you recomm…