Yeah, decorate it just with a tremendous amount of dark red paint, spattered away from the fan, heaviest in the fan corner
Yeah, decorate it just with a tremendous amount of dark red paint, spattered away from the fan, heaviest in the fan corner
Yeah but it sounds less cool if you say thirteen point three millilitres than to say Four (4) TRIOS™!!!
Rust has a lot going for it beyond just the safety thing: excellent package manager, powerful trait system and generics, helpful compiler errors.
The whole language is designed to help you avoid making the programming mistakes people tend to make, not just the borrow checker and memory safety.
Finally, the drivers will be able to play Angry Birds while they race.
Yeah, I shell out for the premium electricity, the 99% electrons. The 95% stuff is fine but I have a lot of expensive devices; I want them to run as fast as possible.
I like Tom Scott, I think his videos are interesting and well produced. But I’m glad for the break, I think I’ve reached saturation on Tom Scott content and am starting to find Tom Scott’s Tom Scott mannerisms and speech patterns to be a bit too gratingly Tom Scott. The earnest Tom Scott monologues, Tom Scott’s Tom Scott laugh while experiencing something Tom Scott about 3/4 predicted, the Tom Scott pause before delivering that last Tom Scott factoid.
Anyway, I hope he has a nice break and comes back some day soon.
I recommend wrapping the git cli commands using subprocess, using porcelain output modes etc, and parsing the output.
We have had stability problems with GitPython (which wraps gitdb). On Linux gitdb does clever things with sliding mmap, which caused some crashes (in a multi threaded environment), and I found simple race conditions in the code for writing loose objects, which is about as simple an operation as can be, so I lost faith with it. I do use gitdb in one read-only single-threaded system; it’s undoubtedly fast.
The biggest issues with git libraries are around the complexity of git configurations. Any independent reimplementation is probably going to support the most common 99% of features but that 1% always comes back to bite you! We use a lot of git features in service of a gigantic monorepo, like alternates and partial clones and config tricks.
If we use command-line git we get 100% compatibility with all git configuration and ODB features, and it’s hard to ensure that with an independent git implementation (even libgit2).
When you say “that solution doesn’t scale well” - we have made it scale. git itself scales well for operations it can perform natively, you just have to use the features effectively, often the high-level operations but sometimes lower-level commands like
git cat-file --batch
,git mktree --batch
, etc. It’s not as fast as gitdb but fast enough, and I can have high confidence that I can write something once and it won’t break or cause problems later.