Hacker News Reader

Comment by geezerjay | Hacker News Reader

> there's an experimental feature

That's not a feature but a fix for a design problem, and currently the only fix is an experimental one.

For those seeking to invest their time learning a professional tool, that's a whole pile of no-nos that naturally point to a very hard pass.

View on HN

Go modules are extremely suitable for current work; they're as un-risky as anything labelled "experimental" could be. I've been using them for a boring professional application for about 4 months now, and there are no hassles with using them.

Same here. I've been using them in production with no issues.

> they're as un-risky as anything labelled "experimental" could be.

Yes, that's exactly the point, and why any decision to take a hard pass is more than obvious.

I don't understand what you mean, sorry

Think of it this way: if you spend time learning and using a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

Its not like there is much of a barrier there.

> a feature that is not guaranteed to be there, say, a year down the line, is that a good investment?

The Go devs have been extremely clear that Go modules is THE solution to Go packages.

If they do mean what they say then they will release a version of Go where the GOPAH nonsense is over and a fix for that design problem is not euphemistically described as experimental.

Until then, no LTS means not ready for production.

GOPATH is still being used internally by Go modules, but it's set up automatically and you never have to even know it's there. It will probably remain an option to use it as a user for a while due to backward compatibility.

I don't see how that prevents you from using Go modules.

> a fix for that design problem is not euphemistically described as experimental

The simple reason for it being "experimental" is because Go 1.11 is the first release to include it, not because of some inherent instability. Wait till February for Go 1.12 if you're so worried.

> no LTS means not ready for production

I don't know what you mean by LTS here, since every Go release as of 1.0 has been backwards compatible.

Learning Go modules is a minimal investment. It is rather hours than days.

Experimental and production are two words that should be used together.

For some people and organizations "as un-risky as anything labelled "experimental" could be" is risky enough to be automatically being disqualified from even being considered. There's the label 'experimental', so it can't be used anywhere touching the production codebase regardless of any other arguments.

A ton of projects have upgraded to work well with modules already. Seriously, it's set and forget in your zshrc / bashrc / whathaveyou.

> Seriously, it's set and forget

If that was true they would not be euphemistically labelled as experimental.

"All that is excessive is insignificant.", said Talleyrand.

By your standards c and c++ are not professional tools.

Not the OP, but uh, no neither of those are "professional" in the sense that professional should use them, regardless of the plain fact that "professionals" do use them.

Those are both garbage languages, despite their utility.

I don't understand the issue with language improvements, should we only use languages that were perfectly designed to start? Like JavaScript?

> should we only use languages that were perfectly designed to start?

If there are a myriad of languages and we do have limited time to invest mastering a language, we better use our time wisely and not waste it with those with severe design problems and designers who have refused to face those issues for years.

Reply on news.ycombinator.com