Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Go mitigates supply chain attacks

go.dev

Post reply on HN
Print view View original

51–60 of 265 posts

Re: How Go mitigates supply chain attacks

#51

Post by throw_m239339 »

philosopher1234 wrote: post #46
throw_m239339 wrote: post #42

Earlier quoted context omitted.

> Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better. No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue…

> No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes i…

> Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at.

Go makes it pretty easy to ignore errors, it's even worse than Java. An uncaught managed exception will not compile, and an uncaught unmanaged exception might terminate your program.

    _ := YieldsAnError()
will will never terminate your program. Go makes it pretty easier to do the wrong thing.

Re: How Go mitigates supply chain attacks

#52

Post by randomdata »

ryeguy wrote: post #24
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"); }

This comparison misses the point. Go requires you to bubble up errors manually, that's the difference.

At least one can respect Go for being consistent, even if requires a little extra manual labour. The languages that require you to manually bubble up some types, but not others, are just bizarre. Like, they're onto something neat, but why stop halfway? I don't want to put in the manual work for any type. If I've decided the manual effort is worthwhile, I don't want weird exceptions to worry about. Pick a lane, programming languages.

Re: How Go mitigates supply chain attacks

#53

Post by philosopher1234 »

throw_m239339 wrote: post #51
philosopher1234 wrote: post #46

Earlier quoted context omitted.

> No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue with Java, it is not an issue in the language itself, it's with you and your team. Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes i…

> Its my entire company, and its with the open source ecosystem. Its naive to think that language constructs dont influence dev's decisions. You need to make it easy to do the right thing, not hard, and go makes it easy, which java fails at. Go makes it pretty easy to ignore errors, it's even worse than Java. An uncaught managed exception will not compile, and an uncaught unmanaged exception might terminate your prog…

You're arguing a technicality, which is a waste of time. We should focus on reality, not imaginary theoretical issues. In reality, that never happens. And people even develop linters (frankly unnecessary) to guarantee it, if you're really paranoid.

This is a social problem, influenced by language design. You need to be thinking about the way humans actually behave in practice, not how they theoretically might behave.

In practice people do not accidentally skip errors in Go. In practice people do not handle errors at all in Java. This is the responsibility of the respective cultures and language designs.

Re: How Go mitigates supply chain attacks

#55

Post by nu11ptr »

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…

Couldn't disagree more (I spent years writing Go, and now Rust - will NEVER go back)

Re: How Go mitigates supply chain attacks

#56

Post by geodel »

munificent wrote: post #49
philosopher1234 wrote: post #40

Earlier quoted context omitted.

Go just expects you to manually trigger the updates. Thats all. It still is in favor of updating to take security fixes, so i think your argument is wrong.

Let's say my_app uses package foo which uses package bar. It turns out there is a security bug in bar. The bar maintainers release a patch version that fixes it. In most package managers, users of my_app can and will get that fix with no work on the part of the author of foo. I'm not very familiar with Go's approach but I thought that unless foo's author puts out a version of foo that bumps its minimum version depend…

You keep harping on old buggy version where Go has been very clear that it is operator's explicit responsibility to have correct/updated/fixed versions of dependency running.

It specially does not look good in your case considering you work for Google on a different programing language. If you have a clear point to make then compare it with your approach. Instead of making neutral sounding arguments when they are not.

Re: How Go mitigates supply chain attacks

#57

Post by nu11ptr »

> Unlike most other package managers files, Go modules don’t have a separate list of constraints and a lock file pinning specific versions.

The weird thing about the Go devs is there is always that little bit of elitism under the surface that I detect in their writing (whether it be colors in the playground, the GC, etc). I spent years writing Go and have now moved to Rust. What I find odd is the Rust team has done (IMO) one of the greater achievements in PL history and yet they seem to not have this elitism thing going on (or maybe I just haven't noticed). Go on the other hand, IMO, made some "interesting" language choices (like keeping null) and they seem to want to be celebrated for it and claim their achievements as new and novel.

EDIT: To clarify, I'm talking about the core Go devs - those that work on stdlib and the compiler

Re: How Go mitigates supply chain attacks

#58

Post by typical182 »

munificent wrote: post #45
infogulch wrote: post #38

Earlier quoted context omitted.

The author is saying that Go provides the same guarantees with just a package list in the go.mod file that other package managers need both a package list and lock file to solve. go.sum is essentially a distributed / community maintained transparency log of published versions of packages.

Maybe I'm just not familiar with it enough but I don't see how merging a package manifest and lockfile into a single file is a net win. This means it's no longer clear which dependencies are immediate and which are transitive. It's not clear which versions are user-authored constraints versus system-authored version selections. For dependencies that are transitive, it's not clear why the dependency is in there and wh…

FWIW, there are two machine-formatted sections of go.mod -- the first for direct dependencies, the second section for indirect dependencies.

(That's as of Go 1.17. Previously, that information was communicated via machine-generated comments in a single section).

Re: How Go mitigates supply chain attacks

#59

Post by [deleted] »

throw_m239339 wrote: post #42
philosopher1234 wrote: post #39

Earlier quoted context omitted.

Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better.

> Far easier to work with and understand when you dont need to perform a massive disruptive ceremony to handle exceptions. I've been working full time in java for the past 4 years and basically no one handles exceptions because its so cumbersome and bad to read. Not so in Go. Go does it better. No Go doesn't do it better, Go just doesn't give you the choice, from a convention perspective. You have a discipline issue…

[deleted]

Re: How Go mitigates supply chain attacks

#60

Post by infogulch »

I'm annoyed by the false dichotomy that colors most discussions around package management that there are only two solutions to publishing software packages: 1. a carefully curated professionally maintained standard library, 2. the complete wild west where anything goes. It's not really "false" because this is the reality of how package managers are designed today, but it's false in the sense that it doesn't have to be this way.

You can see this tension in virtually every discussion, users resisting using packages that aren't published in the standard library for fear of attacks and poor quality, and maintainers that resist publishing in the standard library for fear of changing requirements and the appearance of better designs. Sure there are admissible entitlement / responsibility arguments against these respective positions, but that's mostly a distraction because both have a valid point.

The problem is that there's no space for intermediate solutions. We need packaging tools to aggregate and publish groups of packages that relate to a particular domain, and organizational tools to ensure quality and continuity of these package groups over time. This mitigates users' fears and reduces their cognitive load by curating the solution space, and it mitigates maintainers fears of ossification and backcompat hell by enabling them to create new package groups.

I'm saying there's an entire dimension of valid tradeoffs in this space, but the current design trend of package managers force us into one extreme or the other.

Post reply on HN