[mirceal]

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.

[weberc2]

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]

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

> To their credit they identified early that an official solution is essential.

this made me smile.

[apta]

Not sure what you're talking about, Java's dependency management system is strictly superior.

Most important software is quite a claim as well.

[qalmakka]

It could be, but also every time I start a Gradle build I can get up and go brew some coffee, drink some and then come back to see it's still building, so it's not without its flaws.

[apta]

Ironically, I do the same with golang at my current employer. Build times are nowhere near as what's hyped. Much closer to Java, and in fact, due to Java's incremental compilation, golang is often slower.

[weberc2]

Go has incremental builds as well. I’ve been using it for years and build times are usually a couple seconds; a couple of minutes for huge projects. Are you sure that’s just build time and not some combination of downloading dependencies and/or running tests? How big is your project?

[mirceal]

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]

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

[mirceal]

good news is that it’s buckets. bad news is that it’s C++ and Java

[ilovecaching]

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]

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]

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]

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.

[mirceal]

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]

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]

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

[saturn_vk]

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]

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]

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]

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]

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]

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.