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

Go Modules in 2019

blog.golang.org

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Go Modules in 2019

#161

Post by Merovius »

pjmlp wrote: post #159
Merovius wrote: post #158

Earlier quoted context omitted.

> So instead of creating M packages * N OSes, we do it just once. No, creating M packages x N OSes is exactly what we do. In fact, we create M+N package- managers x N OSes - and then also create MxN packages. If you can write a language-specific package manager for all OSes, you can also write a non-language-specific package manager for all OSes, so I the "it doesn't work in all distributions" argument is just a symp…

Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for. My C++, Java and .NET packages work everywhere there is…

> Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for.

Can you explain why that would be a problem? It's certainly not a technical one, none of these are special when it comes to versioning or dependency management of software. I can see that there's a social/political problem - which is exactly what I'm talking about.

Re: Go Modules in 2019

#162

Post by iainmerrick »

erik_seaberg wrote: post #146
iainmerrick wrote: post #106

Earlier quoted context omitted.

Because the designers of Kotlin are more open to experimentation and new ideas.

(setq n (cond (expr trueVal) (t falseVal))) This particular idea dates back to at least 1965.

Er, yes, I should say “new ideas about which features are worth stealing from Lisp” :)

Re: Go Modules in 2019

#163

Post by Carpetsmoker »

latch wrote: post #148
Carpetsmoker wrote: post #138

Earlier quoted context omitted.

There are "I've used Go for a week and here are my strong opinions on it!" posted to reddit (and elsewhere) every week. Frankly, it's just tiring; especially as a lot of the same points and misconceptions are repeated. Some points are valid, but it's repetitive at best. It would be like discussing Python's significant whitespace with inexperienced Python programmers every week. Sure, it's quirky and arguably not a go…

I started using Go in 2008, but I get your point. Still, I think my and my parent's point is that: it would have been better if they'd just said nothing.

> I started using Go in 2008, but I get your point.

Yeah, it's an imperfect heuristic. I didn't intend it as a remark about you or your article in particular (I had added a sentence about that in my previous comment, but it must have gotten lost in the editing).

> it would have been better if they'd just said nothing.

Yes, I agree. "If you can't say it nice, then it's probably best to not say anything at all". I thought it would just be helpful to explain some of the frustrations that are (probably) behind the comment.

Re: Go Modules in 2019

#164

Post by pjmlp »

Merovius wrote: post #161
pjmlp wrote: post #159

Earlier quoted context omitted.

Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for. My C++, Java and .NET packages work everywhere there is…

> Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for. Can you explain why that would be a problem? It's cer…

It surely is a technical one above any political willingness.

A package format that supports all OS system paths, installation processes, difference between build time/dev time/deployment time, language compilation toolchains, compiler flags, ways to address hardware resources,OS specific deployment processes, ... is bound to the lowest common denominator for any chance of success.

Thus forcing everyone that needs something beyond that lowest common denominator to implement their own workarounds, thus we are again back to language package managers.

Re: Go Modules in 2019

#165

Post by EdiX »

candiodari wrote: post #140
EdiX wrote: post #98

Earlier quoted context omitted.

> Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that. This is not true. If you pass -mod=vendor, or place it in $GOFLAGS, go will build something outside of GOPATH, in module mode, using the vendor directory exclusively. I wish it was the default, but only because it encourages people to not use vendor directories (which is a bad habit), not because…

Why are vendor directories a bad habit ? There just shouldn't be any GOPATH at all as far as I'm concerned. Look in /usr/include. There you can see what's wrong with GOPATH, 5 years in the future. Now try installing 2 different versions of libraries. I'll wait.

> Why are vendor directories a bad habit ?

They aren't, not having them is.

Re: Go Modules in 2019

#166

Post by EdiX »

calcifer wrote: post #110
EdiX wrote: post #98

Earlier quoted context omitted.

> Right now, "module mode" is mutually exclusive with "vendor mode" and I don't think there are any plans to change that. This is not true. If you pass -mod=vendor, or place it in $GOFLAGS, go will build something outside of GOPATH, in module mode, using the vendor directory exclusively. I wish it was the default, but only because it encourages people to not use vendor directories (which is a bad habit), not because…

> in module mode, using the vendor directory exclusively But that's not what I'm asking. I want "go build" (with some flags) to use my fork (vendored if needed) for one library, and pick up all other dependencies from the module cache as usual. How do I that? Because this is already possible in a vendor-only world; I just edit the code in vendor.

You check out the dependency you want to change and add a replace directive in go.mod. Either a temporary one to a file system path or a permanent one to a forked repository.

Re: Go Modules in 2019

#167

Post by 4ad »

candiodari wrote: post #145
yashap wrote: post #103

Earlier quoted context omitted.

Quite a few languages do if expressions, and IMO they’re great. Simple syntax, readable and powerful. It’s crazy to me that any new language wouldn’t have them.

The argument specified in the docs is "a language needs only one conditional flow construct" (in a language, of course, that has half a dozen conditional flow constructs ...) The more palatable argument that people who try to cover for ... seems to be that when people nest if expressions, it becomes a mess. I'm glad these people exist. The real reason is found here: http://dtrace.org/blogs/wesolows/2014/12/29/golang-…

Ken Thompson has been writing compilers for over 50 years now. If you believe that Ken "barely knew how to get a compiler working in the first place", we have nothing to talk about, as you obviously made up your mind already.

Re: Go Modules in 2019

#168

Post by almostdeadguy »

zemo wrote: post #59
treve wrote: post #8

One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…

the fact that you call Rob Pike "Erik Pike" really reads like the complaints of someone who doesn't do their homework and asks questions that have already been answered in many places. Generics is a major tell, too, since the Go team's position on generics was always "generics are interesting but we don't know how to make them work well with Go's existing type system". See for example, this blog post from 2009: https…

The kinds of parametric polymorphism implementations mentioned here do not represent the full set of options. Charitably this represents an ignorance on the part of the Go developers, but really it has felt like an apathy towards the field of programming language design and research. Intensional polymorphism (basically passing the type of a parametric argument as a parameter, and either using a specialized implementation of the function or one that operates over a boxed value) has been known about for years and is used in languages like Haskell: https://www.cs.cmu.edu/~rwh/papers/intensional/popl95.pdf

Re: Go Modules in 2019

#169

Post by Merovius »

pjmlp wrote: post #164
Merovius wrote: post #161

Earlier quoted context omitted.

> Good luck creating a package format that works across iOS, Android, Red-Hat, SuSE, Debian, Ubuntu, ..., IBM i, IBM z, Aix, HP-UX, Solaris, Windows, Zephyr, Yoctos, RTOS, Integrity, mbed, MicroEJ, BSD variants, Unisys ClearPath, VxWorks, QNX, macOS, Tizen, Jolla, ChromeOS, Fuchsia and several others that I am unaware of or was too lazy to keep adding entries for. Can you explain why that would be a problem? It's cer…

It surely is a technical one above any political willingness. A package format that supports all OS system paths, installation processes, difference between build time/dev time/deployment time, language compilation toolchains, compiler flags, ways to address hardware resources,OS specific deployment processes, ... is bound to the lowest common denominator for any chance of success. Thus forcing everyone that needs so…

> is bound to the lowest common denominator for any chance of success.

ISTM the "lowest common denominator" is a superset of everything current language-specific package-managers support and a subset of anything a current language-agnostic package-manager supports (pretty much definitionally). So ISTM that this is a net win - easier to build than APT/DNF/Pacman… and yet more useful than npm/stack/pip/…

In particular, I don't know any currently existing language-specific package-manager that supports what I'd call the GCD of package-management (e.g. none that I can think of supports actual OS-specific installation of packages) so that clearly isn't even a requirement.

> Thus forcing everyone that needs something beyond that lowest common denominator to implement their own workarounds, thus we are again back to language package managers.

FWIW, a) part of the political and social problem is to talk more honestly about what "needing" really means and b) no, that's not at all "back to language package managers". You can have a layered design, e.g. splitting the "building" and the "installation" part, thus letting languages implement their workarounds in their dedicated building layer and letting OSes implement their workarounds in their installation layers. You just need to actually sit down and talk about the interface needed between the two (and the sets of layers actually needed, which will be >2). Which no one seems really willing to do.

Re: Go Modules in 2019

#170

Post by almostdeadguy »

Boulth wrote: post #151

> One of the most important parts of the original design for go get was that it was decentralized That's one of the things I like in go most. Having decentralized packages via domains and URLs and then index them (godoc.org works very well), it mirrors the design of the Web. In contrast npm, Rust and others that are tightly coupled to one site feels like Google AMP - centralizing and hosting everything in one place.

Cargo (in the nightly channel, but eventually will become stable) and npm can both use alternative package indexes and vendored dependencies, so they are not tightly coupled. Having a standardized package index as a database is what allows efficient dependency solving, which Go hasn't considered providing up until recently.

> that anyone should be able to publish their code on any server, in contrast to central registries such as Perl’s CPAN, Java’s Maven, or Node’s NPM. Placing domain names at the start of the go get import space reused an existing decentralized system and avoided needing to solve anew the problems of deciding who can use which names. It also allowed companies to import code on private servers alongside code from public servers.

lol statements like this are infuriating. Go is no more decentralized than those languages, unless you consider git hosting something people in standard practice do on their own (survey some of the top Go dependencies and see if that holds true). They simply lack a package index, but the cited language package managers both have those and allow you to host your own.

Post reply on HN