6 ms·

I thought the whole point of go was to remove extraneous features and provide a completely minimal programming language. The argument being that all those extr

I thought the whole point of go was to remove extraneous features and provide a completely minimal programming language. The argument being that all those extra features are a source of bugs. Nevertheless, modules and try... it seems like it’s just an effort to add them all back in again. Surely if this happens go will be indistinguishable from all the other languages it was designed to be different from?

lkramer 7y ago
Speaking from a personal perspective, modules feels like a real improvement, mostly because GOPATH always felt a bit iffy. I share your concerns, especially around generics.
deleted 7y ago
[deleted]
sudhirj 7y ago
Try was rejected and modules are awesome in my opinion. Easily the best dependency management I’ve worked with, across Ruby (Gems), Python (PIP), Java (Gradle/Maven) etc. Up to this point, the ratio of useful enhancements to unnecessary cruft has heavily skewed towards usefulness. The post links to a new questionnaire the core wants all change proposers to answer - the questions are pretty good and force a bit of intense soul searching for everyone asking for a change. That will probably stifle ideas a bit, but resisting change by default is what we want out of this language anyway.
- eberkund 7y ago
  Those are all awful dependency management examples. I won't say Go dependency management is terrible, but it's certainly not awesome. At least to someone who has used PHP (Composer), Rust (Cargo), JavaScript (NPM), C# (NuGet).
  - sa46 7y ago
    I don't think NPM is an example of a good dependency management system. It works, but it doesn't spark joy. Some issues I've run into: - npm install ignores package-lock.json and uses package.json. The work-around is to use npm ci. https://stackoverflow.com/a/45566871/30900 https://stackoverflow.com/a/45566871/30900 - Flakiness. An acceptable solution to npm difficulties is `rm -rf node_modules; npm i`. Admittedly, this has improved a lot in recent years. NPM also inherits the design preferences of the JS ecosystem. - Simple packages have deep dependency graphs. - Functionality is spread across multiple packages, sometimes at a granularity of a function per package. - If you want types, you roughly double the number of packages you need.
    - thrwaway69 7y ago
      Half the issues you mentioned are due to the ecosystem/community (one liner packages and deep dependency isn't fault of npm but it might be an unintentional result of how easy it was/is to publish and reuse packages) and the other half I don't notice by using yarn/pnpm. Getting types is optional and only required if you use typescript which you don't have to. It does improve the editor experience for vanilla js but those are put under dev dependency. There are a lot of things that can be improved though. Lot of packages put their config inside package.json which is honestly messy. The whole script part is a bit restricting. Better approach would have been to follow how mix (elixir) does it. Json is limiting as a format, no comments. Like you mentioned, it inherits the mentality of js ecosystem. It doesn't feel part of node but a separate piece of its own.
  - sosodev 7y ago
    Why are gems awful? It’s one of the best imo
    - sudhirj 7y ago
      Gems are fine-ish... they rubygems infrastructure is really slow, though. Maybe github packages will be better. And the ton or native code compilation sucks a bit, especially when compared to Go. CGO isn’t all roses, but it’s still a bit less common because you can get comparable performance with pure Go.
  - jayd16 7y ago
    Why is gradle/maven significantly different than Nuget as far as dependency management goes? The only major difference is Gradle and Maven also handle a lot of the build management as well.
- simiones 7y ago
  I was curious - what's wrong with Maven that is improved in Go modules? I personally found Maven much more friendly, since there are no odd interactions with your source-control solution, you get all relevant details in the Maven pom.xml. I also find this idea of relying on semver, especially with Go's insistence on renaming packages for major version changes, to be very unpleasant and brittle, especially for internal packages.
  - tikkabhuna 7y ago
    One idea I like is to be able to depend on a branch. In Java it would be nice to depend on a branch, rather than dealing with snapshots. Obviously that comes at the cost of coupling with the VCS. Maybe its not worth it. Interesting idea though.
    - LadyCailin 7y ago
      The idea of a “branch” is not particularly novel, and I think any useful VCS will have an equivalence. I’d be perfectly fine with relying on that as much as I do any other aspect of a package manager.
    - simiones 7y ago
      Isn't that much harder to do with Go mod than with Maven? With Maven, you can define your own versioning scheme and easily include the branch as a component of the version "number". In Go mod, as far as I can tell, you have to have a Semver vMAJOR.MINOR.PATCH version, which is much more difficult to adjust for short-lived branches.
  - sudhirj 7y ago
    Each library needs to be build a JAR, which isn't the case in Go - in Go you just put in the code URL (git repo / branch / sha1) and you have it. Also locks the dependency to that sha1, and crypto verifies it. So you get all the benefits of building an artefact, hash verification and central repo without having to do any of the work.
    - 7y ago
pjmlp 7y ago
Programming languages are products just like anything else in the software industry. Either they adapt or eventually fade away. Hence why we get this reboot cycles where new languages get introduced as revolution against the establishment, and a couple of years later are just as feature rich as the ones they were "fighting" against.
- deleted 7y ago
  [deleted]
- chooseaname 7y ago
  > Either they adapt or eventually fade away. The problem is devs are like, "This is a great language! I wish it had all these other feature from this other language I've been using." Well, just go use that other language.
  - pjmlp 7y ago
    That is the "eventually fade away part" of my remark.
  - AnimalMuppet 7y ago
    But they want those features without the complexity of the other language. So "just go use that other language" doesn't satisfy them, either. But at least your response makes it so that they're whining about two languages, instead of just one...
  - cheese4242 7y ago
    Exactly. Sadly seems inevitable that all languages will eventually become bloated due to this.
- AnimalMuppet 7y ago
  By "revolution against the establishment", I take you to mean "revolution against the complexity of existing tools". Meaning, a simpler tool. You can build a tool that will do 80% of what the existing tool does, with 20% of the complexity (or maybe even 90/10). And that's great... until you need the ability to do that last 10 or 20%. Then the simple tool has trapped you. But by then, you've got a lot of code in the new tool. So what you want is a way to do whatever part of the last 10 or 20% of power that you need for your problem. "It's just a small addition!" But there's someone else who needs a different part of the last 10 or 20%, and wants to add that part... And so you wind up with the new tool becoming as complex as the old tool. And then, as you say, the cycle repeats. I think that if a tool is going to be an "80% of the power at 20% of the complexity" tool, and remain that, then it has to have an escape mechanism. You've written your 100,000 lines of simple code, and you need 50 lines in a more powerful tool, well, there's a clean way to use code written in a more powerful language for those 50 lines. Then the language can remain one that just has 20% of the complexity (if those in charge of the language can maintain their vision and their stubbornness).
misrab 7y ago
As much as I hate to say it...I completely agree. I'd love to see the reasoning behind breaking minimalist principles; otherwise it looks like complexity drift to me.
- tgv 7y ago
  The proposals don't change the language, it's just a few very sensible warnings and the tiniest, sensible extension of constant expressions.
chooseaname 7y ago
I agree. I strongly desire the Go team to keep the language as tiny as it is.
- cheese4242 7y ago
  Same here. There are tons of other languages to choose from if you don't like what makes Go unique. People seem obsessed with making all languages homogeneous rather than appreciating what makes them different.
coldtea 7y ago
>Nevertheless, modules and try... it seems like it’s just an effort to add them all back in again. Keyword is "extraneous features". 10 years of hard experience showed neither of modules nor a better error handling story (not necessarily "try") are "extraneous". On the contrary, extraneous is what we get when everybody implements their own ad-hoc solution for those.

lkramer 7y ago

Speaking from a personal perspective, modules feels like a real improvement, mostly because GOPATH always felt a bit iffy. I share your concerns, especially around generics.

deleted 7y ago

[deleted]

sudhirj 7y ago

Try was rejected and modules are awesome in my opinion. Easily the best dependency management I’ve worked with, across Ruby (Gems), Python (PIP), Java (Gradle/Maven) etc. Up to this point, the ratio of useful enhancements to unnecessary cruft has heavily skewed towards usefulness. The post links to a new questionnaire the core wants all change proposers to answer - the questions are pretty good and force a bit of intense soul searching for everyone asking for a change. That will probably stifle ideas a bit, but resisting change by default is what we want out of this language anyway.

eberkund 7y ago
Those are all awful dependency management examples. I won't say Go dependency management is terrible, but it's certainly not awesome. At least to someone who has used PHP (Composer), Rust (Cargo), JavaScript (NPM), C# (NuGet).
- sa46 7y ago
  I don't think NPM is an example of a good dependency management system. It works, but it doesn't spark joy. Some issues I've run into: - npm install ignores package-lock.json and uses package.json. The work-around is to use npm ci. https://stackoverflow.com/a/45566871/30900 https://stackoverflow.com/a/45566871/30900 - Flakiness. An acceptable solution to npm difficulties is `rm -rf node_modules; npm i`. Admittedly, this has improved a lot in recent years. NPM also inherits the design preferences of the JS ecosystem. - Simple packages have deep dependency graphs. - Functionality is spread across multiple packages, sometimes at a granularity of a function per package. - If you want types, you roughly double the number of packages you need.
  - thrwaway69 7y ago
    Half the issues you mentioned are due to the ecosystem/community (one liner packages and deep dependency isn't fault of npm but it might be an unintentional result of how easy it was/is to publish and reuse packages) and the other half I don't notice by using yarn/pnpm. Getting types is optional and only required if you use typescript which you don't have to. It does improve the editor experience for vanilla js but those are put under dev dependency. There are a lot of things that can be improved though. Lot of packages put their config inside package.json which is honestly messy. The whole script part is a bit restricting. Better approach would have been to follow how mix (elixir) does it. Json is limiting as a format, no comments. Like you mentioned, it inherits the mentality of js ecosystem. It doesn't feel part of node but a separate piece of its own.
- sosodev 7y ago
  Why are gems awful? It’s one of the best imo
  - sudhirj 7y ago
    Gems are fine-ish... they rubygems infrastructure is really slow, though. Maybe github packages will be better. And the ton or native code compilation sucks a bit, especially when compared to Go. CGO isn’t all roses, but it’s still a bit less common because you can get comparable performance with pure Go.
- jayd16 7y ago
  Why is gradle/maven significantly different than Nuget as far as dependency management goes? The only major difference is Gradle and Maven also handle a lot of the build management as well.
simiones 7y ago
I was curious - what's wrong with Maven that is improved in Go modules? I personally found Maven much more friendly, since there are no odd interactions with your source-control solution, you get all relevant details in the Maven pom.xml. I also find this idea of relying on semver, especially with Go's insistence on renaming packages for major version changes, to be very unpleasant and brittle, especially for internal packages.
- tikkabhuna 7y ago
  One idea I like is to be able to depend on a branch. In Java it would be nice to depend on a branch, rather than dealing with snapshots. Obviously that comes at the cost of coupling with the VCS. Maybe its not worth it. Interesting idea though.
  - LadyCailin 7y ago
    The idea of a “branch” is not particularly novel, and I think any useful VCS will have an equivalence. I’d be perfectly fine with relying on that as much as I do any other aspect of a package manager.
  - simiones 7y ago
    Isn't that much harder to do with Go mod than with Maven? With Maven, you can define your own versioning scheme and easily include the branch as a component of the version "number". In Go mod, as far as I can tell, you have to have a Semver vMAJOR.MINOR.PATCH version, which is much more difficult to adjust for short-lived branches.
- sudhirj 7y ago
  Each library needs to be build a JAR, which isn't the case in Go - in Go you just put in the code URL (git repo / branch / sha1) and you have it. Also locks the dependency to that sha1, and crypto verifies it. So you get all the benefits of building an artefact, hash verification and central repo without having to do any of the work.
  - 7y ago

pjmlp 7y ago

Programming languages are products just like anything else in the software industry. Either they adapt or eventually fade away. Hence why we get this reboot cycles where new languages get introduced as revolution against the establishment, and a couple of years later are just as feature rich as the ones they were "fighting" against.

deleted 7y ago
[deleted]
chooseaname 7y ago
> Either they adapt or eventually fade away. The problem is devs are like, "This is a great language! I wish it had all these other feature from this other language I've been using." Well, just go use that other language.
- pjmlp 7y ago
  That is the "eventually fade away part" of my remark.
- AnimalMuppet 7y ago
  But they want those features without the complexity of the other language. So "just go use that other language" doesn't satisfy them, either. But at least your response makes it so that they're whining about two languages, instead of just one...
- cheese4242 7y ago
  Exactly. Sadly seems inevitable that all languages will eventually become bloated due to this.
AnimalMuppet 7y ago
By "revolution against the establishment", I take you to mean "revolution against the complexity of existing tools". Meaning, a simpler tool. You can build a tool that will do 80% of what the existing tool does, with 20% of the complexity (or maybe even 90/10). And that's great... until you need the ability to do that last 10 or 20%. Then the simple tool has trapped you. But by then, you've got a lot of code in the new tool. So what you want is a way to do whatever part of the last 10 or 20% of power that you need for your problem. "It's just a small addition!" But there's someone else who needs a different part of the last 10 or 20%, and wants to add that part... And so you wind up with the new tool becoming as complex as the old tool. And then, as you say, the cycle repeats. I think that if a tool is going to be an "80% of the power at 20% of the complexity" tool, and remain that, then it has to have an escape mechanism. You've written your 100,000 lines of simple code, and you need 50 lines in a more powerful tool, well, there's a clean way to use code written in a more powerful language for those 50 lines. Then the language can remain one that just has 20% of the complexity (if those in charge of the language can maintain their vision and their stubbornness).

misrab 7y ago

As much as I hate to say it...I completely agree. I'd love to see the reasoning behind breaking minimalist principles; otherwise it looks like complexity drift to me.

tgv 7y ago
The proposals don't change the language, it's just a few very sensible warnings and the tiniest, sensible extension of constant expressions.

chooseaname 7y ago

I agree. I strongly desire the Go team to keep the language as tiny as it is.

cheese4242 7y ago
Same here. There are tons of other languages to choose from if you don't like what makes Go unique. People seem obsessed with making all languages homogeneous rather than appreciating what makes them different.

coldtea 7y ago

>Nevertheless, modules and try... it seems like it’s just an effort to add them all back in again. Keyword is "extraneous features". 10 years of hard experience showed neither of modules nor a better error handling story (not necessarily "try") are "extraneous". On the contrary, extraneous is what we get when everybody implements their own ad-hoc solution for those.