8 ms·

Every mainstream programming language that came out in the last 20 years has already solved this. Java, Javascript, Ruby, Python, Rust, you name it. I am baffl

Every mainstream programming language that came out in the last 20 years has already solved this. Java, Javascript, Ruby, Python, Rust, you name it. I am baffled to why Go has not figured this out and are presenting recent developments as some kind of breakthroughs - they are not. To me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. It does some things really, really well but it's far from the panacea most developers that use it think it is.

ilovecaching 8y ago
I never had any issues with the GOPATH and vendor approach, but I have experience with using a huge monorepo, so I never had expectations that it would be any different. But go mod is great, and it is very different than cargo, pip, npm, etc. I don't think they are claiming it's a spiritual revolution, but it solves the problems people who needed traditional package versioning where having in an elegant and Goish way. Go is also far from experimental. It has areas where it could be better, but it's a panacea compared to writing Java in an IDE with Maven for a living.
- mirceal 8y ago
  given the option I will take java any day or night. we developers like to experiment things and put them on our resumes, but once the kool-aid is gone very few things stand the test of time. imho, go wouldn’t be a thing if it didn’t have [initial] backing from google.
  - ilovecaching 8y ago
    Go grew as a result of the open source ecosystem that grew around Docker. Google has backed plenty of other languages that have gone nowhere, so I think it's a fallacy to claim that's why Go has risen in popularity. If anything it was containerization and maybe the fact that Ken and Pike were involved more than the Google brand. Go is also just really great. You don't need an IDE or a big crusty language to write good software. Go is small, compiles quickly, runs efficiently, is easy to teach, and has great tooling that lets you get up in running in just a few minutes. The ecosystem is centered around open source, the Go project itself including the name, logos, and specification are open source, and the Go conference in Denver is fantastic. Go is not kool-aid.
    - mirceal 8y ago
      we’ll agree to disagree here. I believe it’s kool-aid and unless you use it in one of the few niches where it shines it’s a disaster waiting to happen. the Google brand helped immensely and containers/docker are their own flavor of kool-aid. The art of actually thinking about how you’ll package and deploy your software is lost. Put it in a docker container and fuck it. Fuck security, fuck ever understanding what you’re running, ship it fast/ship it now. My test for docker and its own flavor of koolaid is to ask its supportes what a container is. 95% don’t know. Yep
- mirceal 8y ago
  if you didn’t experience issues with “vendoring” you were either: extremely lucky, work on a very small codebase and/or on a very small team. to me, only the idea of using a git submodule pointed to a repo that has all my dependencies is... repeat after me: a source control system is not a dependency management system.
  - ilovecaching 8y ago
    Maybe the first, but monorepos are used company wide and contain millions of lines of code. The monorepo approach and vendoring does work, and there are a lot of advantages to having everything work on each revision, you just need to be conscious of it.
    - mirceal 8y ago
      hah. no. unless you have proper build/release/test/deploy state-of-the-art tooling the monorepo approach is a disaster. google and other bigco have it? do you? there is a reason we modularize and version things in software. in the context in which you pull in external libraries you don’t control, using a monorepo is madness.
weberc2 8y ago
Go's modules are quite a lot nicer than Java's or Python's dependency management / build tools. JavaScript only recently got its act together. Can't speak to Ruby, but Rust is the only one that got it right the first time. Dependency management is only recently a "solved problem". > Go me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. It does some things really, really well but it's far from the panacea most developers that use it think it is. Go is definitely a production-ready language, and indeed it powers much of the most important software that has been written since it went 1.0 (particularly in the Cloud and DevOps spaces). It's not perfect, but it's really, really good and improving steadily.
- geodel 8y ago
  > Rust is the only one that got it right the first time. Not really the first time. They made attempts before. Dumped it along with person who created earlier solution and then developed current solution. To their credit they identified early that an official solution is essential.
  - mirceal 8y ago
    > To their credit they identified early that an official solution is essential. this made me smile.
- mirceal 8y ago
  nah. we’ll agree to disagree on this one. most devops cloud stuff is written in python. you know what’s written in go? terraform. i have yet to meet someone that has actually leveraged terraform in a production setting and does not think it should be banned. what else? k8s? the favorite poster boy of our generation. solving problems you don’t have and replacing figuring out how to deploy your stuff with the anguish of keeping the cluster up and uptodate.
  - apta 8y ago
    I'm curious as to how much golang is even used inside Google itself, since they actually have to write maintainable code that does nontrivial stuff, and not follow the latest fads
saturn_vk 8y ago
Not sure I would put python out Javascript as Languages that have solved dependency management. Even Java has shortcomings in this department. Which is why I'm baffled by your comment.
- mirceal 8y ago
  compared to go? it’s state of the art. npm is a huuge succes. pypi is real. for java developers maven central is living the dream. go? pull shit from git hub and pretend that it’s acceptable and works
apta 8y ago
It's how basically the entire language is, they keep reinventing the wheel, only in a subpar way and market it as if it's some breakthrough, and people who don't know better drink the Koolaid. golang wouldn't have gone anywhere if it didn't have the Google name behind it. Did you even notice how verbose the testing code was in that post?
- mirceal 8y ago
  we should form a club or something. we’ll call it the gopher 8th light seekers and drink sparkling water + bitch about go while the rest invent the future. in go :)
  - apta 8y ago
    hah. What kind of future are you talking about? :P It still seems that Java and C# and python are dominant in their respective areas, and golang being relegated to devops stuff, those guys can deal with all the shortcomings of the language because they don't know better, but at least it's not infiltrating other areas. Ironic that the golang authors wrote it as a C++ replacement and it completely flopped there, just shows how out of touch from reality they are.
    - mirceal 8y ago
      the “future”. the one with flying cars and strong AI and aliens. where everything compiles instantly and we laugh at peasants that worry about dependency management and sanity.

ilovecaching 8y ago

I never had any issues with the GOPATH and vendor approach, but I have experience with using a huge monorepo, so I never had expectations that it would be any different. But go mod is great, and it is very different than cargo, pip, npm, etc. I don't think they are claiming it's a spiritual revolution, but it solves the problems people who needed traditional package versioning where having in an elegant and Goish way. Go is also far from experimental. It has areas where it could be better, but it's a panacea compared to writing Java in an IDE with Maven for a living.

mirceal 8y ago
given the option I will take java any day or night. we developers like to experiment things and put them on our resumes, but once the kool-aid is gone very few things stand the test of time. imho, go wouldn’t be a thing if it didn’t have [initial] backing from google.
- ilovecaching 8y ago
  Go grew as a result of the open source ecosystem that grew around Docker. Google has backed plenty of other languages that have gone nowhere, so I think it's a fallacy to claim that's why Go has risen in popularity. If anything it was containerization and maybe the fact that Ken and Pike were involved more than the Google brand. Go is also just really great. You don't need an IDE or a big crusty language to write good software. Go is small, compiles quickly, runs efficiently, is easy to teach, and has great tooling that lets you get up in running in just a few minutes. The ecosystem is centered around open source, the Go project itself including the name, logos, and specification are open source, and the Go conference in Denver is fantastic. Go is not kool-aid.
  - mirceal 8y ago
    we’ll agree to disagree here. I believe it’s kool-aid and unless you use it in one of the few niches where it shines it’s a disaster waiting to happen. the Google brand helped immensely and containers/docker are their own flavor of kool-aid. The art of actually thinking about how you’ll package and deploy your software is lost. Put it in a docker container and fuck it. Fuck security, fuck ever understanding what you’re running, ship it fast/ship it now. My test for docker and its own flavor of koolaid is to ask its supportes what a container is. 95% don’t know. Yep
mirceal 8y ago
if you didn’t experience issues with “vendoring” you were either: extremely lucky, work on a very small codebase and/or on a very small team. to me, only the idea of using a git submodule pointed to a repo that has all my dependencies is... repeat after me: a source control system is not a dependency management system.
- ilovecaching 8y ago
  Maybe the first, but monorepos are used company wide and contain millions of lines of code. The monorepo approach and vendoring does work, and there are a lot of advantages to having everything work on each revision, you just need to be conscious of it.
  - mirceal 8y ago
    hah. no. unless you have proper build/release/test/deploy state-of-the-art tooling the monorepo approach is a disaster. google and other bigco have it? do you? there is a reason we modularize and version things in software. in the context in which you pull in external libraries you don’t control, using a monorepo is madness.

weberc2 8y ago

Go's modules are quite a lot nicer than Java's or Python's dependency management / build tools. JavaScript only recently got its act together. Can't speak to Ruby, but Rust is the only one that got it right the first time. Dependency management is only recently a "solved problem". > Go me, and I'm not trying to be disrespectful here, because of the shortcomings it has, Go is in the experimental/keep an eye on bucket. It does some things really, really well but it's far from the panacea most developers that use it think it is. Go is definitely a production-ready language, and indeed it powers much of the most important software that has been written since it went 1.0 (particularly in the Cloud and DevOps spaces). It's not perfect, but it's really, really good and improving steadily.

geodel 8y ago
> Rust is the only one that got it right the first time. Not really the first time. They made attempts before. Dumped it along with person who created earlier solution and then developed current solution. To their credit they identified early that an official solution is essential.
- mirceal 8y ago
  > To their credit they identified early that an official solution is essential. this made me smile.
mirceal 8y ago
nah. we’ll agree to disagree on this one. most devops cloud stuff is written in python. you know what’s written in go? terraform. i have yet to meet someone that has actually leveraged terraform in a production setting and does not think it should be banned. what else? k8s? the favorite poster boy of our generation. solving problems you don’t have and replacing figuring out how to deploy your stuff with the anguish of keeping the cluster up and uptodate.
- apta 8y ago
  I'm curious as to how much golang is even used inside Google itself, since they actually have to write maintainable code that does nontrivial stuff, and not follow the latest fads

saturn_vk 8y ago

Not sure I would put python out Javascript as Languages that have solved dependency management. Even Java has shortcomings in this department. Which is why I'm baffled by your comment.

mirceal 8y ago
compared to go? it’s state of the art. npm is a huuge succes. pypi is real. for java developers maven central is living the dream. go? pull shit from git hub and pretend that it’s acceptable and works

apta 8y ago

It's how basically the entire language is, they keep reinventing the wheel, only in a subpar way and market it as if it's some breakthrough, and people who don't know better drink the Koolaid. golang wouldn't have gone anywhere if it didn't have the Google name behind it. Did you even notice how verbose the testing code was in that post?

mirceal 8y ago
we should form a club or something. we’ll call it the gopher 8th light seekers and drink sparkling water + bitch about go while the rest invent the future. in go :)
- apta 8y ago
  hah. What kind of future are you talking about? :P It still seems that Java and C# and python are dominant in their respective areas, and golang being relegated to devops stuff, those guys can deal with all the shortcomings of the language because they don't know better, but at least it's not infiltrating other areas. Ironic that the golang authors wrote it as a C++ replacement and it completely flopped there, just shows how out of touch from reality they are.
  - mirceal 8y ago
    the “future”. the one with flying cars and strong AI and aliens. where everything compiles instantly and we laugh at peasants that worry about dependency management and sanity.