HN user
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 be stuck trying to get your changes merged by the home team - something I think is much more desirable for long term code quality (in theory)
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 empowered to figure out how to do this. Rather than having management say you have to review this away teams code, deal with it
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 to handle the merging. If they want to, they can try to get home team to take their changes, but that's at home teams full discretion.
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, League of Legends, Fortnite, etc). Many of these games have matchmaking system that try to put players of similar skill together. These systems are sometimes flawed, but can generally work well enough to soften the experience of picking up the game for the first time.
Hopefully he's not also thinking of this guy: https://en.wikipedia.org/wiki/The_Sea-Wolf#Wolf_Larsen
(great book btw)
Thanks for the explanation, I missed that!
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.
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?