[spullara]

It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed. Since it was obvious from day 1 to most people from other ecosystems maybe they shouldn't have so much NIH. We'll likely get exceptions and generics soon as well. What a waste of time.

[tracker1]

It's also important to get a number of other things worked out and discuss possibilities. The go process in terms of using a baseline directory with git sources seems to be a very pragmatic approach to start from. I started playing with node before npm was in the box. There were some competing ideas and eventually one won out.

I think that having a system in place with the language may be a better option than a company with its' own motivations and needs separated from the language/runtime/platform.

As to generics, I think you may well find generics in the future. I feel that most of the resistance was in order to better support core language features. I can't think of any languages (I'm no expert) that started with generics support, so I'd be surprised if this wasn't a go 2.x goal.

For exceptions, I think that the go solution works. Similar to the callback interfaces in node, it puts errors in your face, which isn't a bad thing. I mainly contrast this with node, as it's another language/platform that has grown a LOT but also relatively recent.

You can compare the progress of node, go and others to say python2/3, C#, Java and others. I think go progress has been great by comparison, and pragmatic choices have ruled out.

[chimeracoder]

> It is amazing that it took them this long to realize they were entirely wrong about how dependencies should be distributed.

It didn't take "this long"; the Go team openly admitted the need for a better approach at the very first GopherCon back in 2014, nearly five years ago. (That was not the first time, either).

It takes time to do all that work.

[spullara]

If you realize something is wrong a couple years in and it takes 5+ years to fix it, then that seems like a long time to me.

[geodel]

In between community developed many solutions when official solution was lacking. So it's not like people were twiddling their thumbs for 5 years. Also check how long Java took to get official module solution. Work on that started in 2008 and solution was delivered in 2017.

[spullara]

Hah. They don't have one now. The de facto solution is Maven. Java itself doesn't actually have a module system like the one discussed for Go. It is merely a access control system rather than a dependency system.

To be clear, I give the Java people shit about it all the time and was on the original Java module system JSR that was supposed to deliver it. In the end, the Sun people yanked the dependency part and shipped a module system that is really only useful to the JDK.

[pjmlp]

In Java's case, lets not forget the work started before Oracle's acquisition and there were the political wars from the OSGi field as well.

[emersion]

The way dependencies are distributed (ie. downloaded) won't change a lot, and as they say the distributed model is very important. Maybe you mean how dependencies are installed by the go command?

(As a side note, I don't think there are any plans for exceptions -- for good)

[spullara]

They will be globally indexed, signed and versioned rather than downloaded at HEAD from a random repository. I'd say that is pretty different.

Also, https://go.googlesource.com/proposal/+/master/design/go2draf...