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

Go 1.7 is released

blog.golang.org

Post reply on HN
Print view View original

131–140 of 141 posts

Re: Go 1.7 is released

#131

Post by cookiecaper »

vetinari wrote: post #115
cookiecaper wrote: post #114

Earlier quoted context omitted.

Yeah, if you can install packages, then you can run the RVM installation script and install the right version of Ruby. In fact, you don't even need admin privileges if you use RVM.

That will get you off package system for the entire stack and now the maintenance of the whole circus is up to you. Which is exactly what I'm trying to get away from.

I do dislike individual language package managers and ecosystems for this reason, but I think it's gotta be accepted at this point. Practically every language has their own package repo and versioning apparatus now. Ruby has RVM, Node.js has NVM, Python has PyPi/venv, etc. Most projects expect their users to deploy with these and include things like Gemfiles to define dependencies. That usually means if you insist on using the upstream packages provided by the distribution, you're going to have to install them manually and have a bunch of extra headaches to worry about anyway (to be honest, most custom applications are really difficult to get running using only distro-packaged Ruby or Python libs).

Re: Go 1.7 is released

#132

Post by vetinari »

cookiecaper wrote: post #131
vetinari wrote: post #115

Earlier quoted context omitted.

That will get you off package system for the entire stack and now the maintenance of the whole circus is up to you. Which is exactly what I'm trying to get away from.

I do dislike individual language package managers and ecosystems for this reason, but I think it's gotta be accepted at this point. Practically every language has their own package repo and versioning apparatus now. Ruby has RVM, Node.js has NVM, Python has PyPi/venv, etc. Most projects expect their users to deploy with these and include things like Gemfiles to define dependencies. That usually means if you insist on…

The individual language package managers are very nice for development, as you may have any package version you want, and also for non-linux users, where there may be no native package management at all. For operations, however, they suck mightly (that's terminus technicus).

I quite like the SCL [1]. It solves the problem, that you might need different version of node/python/ruby/rails/php/whatever, than is packaged with the OS release of your choice. It has the software nicely packaged and maintained. Now getting third party packages to work with that, that's the problem. Passenger rpm [2] requires system-provided ruby, not just any ruby... I will survive that that App X wants Gem Y installed by rubygem. I won't like it, but it is workable and makes maintenance/updates slightly more difficutlt. But I will not put unpackaged module into Apache config.

[1] https://www.softwarecollections.org/

[2] https://www.phusionpassenger.com/library/install/apache/inst...

Re: Go 1.7 is released

#133

Post by lobster_johnson »

jay-saint wrote: post #96
sergiotapia wrote: post #36

Earlier quoted context omitted.

Same, it sounds off to me. I'm also not a grammar expert but know when something sounds 'off'. "Nintendo Wii U is released." - it just sounds strange. "Nintendo Wii U has been released." - ok, sounds good. "Nintendo Wii U released." - ok, sounds good.

""Nintendo Wii U has been released." has been is Passive voice and should be avoided.

Sometimes good advice, but certainly not a rule. As Pinker points out in "A Sense of Style", passive voice lets you modify word order to emphasize what's important to the reader.

Re: Go 1.7 is released

#134

Post by lobster_johnson »

prewett wrote: post #62
ksec wrote: post #23

Ok, off topic question. Not an expert in grammar, but something about "Go 1.7 is released" seems wrong to me. Anyone could tell me if this is an correct usage of grammar? Edit: Dont know why so many downvote, but it is a honest question.

It seems right to me (American speaker). "Released" functions as an adjective, with similar meaning to "available." "Go 1.7 is available" would be grammatically correct. "Go 1.7 has been released" would also be correct, but uses the present perfect tense. So the question is, can "released" be used as an adjective? "The released version has a bug" seems correct to me, and "released" clearly functions as an adjective t…

It's just present tense, usually known as "historical present" tense when used in a headline like this. "Released" here might be intended as an adjective or verb; it's ambiguous, but both are valid in the sentence structure.

Re: Go 1.7 is released

#135

Post by lobster_johnson »

cyphar wrote: post #46

The one thing that really pisses me off about the way Go handled vendoring is that they did it in a way that makes it incompatible with GOPATH. Previously in runC and Docker, we had build hacks that would symlink (or full copy) the current directory into vendor/src/ and then set the GOPATH to vendor/. This was compatible with every go version. In addition, many other projects did the exact same thing. But the way tha…

If anything, the Go people have repeatedly claimed they don't know best -- because Google famously uses a huge monorepo with all deps vendored, and don't do "package management" as such -- and have preferred to let the community find a solution organically.

Which is also why we ended up in this frustrating profusion of competing tools (Godeps, Glide and many others, plus the messy business that is git submodules) rather than a concerted effort towards a unified solution.

I don't at all believe the argument that they can't design something because they don't need it at Google. They're engineers, after all. You don't need to use a bridge in order to build one. There are plenty of existing tools (Bundler, Cargo, NPM, Cabal) that can also be used as case studies in how to do things right (Bundler, Cargo) or don't do them wrong (NPM).

In my company we use Glide, which is the best solution I've encountered so far, but it's beyond buggy, and struggles with some Google repos that need to be flattened in order to avoid duplicate, conflicting dependencies (glog and pflags, sigh).

Re: Go 1.7 is released

#136

Post by lobster_johnson »

mixedCase wrote: post #105
spriggan3 wrote: post #94

Earlier quoted context omitted.

It's also a necessary "evil" to demonstrate that languages should have the right amount of features, no more and tools are part of a language, along with ease of deployment. It's is questionable whether Go strikes the right balance when it comes to features vs "simplicity" though, but it might inspire better solutions in the future. I think MSFT is trying to follow the same path with .net core and its tool chain, I h…

>I hope they succeed as C# and F# are vastly superior to Go. In number of features, yes. Everything else and you come off as opinionated. I cannot comfortably write C# from my Linux workstation since all the tools are Windows-first. C# is a language where everything must be done in classes and inherits a C++/Java school of OOP which I find abhorrent as it tends to favor monstrosities of abstraction upon abstraction.…

C# in VSCode is really good, and works on Linux. Have you tried it?

Re: Go 1.7 is released

#137

Post by jakub_h »

yuyuyy wrote: post #59

Is Go based on llvm? It doesn't seem like it, but would be curious to know why not? Isn't this the point of llvm, to separate the "language component" from the "cpu component"?

Pehaps this is the point of LLVM, but the point of Go was getting rid of C++.

Re: Go 1.7 is released

#138

Post by cyphar »

lobster_johnson wrote: post #135
cyphar wrote: post #46

The one thing that really pisses me off about the way Go handled vendoring is that they did it in a way that makes it incompatible with GOPATH. Previously in runC and Docker, we had build hacks that would symlink (or full copy) the current directory into vendor/src/ and then set the GOPATH to vendor/. This was compatible with every go version. In addition, many other projects did the exact same thing. But the way tha…

If anything, the Go people have repeatedly claimed they don't know best -- because Google famously uses a huge monorepo with all deps vendored, and don't do "package management" as such -- and have preferred to let the community find a solution organically. Which is also why we ended up in this frustrating profusion of competing tools (Godeps, Glide and many others, plus the messy business that is git submodules) rat…

> If anything, the Go people have repeatedly claimed they don't know best

So why is the defacto vendoring system for the Go tooling incompatible with old Go versions (the "organic" solutions were compatible with Go versions without vendoring support because they were implemented before vendoring support was a thing!)?

The vendor/src hack meant that you could compile with ANY version of Go -- that's important for distributions (and other people who want to build runC and Docker -- put plainly we pin Go versions because of compiler bugs). But no, now we have to use vendor/ which means that now we have to do even more messing around with the GOPATH (which makes rpmbuild even more ugly than it needs to be). sigh

Re: Go 1.7 is released

#139

Post by lobster_johnson »

cyphar wrote: post #138
lobster_johnson wrote: post #135

Earlier quoted context omitted.

If anything, the Go people have repeatedly claimed they don't know best -- because Google famously uses a huge monorepo with all deps vendored, and don't do "package management" as such -- and have preferred to let the community find a solution organically. Which is also why we ended up in this frustrating profusion of competing tools (Godeps, Glide and many others, plus the messy business that is git submodules) rat…

> If anything, the Go people have repeatedly claimed they don't know best So why is the defacto vendoring system for the Go tooling incompatible with old Go versions (the "organic" solutions were compatible with Go versions without vendoring support because they were implemented before vendoring support was a thing!)? The vendor/src hack meant that you could compile with ANY version of Go -- that's important for dist…

I can't explain that since I'm not on the Go team. However, it's possible that they also didn't realize this hack was being relied on by people. The fact that you describe it as a hack implies it was never intentionally supported behaviour. Did you bring it up during the development of 1.5?

Re: Go 1.7 is released

#140

Post by cyphar »

lobster_johnson wrote: post #139
cyphar wrote: post #138

Earlier quoted context omitted.

> If anything, the Go people have repeatedly claimed they don't know best So why is the defacto vendoring system for the Go tooling incompatible with old Go versions (the "organic" solutions were compatible with Go versions without vendoring support because they were implemented before vendoring support was a thing!)? The vendor/src hack meant that you could compile with ANY version of Go -- that's important for dist…

I can't explain that since I'm not on the Go team. However, it's possible that they also didn't realize this hack was being relied on by people. The fact that you describe it as a hack implies it was never intentionally supported behaviour. Did you bring it up during the development of 1.5?

> The fact that you describe it as a hack implies it was never intentionally supported behaviour.

It's used by the largest Go projects that exist. So if the Go developers didn't look at what the largest Go projects do and take inspiration from that, I'm really not sure what else to say.

A hack that is used by everyone is relied upon behaviour. I wouldn't even call it a hack, it's trying to make Go's obsession with your filesystem actually usable -- why on earth does my compiler toolchain care about how my home directory is structured?

The old method still works, you just have to call the directory something other than vendor/. Which just defeats the whole point.

> Did you bring it up during the development of 1.5?

My experience with Go 1.5 was a lot of other (more serious) bugs, so I didn't have a chance to comment on that particular issue. I'm surprised nobody from Docker said anything though.

Post reply on HN