Sorry, I missed the link to https://github.com/sugawarayuuta/benchmark – I don't find its contents very easy to digest, and there's often more to an encoding library than benchmark perf - how does it compare in terms of functionality, correctness, etc would be great to cover too. The README just has vague discussion of "some other alternatives" which isn't very actionable.
Whenever I see one of those supposedly better implementation of something, I always wonder why don't their author simply PR the standard library with their superior implementation? Go is quite pragmatic in its approach to things, I have never seen any interaction with core maintainer that went bad if someone had a better solution in every possible way
If I had to guess, “hey you should adopt my library, it isn’t in production use anywhere but look at these benchmarks” is a harder sell than “lots of people are already using this and it works really well, all significant bugs raised have been fixed, and hey look at these benchmarks while you’re at it”.
Sure, live and let live, but there is no way I would use a library that doesn't maintain a version history, especially so given the nature of go's non-centralized dependency management system.
Even if you pin your dependencies to a particular commit hash, eventually github will garbage collect detached commits, and your project will fail to build.
Most of the time the reason isn't nefarious, but rather that people aren't interested in (a) doing the versioning work as they implement things bit by bit and (b) exposing their "draft" copy work while they are still trying out things that fail.
24 comments
[ 3.5 ms ] story [ 91.3 ms ] threadThere is a column named SegmentJSON in the benchmarks page [1]
[1] https://github.com/sugawarayuuta/benchmark
How fast and safe was it before? Seems to be no way of knowing, as the git history has been blown away, what's up with that?
Anyway, I'm not a fan of this style of using Git, but personal projects are ultimately, personal, to each their own.
Even if you pin your dependencies to a particular commit hash, eventually github will garbage collect detached commits, and your project will fail to build.
cmon man, dont do that.
for the lay people, this person rebased to remove the ENTIRE history of the project.
Is this a real library or some honeypot?
Seems very suspicious and dangerous. I would not touch it or install it.