Perhaps, but I think it depends on where the Go devs are coming from. In my experience the lack of proper dependency management in older versions of Go didn't really lessen dependencies, it just made teams have to deal with annoying $GOSRC issues. But then I worked at a place where the devs used PHP (w/composer) and node before Go was introduced.
Personally I came from a C background so I tended to use deps more sparingly.
In the end it's a bit of a balancing act—lots of dependencies is a larger opportunity for these kind of supply chain attacks to affect you. Copying stuff into your repo protects you from that, but it also makes it way more likely that you'll miss security fixes, unless you're actively looking for them. Re-implementing what you need is also viable but it slows down the dev process.
I agree. Java has the same ability to quickly add deps, and in some case they can be sprawling, but it's still perfectly possible to develop complex apps without a lot of deps coming in.
It absolutely is a culture thing. I've seen many threads asking about backend frameworks in Go, and every time there were lots of answers akin to "screw framework dependencies, stdlib is more than enough".
I agree with the sibling comment and also don't understand how the title is "offensive". I literally can't think of anything that could be offensive about any term in the title or the title as a whole.
Okay, that's an interesting complaint and I can understand it. For me, the title is QUITE clear.
There's a very strong narrative in the zeitgeist that "no one" is hiring entry level jobs anymore because they're being replaced with AI. There's some pretty solid hiring data for CS grads, at least, that backs this up, even when controlling for the down economy as a whole.
So the first part "Not hiring junior engineers" is very clear. Whatever this blog post is, it's a message to companies that are making these hiring decisions.
Then, the rest follows: " won't work". It won't solve the problem you think you have.
Now that I've got your perspective, it IS possible for me to force my brain to incorrectly parse the title in a way that produces word salad, so I guess I can get it.
I had all the context I needed to easily grok it at first glance. The intended audience of the article (people who are deciding to hire fewer junior engineers) ALSO probably have that context. But it's not hard for me to believe that there are lots of people even on HN that didn't!
I agree with you that you are never "forced" to pirate; you can simply not listen to the missing album.
But many many many many excellent albums are not available for sale anywhere at any price. They essentially do not exist, except in the hands of a few collectors.
The bands themselves, the creators of said music, want their music to be heard.
The fact that they aren't available for sale or streaming is often because a rich bureaucrat can't be bothered, not for any legal reason.
Disagree on the last part, there's plenty of bands that only ever released on CD. Films and Documentaries that only went out on DVD, or even worse. Only ever shown at film festivals and never had actual releases.
It's okay for media to reach its end of life even if they are excellent. All good things come to an end. There is continually other new good things you can find instead in life.
Slack's approach is NOT good enough, because the version of the Agent that lives in Slack cannot see the context of the Agent that lives inside Cursor on my developer laptop. They might be clones with identical brains, but they can't talk to each other or compare notes.
So why can't the cursor instance on your laptop have a slack bot? I've had a slack bot on my build machine written in chicken-scheme of all things for years, I feel like the great people (or clankers?) at cursor ought to be able to figure this one out
It could! An MCP would actually be great but Slack would prefer to sell us their own AI integration product so (1) they make it difficult and more importantly (2) it's against their terms of service
We pay them a LOT of money every year and they would absolutely notice the indexing at the level we'd need to do to make this work ourselves, so the answer is "because Slack is preventing us".
Just my two-cents as a very much boots-on-the-ground infrastructure engineer. We use LLMs heavily on my team -- to write code and review PRs. Our harnesses and guardrails are very very good so we get extremely high-quality output out of most models.
But getting the humans and agents to talk together is really fragmented right now. It's annoying that the agent with the context in my locally-installed Cursor can't really participate in a Slack conversation about a PR that 'it' principally authored (and which I've signed off on).
This is a real communication problem that we face every day, and eventually someone will solve it well and I will ask our leadership to give them a lot of money.
One of the core tenets of early Go was the maxim "a little copying is better than a little dependency".
Probably because of this stance, they didn't even HAVE a dependency-management solution for years
I strongly agree the fewer dependencies the better, on average.