How Go mitigates supply chain attacks

Post by philosopher1234 » Thu, Mar 31, 2022, 5:55 PM UTC

______-_-______ wrote: post #21

37ef_ced3 wrote: post #4

Go is a distillation of many decades of software engineering experience. The people behind Go (e.g., Russ Cox) have learned from history. The peanut gallery loves to complain about superficial aspects of Go. Typically these are people with little or no actual experience using the language and tools. They fixate on imagined problems that don't matter in practice. But anyone who has used Go full-time for a few years is…

For a decade+, people complained that go lacks generics. Would you say those were all people with no experience fixated on an imaginary problem that doesn't matter, or were the complaints valid?

Post by philosopher1234 » Thu, Mar 31, 2022, 5:58 PM UTC

mFixman wrote: post #28

icholy wrote: post #19

Earlier quoted context omitted.

let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }

func ThisCouldUseExceptions() error { err := Exceptions() if err != nil { return terrors.Propagate(err) } err = GeneraliseBetter() if err != nil { return terrors.Propagate(err) } value, err = InFunctionsWithMultipleErrorPoints() if err != nil { return terrors.Propagate(err) } value, err := AlsoTheyHelp() if err != nil { return terrors.Propagate(err) } chained_val, err := WithChaining(value) err = AndPreventAccidental…

    func ThisCouldUseExceptions() error {
        err := Exceptions(arg)
        if err != nil {
            return fmt.Errorf("if a '%v' dev: %w", err)
        }
    
        err = GeneraliseBetter()
        if err != nil {
            return fmt.Errorf("has to actually: %w", err)
        }
    
        value, err = InFunctionsWithMultipleErrorPoints()
        if err != nil {
            return fmt.Errorf("read these errors: %w", err)
        }
    
        value, err := AlsoTheyHelp()
        if err != nil {
            return fmt.Errorf("they will actually be: %w", err)
        }
    
        chained_val, err := WithChaining(value)
        if err != nil {
            return fmt.Errorf("useful: %w", err)
        }
        err = AndPreventAccidentallyIgnoringErrors(chained_val)
        if err != nil {
            return fmt.Errorf("this isnt a real problem: %w", err)
        }
    }

Post by typical182 » Thu, Mar 31, 2022, 6:05 PM UTC

munificent wrote: post #15

> There is no way for changes in the outside world—such as a new version of a dependency being published—to automatically affect a Go build. > Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions. The version of every dependency contributing to any Go build is fully determined by the go.mod file of the main module. I don't know if thi…

Post by [deleted] » Thu, Mar 31, 2022, 6:11 PM UTC

munificent wrote: post #15

> There is no way for changes in the outside world—such as a new version of a dependency being published—to automatically affect a Go build. > Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions. The version of every dependency contributing to any Go build is fully determined by the go.mod file of the main module. I don't know if thi…

Post by philosopher1234 » Thu, Mar 31, 2022, 6:13 PM UTC

throw_m239339 wrote: post #36

icholy wrote: post #19

Earlier quoted context omitted.

let foo; try { foo = await is_this_better(); } catch (err) { console.log("if err != nil doesn't seem so bad all of a sudden"); }

Well you can actually put many exception yielding statements in the try, unlike with go where your code is full of "if err:=nil{}" after every potential error. Most of the time when an exception occurs in sequential operations that can fail, you don't really care where it failed exactly, only that the failure was caught. The irony is that Go does have half baked exceptions (panic,recover) on top of that error as valu…