If there won’t be too many different plugins, maybe having a feature for each plugin would work. Then you could use --features=...
when compiling to select the plugins you need.
If there won’t be too many different plugins, maybe having a feature for each plugin would work. Then you could use --features=...
when compiling to select the plugins you need.
I like to look at Issues and Pull Requests on Github if a crate wasn’t updated for multiple years. If there are already problems like unsoundness, deprecation, or breaking bugs mentioned with no reaction shown by the maintainer, that is a good sign to look elsewhere instead. If everything seems fine and the crate isn’t very complex or security-critical, it is probably not an issue.
I am also very interested in seeing what the next generation of Rust-inspired languages will look like, and not because I am dissatisfied with Rust today. Rust has significantly raised the bar of how a good programming needs to work and any new language in the systems programming area (and beyond) will inevitably be compared to it.
Being active is probably most important.
Maybe it would be possible to get a link into a “This Week in Rust”?
I use Colemak where most punctuation is at the same place as in the US English layout, which programming languages seem to be optimized toward. For the layout I prefer ISO for the larger Enter key.
Rust:
Cannot move princess out of
castle
which is behind a shared reference
Everyone is having fun playing air guitar, though bad they may be at it. Except the beige dude who forgot his air guitar at home.
I don’t think there is a good way of having references within the same struct, but you could store reference counted matches:
matches: Vec<Rc<Match>>, players: HashMap<String, Rc<Match>>,
You would still have to make sure that the
players
map is updated, maybe weak references are useful there.Maybe you could also consider storing the players of a match in the match itself, not outside.