hoodedmongoose

4 ms·

1.
by hoodedmongoose 3y ago
That's a good point. You'd need to figure out what to do about persisted data the service depends on as part of the forking process. In the cases that aren't such that you described, I'd guess most of the time you'd
2.
by hoodedmongoose 3y ago
Spin up your own and own it forever would be my thought, yes. This is definitely a high cost to pay - my thought is that the bias should be much more towards modifying the existing service, but leaving the engineers that own the code to be
3.
by hoodedmongoose 3y ago
The open source model? If the away team can't get the home team to fulfill their requirements, they fork home teams code and take full ownership of it for their purposes. If they want to take updates from home team, they do so but have
4.
by hoodedmongoose 7y ago
I think it's usually more of a result of getting bored with the content than the skill of the players. Certain games never get boring for a big enough critical mass of players to keep going indefinitely (CS:GO, World of Warcraft, Leag
5.
by hoodedmongoose 11y ago
Hopefully he's not also thinking of this guy: https://en.wikipedia.org/wiki/The_Sea-Wolf#Wolf_Larsen (great book btw)
6.
by hoodedmongoose 11y ago
Thanks for the explanation, I missed that!
7.
by hoodedmongoose 11y ago
Ah okay - I didn't realize rust was guaranteeing that no one else would _modify_ the vector while an instance of that struct was around. That's pretty cool.
8.
by hoodedmongoose 11y ago
This is really exciting, and clearly more powerful than what you get in C/C++. That being said: >In a language like C++ there’s only once choice in this situation; that is to clone the vector. What about a shared_ptr to the vector?