3 ms·

> It being a "bad idea" is nonsense. The bad idea claim was principally about breaking cross and static compilation.

9rx 1y ago
Principally, but not exclusively. It was also told to be a bad idea because of some insignificant performance overhead associated with cgo. Which is especially funny as using go-git (which is known to be slow) and shelling out to git are apt to bring even greater performance overhead. As always, don't assume – measure!, but if we have to play the odds for the sake of an internet comment, libgit2 is likely to be the most performant option reasonably available, if there is some reason to think that performance is of concern here. Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs. — And maybe not even. The earlier comment brought a lot of assumptions without offering any background. There are theoretically other options available for libgit2. For example, using the Wasm build. While others have had success using Zig as the C-side compiler, which doesn't have all the messy baggage legacy compilers tend to carry (e.g. poor cross-compilation support). Yes, measurement may offer reason why those are not suitable options, but missing in the comment is the measurement, or even what is trying to be measured! Instead, we got something that appears to be copy and pasted straight from a Rust advertisement.
- throwaway894345 1y ago
  > Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs. Yes, there are cases in which CGo’s tradeoffs are appropriate, but you’re rebutting my claim that CGo is a bad default, so you need to show that CGo is appropriate in the default case (you went so far as to call it “nonsense”), not merely that there exists some project for which CGo’s tradeoffs are appropriate.

9rx 1y ago

Principally, but not exclusively. It was also told to be a bad idea because of some insignificant performance overhead associated with cgo. Which is especially funny as using go-git (which is known to be slow) and shelling out to git are apt to bring even greater performance overhead. As always, don't assume – measure!, but if we have to play the odds for the sake of an internet comment, libgit2 is likely to be the most performant option reasonably available, if there is some reason to think that performance is of concern here. Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs. — And maybe not even. The earlier comment brought a lot of assumptions without offering any background. There are theoretically other options available for libgit2. For example, using the Wasm build. While others have had success using Zig as the C-side compiler, which doesn't have all the messy baggage legacy compilers tend to carry (e.g. poor cross-compilation support). Yes, measurement may offer reason why those are not suitable options, but missing in the comment is the measurement, or even what is trying to be measured! Instead, we got something that appears to be copy and pasted straight from a Rust advertisement.

throwaway894345 1y ago
> Added complexity in compiling is a tradeoff to consider, of course, but "bad idea" is also nonsense there. It requires a different set of priorities, but those priorities may very well be exactly what a project needs. Yes, there are cases in which CGo’s tradeoffs are appropriate, but you’re rebutting my claim that CGo is a bad default, so you need to show that CGo is appropriate in the default case (you went so far as to call it “nonsense”), not merely that there exists some project for which CGo’s tradeoffs are appropriate.