Taking Go modules for a spin • Hacker News Board

Re: Taking Go modules for a spin

#71

Post by bbatha » Tue, Jul 17, 2018, 4:07 PM UTC

dilap wrote: post #67

bbatha wrote: post #64

Earlier quoted context omitted.

It does. There are ways to mark a package as "only once" in the dep graph. For instance, C libraries are required to be marked in this way. The only once constraint also has a nice out for the SAT solver, if you reach a conflict or something that can't be solved cheaply you just make the user select a version that may not be compatible with the constraints. Bower, dep, and maven work that way.

You anticipated where I was going, which is mutable state + multiple copies of packages seems like a recipe for trouble. So, I'm not sure how happy I would be as a user if my package installer bailed out and asked me to choose! Out of curiosity, how do you mark your package as "only once" in cargo? I tried googling, and didn't find an answer, but did find a bug where people couldn't build because they ended up depend…

> So, I'm not sure how happy I would be as a user if my package installer bailed out and asked me to choose!

Its definitely not a great UX, but at the end of the day the problem can only be solved at the language level or by package authors choosing new names. For instance in java you can't import 2 major versions of a package. Solving for minor versions having to bail out has been incredibly rare in my experience. I only see it when there's "true" incompatibilities, e.g.

foo: ^1.5.0 bar: foo (> Out of curiosity, how do you mark your package as "only once" in cargo? I tried googling, and didn't find an answer, but did find a bug where people couldn't build because they ended up depending on two different versions of C libraries!

I think its the `links = ""` flag. It may only work for linking against C libraries at the moment, but cargo understands it!

> It does make wonder if MVS will solve real pain in practice. :-)

Not by itself, the semantic import versioning is the solution to the major version problem, by giving major versions of package different names. Go packages aren't allowed to blacklist versions, though your top level module is. This just means that package authors are going to have to communicate incompatible versions out of band, and that the go tool may pick logically incompatible versions with no signal to the user beyond (hopefully) broken tests!

Re: Taking Go modules for a spin

#72

Post by bbatha » Tue, Jul 17, 2018, 4:11 PM UTC

steveklabnik wrote: post #65

dilap wrote: post #63

Earlier quoted context omitted.

does rust have mutable package-level state like go?

Packages are made up of modules, and modules can have global state. But doing so directly is unsafe, specifically because it can introduce a data race. Rust also does not have “life before main”, so it doesn’t get used in the same way as languages that do. I’m not sure if Go does?

Even if its not just "mutable" state there are a lot of undesirable situations for multiple package imports in rust:

1. Singletonish things like global allocators, rayon-core, etc

2. You may have made a package static safe to mutate with a mutex, but it could be a bad thing to have different versions of that mutex.

3. Compile time computed tables (unicode table, perfect hashes, etc) could be imported multiple times ballooning the binary.

4. ABI/type compatibility with any reexported types

Re: Taking Go modules for a spin

#73

Post by steveklabnik » Tue, Jul 17, 2018, 4:23 PM UTC

bbatha wrote: post #72

steveklabnik wrote: post #65

Earlier quoted context omitted.

Packages are made up of modules, and modules can have global state. But doing so directly is unsafe, specifically because it can introduce a data race. Rust also does not have “life before main”, so it doesn’t get used in the same way as languages that do. I’m not sure if Go does?

Even if its not just "mutable" state there are a lot of undesirable situations for multiple package imports in rust: 1. Singletonish things like global allocators, rayon-core, etc 2. You may have made a package static safe to mutate with a mutex, but it could be a bad thing to have different versions of that mutex. 3. Compile time computed tables (unicode table, perfect hashes, etc) could be imported multiple times b…

Oh totally. Thanks for listing those out.

Re: Taking Go modules for a spin

#74

Post by dilap » Wed, Jul 18, 2018, 12:54 AM UTC

bbatha wrote: post #71

dilap wrote: post #67

Earlier quoted context omitted.

You anticipated where I was going, which is mutable state + multiple copies of packages seems like a recipe for trouble. So, I'm not sure how happy I would be as a user if my package installer bailed out and asked me to choose! Out of curiosity, how do you mark your package as "only once" in cargo? I tried googling, and didn't find an answer, but did find a bug where people couldn't build because they ended up depend…

> So, I'm not sure how happy I would be as a user if my package installer bailed out and asked me to choose! Its definitely not a great UX, but at the end of the day the problem can only be solved at the language level or by package authors choosing new names. For instance in java you can't import 2 major versions of a package. Solving for minor versions having to bail out has been incredibly rare in my experience. I…

> Go packages aren't allowed to blacklist versions, though your top level module is. This just means that package authors are going to have to communicate incompatible versions out of band, and that the go tool may pick logically incompatible versions with no signal to the user beyond (hopefully) broken tests!

Yeah, it seems if the Go system ends up not working out in practice, this will be why.

But because of the minimal nature of MVS, you won't run into this problem unless something else is compelling you to go to the broken version. And by the time that's happening, you'd hope that the bug would've been reported and fixed in the original library.

It'll be interesting to see how it plays out in practice.

(Also, if I have a library A that depends on B, which is being reluctant or slow about fixing some bug, I can always take the nuclear option and just fork B and then depend on that. Basically the explicit version of what Cargo would do through deciding it couldn't resolve w/o creating two versions. But I think the incentives might be set up right that the easy/happy path will end up getting taken in practice.)

Re: Taking Go modules for a spin

#75

Post by akavel » Fri, Jul 27, 2018, 10:49 AM UTC

atombender wrote: post #70

akavel wrote: post #55

Earlier quoted context omitted.

Personally, I actually never thought Dep was blessed by the Go team to the point that it "was going to be official". So I wouldn't be so fast to say "pretty much everyone". Notably, some loud people "thought" so; I've noticed that many quiet people quietly did not (as can be seen e.g. by the numerous voiced agreements and endorsements of the vgo prototype on the mailing list). Again, I personally expected exactly som…

What impression you had probably depends on whether you read the Go mailing lists or not. All of my colleagues, myself included, had gotten the impression, who knows how, that Dep was official. We don't follow the Go lists. The Dep situation is very similar to that of Eric S. Raymond's attempt at replacing the Linux kernel's config tool. Instead of presenting a design proposal and discussing it in public, he pretty m…

That's a very interesting reply for me, thanks. Reflecting on it, actually I don't really follow the list either nowadays, due to not enough time. But I feel I kinda do know the “who's who” of the community, and thus I sometimes just glance through some threads (e.g. on HN) looking only for what did a core member of the Go team say. Recently, I repeatedly feel it's important to quickly find out who's the “important people with power” in an online tech forum. I don’t want this to sound as some kind of a critique; just trying to put down how I believe I came to the conclusion I expressed in the above comment, to try and better understand it for myself.