4 ms·

> 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

> 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.

llimllib 8y ago
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.
- weberc2 8y ago
  Same here. I've been using them in production with no issues.
- geezerjay 8y ago
  > 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.
  - llimllib 8y ago
    I don't understand what you mean, sorry
    - Cyph0n 8y ago
      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?
      - throwaway2048 8y ago
        Its not like there is much of a barrier there.
      - AsyncAwait 8y ago
        > 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.
        geezerjay 8y ago
        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.
        AsyncAwait 8y ago
        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.
      - _ph_ 8y ago
        Learning Go modules is a minimal investment. It is rather hours than days.
    - threeseed 8y ago
      Experimental and production are two words that should be used together.
    - PeterisP 8y ago
      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.
  - danielhlockard 8y ago
    A ton of projects have upgraded to work well with modules already. Seriously, it's set and forget in your zshrc / bashrc / whathaveyou.
    - geezerjay 8y ago
      > Seriously, it's set and forget If that was true they would not be euphemistically labelled as experimental.
grumpydba 8y ago
"All that is excessive is insignificant.", said Talleyrand. By your standards c and c++ are not professional tools.
- carapace 8y ago
  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.
sieabahlpark 8y ago
I don't understand the issue with language improvements, should we only use languages that were perfectly designed to start? Like JavaScript?
- geezerjay 8y ago
  > 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.

llimllib 8y ago

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.

weberc2 8y ago
Same here. I've been using them in production with no issues.
geezerjay 8y ago
> 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.
- llimllib 8y ago
  I don't understand what you mean, sorry
  - Cyph0n 8y ago
    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?
    - throwaway2048 8y ago
      Its not like there is much of a barrier there.
    - AsyncAwait 8y ago
      > 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.
      - geezerjay 8y ago
        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.
        AsyncAwait 8y ago
        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.
    - _ph_ 8y ago
      Learning Go modules is a minimal investment. It is rather hours than days.
  - threeseed 8y ago
    Experimental and production are two words that should be used together.
  - PeterisP 8y ago
    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.
- danielhlockard 8y ago
  A ton of projects have upgraded to work well with modules already. Seriously, it's set and forget in your zshrc / bashrc / whathaveyou.
  - geezerjay 8y ago
    > Seriously, it's set and forget If that was true they would not be euphemistically labelled as experimental.

grumpydba 8y ago

"All that is excessive is insignificant.", said Talleyrand. By your standards c and c++ are not professional tools.

carapace 8y ago
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.

sieabahlpark 8y ago

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

geezerjay 8y ago
> 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.