4 ms·

It's a good point. I've had it as a worry in the back of my mind for a while now, the 'best' solution for now seems to be linking to your own personal forks of

It's a good point. I've had it as a worry in the back of my mind for a while now, the 'best' solution for now seems to be linking to your own personal forks of projects you depend on.

revscat 13y ago
That's a pretty heavy solution.
- Svip 13y ago
  Not for a video game.
- potatolicious 13y ago
  Sure, but it's also a common solution outside of Go. I write iPhone apps and we have all of our major dependencies forked, because at some point you're going to butt up against the limits of what your lib does. Even just redirecting a git submodule at a later point is a minor brainfuck - so nowadays we just instinctively fork as soon as we decide to pull it in as a dependency. What I really want to know is why they chose Go in the first place. Go isn't a game development language and it has little to no support, documentation, or just plain old previous community experience in the gaming context. This feels like the classic software development of putting the technology ahead of the product - using a tool because it's cool, rather than using it because it's the best thing for the job. It's all about shipping, people. Use whatever you need to you can ship what you want, when you want to, at the quality and reliability you desire.
  - pjmlp 13y ago
    > Sure, but it's also a common solution outside of Go. In the C and C++ world, yes. Because they lack the software repositories many mainstream languages have. The problem is that we got used to Maven, Ivy, CPAN, Gems, eggs, NuGet, ...
    - dagw 13y ago
      Back when I worked on a large commercial Python project, we did the same thing. All dependencies where on our server and that's the only place we grabbed them from when building a new release.
      - pjmlp 13y ago
        I think the main problem is that we got used to these dependency tools, and many developers coming to Go don't have experience how development was done before they came into existence.
        rurounijones 13y ago
        Or the fact that many developers look at the previous methods and quite rightly say "That is a hideous method, we have moved on (and IMHO improved) from that, why the hell has a new language reverted to old and busted methods" As I said in another comment regarding Go. If any company has the ability to create a stable, maintained CPAN / rubygems equivalent for the Go language, it would be Google. Which just makes the lack of it more jarring (although I see the arguments that Go is designed for Google and may not fit other's ideas of what important features are)
  - rubinelli 13y ago
    Why Go? Because it's new and cool, of course. The whole Haunts project already had serious problems; this was just the final nail in the coffin, if you'll excuse the pun: http://www.joystiq.com/2012/10/24/haunts-anatomy-of-a-kickstarter-collapse/ http://www.joystiq.com/2012/10/24/haunts-anatomy-of-a-kickst...
Svip 13y ago
Isn't that usually what people do in developments? They obtain a copy or fork of a library, and only update it at their discretion? This seems like an oversight by the developers rather than Go. I realise that since Go supports this, it is encouraging to simply do that, but it isn't wise in the long term. For instance, I've had some issues with Go-SDL, because one of the forks became unreliable. I decided eventually to simply fork another of the forks myself to overcome all these issues, and simply update my fork with commits to the main project whenever they came around.

It's a good point. I've had it as a worry in the back of my mind for a while now, the 'best' solution for now seems to be linking to your own personal forks of projects you depend on.

revscat 13y ago

That's a pretty heavy solution.

Svip 13y ago
Not for a video game.
potatolicious 13y ago
Sure, but it's also a common solution outside of Go. I write iPhone apps and we have all of our major dependencies forked, because at some point you're going to butt up against the limits of what your lib does. Even just redirecting a git submodule at a later point is a minor brainfuck - so nowadays we just instinctively fork as soon as we decide to pull it in as a dependency. What I really want to know is why they chose Go in the first place. Go isn't a game development language and it has little to no support, documentation, or just plain old previous community experience in the gaming context. This feels like the classic software development of putting the technology ahead of the product - using a tool because it's cool, rather than using it because it's the best thing for the job. It's all about shipping, people. Use whatever you need to you can ship what you want, when you want to, at the quality and reliability you desire.
- pjmlp 13y ago
  > Sure, but it's also a common solution outside of Go. In the C and C++ world, yes. Because they lack the software repositories many mainstream languages have. The problem is that we got used to Maven, Ivy, CPAN, Gems, eggs, NuGet, ...
  - dagw 13y ago
    Back when I worked on a large commercial Python project, we did the same thing. All dependencies where on our server and that's the only place we grabbed them from when building a new release.
    - pjmlp 13y ago
      I think the main problem is that we got used to these dependency tools, and many developers coming to Go don't have experience how development was done before they came into existence.
      - rurounijones 13y ago
        Or the fact that many developers look at the previous methods and quite rightly say "That is a hideous method, we have moved on (and IMHO improved) from that, why the hell has a new language reverted to old and busted methods" As I said in another comment regarding Go. If any company has the ability to create a stable, maintained CPAN / rubygems equivalent for the Go language, it would be Google. Which just makes the lack of it more jarring (although I see the arguments that Go is designed for Google and may not fit other's ideas of what important features are)
- rubinelli 13y ago
  Why Go? Because it's new and cool, of course. The whole Haunts project already had serious problems; this was just the final nail in the coffin, if you'll excuse the pun: http://www.joystiq.com/2012/10/24/haunts-anatomy-of-a-kickstarter-collapse/ http://www.joystiq.com/2012/10/24/haunts-anatomy-of-a-kickst...

Svip 13y ago

Isn't that usually what people do in developments? They obtain a copy or fork of a library, and only update it at their discretion? This seems like an oversight by the developers rather than Go. I realise that since Go supports this, it is encouraging to simply do that, but it isn't wise in the long term. For instance, I've had some issues with Go-SDL, because one of the forks became unreliable. I decided eventually to simply fork another of the forks myself to overcome all these issues, and simply update my fork with commits to the main project whenever they came around.