5 ms·
This article actually made the issue finally click for me: Go is having trouble solving this problem because it has more going on in the global environment, lik
by JeremyBanks 9y ago
This article actually made the issue finally click for me: Go is having trouble solving this problem because it has more going on in the global environment, like its ancestor languages, and unlike more modern languages. They need to come up with a complicated framework to reign in their spooky action at a distance, because they have lots of implicit global relationships where we might prefer more explicit and local ones.
Yikes.
- ithkuil 9y ago> where we might prefer more explicit and local ones. could you expand on this? who is "we" and what are those explicit and local relationships? are you talking about an opensource ecosystem or a private enterprise?
- JeremyBanks 9y agoIn this case I mean open-source communities and the companies that heavily rely on them.
- ithkuil 9y agoI'm not sure I understand your point. It seems you're implying (please correct me if I'm wrong) that ecosystems of modern open-source languages are more local, more tightly coupled and having people working in concert towards a common goal. In my experience this is often what happens when a new community is spawned. E.g. when nodejs started it was there was always one single implementation of that thing I needed and it was reasonably up to date with the rest of the things around it (including the runtime environment, of which there was only one or perhaps two mayor versions of). As time went on more people started to contributing, often with different levels of commitment. Often "modern" gets conflated with "young". Almost by definition, young communities don't develop the same kind of problems of mature communities, yet.
- matt_m 9y agoI think the main example in the article is talking about incompatible types, not global variables, so the issues apply more or less the same in any language (Java, Python, C++, etc), since there is generally no guarantee that one version of a library can work with objects of another version of a library at run time (since the private fields may be different between the two versions). There's a brief note on singleton problems, so that might be an issue with code that uses them more, but the example given (listening on port 80) is also more or less language independent, since there is only one port 80 whether your code uses singletons or not.