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

Problems with Go Get

0x74696d.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Problems with Go Get

#81

Post by munificent »

nulltype wrote: post #62
tene wrote: post #54

Earlier quoted context omitted.

How do you arrange to never have any transitive dependencies?

I use specific versions of libraries in my app. If two libraries depend on some third library it's rarely an issue, and when it is an issue I often have to resolve it manually anyway. Ideally I think each library would have its own internal copy of any dependencies, but there are some issues with doing that at least in go.

> Ideally I think each library would have its own internal copy of any dependencies

That works if and only if the library never exposes the use of that dependency, but it can break in horrible ways otherwise.

For example, let's say library foo uses some hash_table package to define some hash table data structure. Foo returns hash tables from its public API. Now imagine your app uses foo, gets one of those hash tables, and passes it to bar.

Bar also uses the hash_table package, but--since dependencies are encapsulated--has its own copy of a different version on hash_table. How is that hash_table code going to handle being given a hash table that was created from a different version of itself?

In a dynamically-typed language like JS, it may work, but this seems super sketchy to me, which is why I think an app should only have a single version of any given dependency.

Re: Problems with Go Get

#82

Post by munificent »

hittaruki wrote: post #74
munificent wrote: post #21

I'm awkwardly patting myself on the back here since I'm one of the co-authors, but I really wish more people knew about the package manager we have for Dart[1]. Really, though, I can't take credit, since we basically just do the same thing Bundler does. [1]: https://www.dartlang.org/tools/pub/get-started.html It solves every single one of the problems listed here. It has a very simple workflow: 1. You make a pubspec.…

One of the thing Cheney says in his talk about gb is that nobody likes the .lock files[1], I see that dart is using .lock files, bundlers also uses .lock files as does rust. But other languages seems to get away without it.. clojure with lenigen seems to do it nicely. So what are the problems with it? http://go-talks.appspot.com/github.com/davecheney/presentati...

> One of the thing Cheney says in his talk about gb is that nobody likes the .lock files[1]

That may be true if by "nobody" he means Go users, but outside of the Go community things are different. I haven't heard many complaints about them in the Ruby or Dart ecosystems, and the value they provide (repeatable builds!) is very real.

Re: Problems with Go Get

#84

Post by munificent »

nrser wrote: post #77
munificent wrote: post #21

I'm awkwardly patting myself on the back here since I'm one of the co-authors, but I really wish more people knew about the package manager we have for Dart[1]. Really, though, I can't take credit, since we basically just do the same thing Bundler does. [1]: https://www.dartlang.org/tools/pub/get-started.html It solves every single one of the problems listed here. It has a very simple workflow: 1. You make a pubspec.…

bundler is great. i really wish it worked for most major languages. switching between projects in different languages with different packaging systems is a bunch of weight i don't want to have to carry around or time i don't want to waste. it sounds like you some-what 'ported' bundler to dart... what's your impression of how difficult it would be extend a tool like this to work for many languages? it seems like i'm a…

> it sounds like you some-what 'ported' bundler to dart...

More or less. Most of pub's code is devoted to stuff that's specific to Dart, but it's underlying "philosophy" is Bundler's model.

> what's your impression of how difficult it would be extend a tool like this to work for many languages?

This comes up a lot, but my hunch is that we're unlikely to see a successful language-agnostic package manager. The package manager has to be written in some language, and users of language X generally don't want to be told that they have to install language Y before they can download packages for X.

Also, most of the code for a package manager is fiddly details related to the specific language in question. Thinks like how files are organized, running tests, etc. The amount of code you could share is actually pretty small.

Re: Problems with Go Get

#86

Post by garthk »

nulltype wrote: post #66
TheDong wrote: post #64

Earlier quoted context omitted.

It's very easy to do that in go by just import path rewriting, ignoring legal consequences, and vendoring. Perhaps what you want is npm where what you describe is built in, first class, and looked down upon by much of the sane world.

What are the legal consequences of path rewriting? And why would the sane world look down on npm?

Many correlate "sane" with "statically typed". [1]

JacaScript can cope perfectly well with modules A and B relying on different versions of C. It'll often cope even if A calls B with an object it got with C, or some other module broadly compatible with C. Static typing proponents aren't comfortable with the idea, so it's not "sane" to them. Sane or not, many argue it's not just not slowing down the Node community, but actively contributing to its explosive growth.

In C#, you get MethodMissingException if A.DLL and B.DLL refer to different copies of C.DLL and A calls B with an object it got from C, even if the copies of C.DLL are identical.

1: Perhaps I should contrast with strong typing, not static typing. Meh.

Post reply on HN