How Go mitigates supply chain attacks

Post by merely-unlikely » Thu, Mar 31, 2022, 9:00 PM UTC

the_duke wrote: post #65

nmilo wrote: post #43

Earlier quoted context omitted.

Generally I find if you're writing code like that, your code is too high level. Okay, you've propagated errors, but what is the calling code going to do with those errors? I find large functions like that usually have enough context to handle the errors themselves. Errors, after all, are just conditions with a special name. It's not common to propagate conditions up several layers of code, so why do the same with err…

Go doesn't have (automatic) backtraces. If you don't wrap errors with a trace or with a custom message you often have no idea where the error came from.

  if err != nil {
    return mherr.WrapErr(err, "optional context")
  }

Post by typical182 » Thu, Mar 31, 2022, 9:13 PM UTC

typical182 wrote: post #94

goodoldneon wrote: post #92

Earlier quoted context omitted.

Wouldn't build size increase a lot if transitive dependencies were pinned to direct dependency lockfiles? Like if library A says "use version 1.0.0 of library X" and library B says "use version 1.0.1 of library X", then you'd likely end up bundling duplicate code in your build. Not saying the tradeoff isn't worth it, but pinning to dependency lockfiles isn't without downsides.

FWIW, that's not what Go does. In your scenario, a Go binary ends up with a single copy of library X -- the 1.0.1 version. That's because library A is stating "I require at least v1.0.0 of X", and library B is stating "I require at least v1.0.1 of X". The minimal version that satisfies both of those requirements is v1.0.1, and that's what ends up in the binary. That behavior is Go's "Minimal Version Selection" or "MV…

Post by throwaway894345 » Thu, Mar 31, 2022, 9:23 PM UTC

Friday_ wrote: post #96

throwaway894345 wrote: post #82

Earlier quoted context omitted.

So we just don't build GUI applications unless we understand all of the nuances of layout, text rendering, graphics programming, etc sufficient to implement it ourselves (and without the bugs that even domain experts have introduced but which have been found and fixed over time in libraries)? Or maybe we just say "fuck users who speak languages that aren't easily expressed in ASCII"? There's a reason libraries exist.…

Software programmer usually need to solve specific task, not worlds problems. If you go too generalized you will need 10x, 100x or 1000x more amount of time and code. Look at Big tech, this is what they are doing, they employ thousands workers that write millions of lines of code every day, only to make it work for every case in a world. And still can't compete with specialized solution.

Post by munificent » Thu, Mar 31, 2022, 9:30 PM UTC

klodolph wrote: post #103

munificent wrote: post #97

Earlier quoted context omitted.

> Other systems for determining the versions to use are much more unpredictable and hard to understand than estimated (look at Dart and Cargo) I'm one of the co-authors of Dart's package manager. :) Yes, it is complex. Code reuse is hard and there's no silver bullet.

Nice! I hope I wasn't coming across as critical of Dart's package manager, or Cargo for that matter.

Post by dtgriscom » Thu, Mar 31, 2022, 9:32 PM UTC

vlunkr wrote: post #81

The elephant in the room here is NPM, and I think the obvious problem there is the culture. I have a tiny app I've been playing with using create-react-app. There are over 800 directories in node_modules. That absolutely dwarfs the number of any other language I've used. Even in a medium sized rails app, you likely have some awareness of what every dependency is. It's just impossible with npm. One thought I've had to…