Re:Git-cliff – Generate changelog files from the Git history
by rwmj on Sunday September 05, 2021 @11:11AM
(#28424915)
Why would speed matter for something that runs a few regexps over some commit messages once a month? I would have chosen Perl for this task: good enough speed for the task, excellent built-in support for regexps, templating libraries like the Template Toolkit, and flexibility around things like loading custom modules at runtime and parsing configuration.
[ Parent
| on HN ]
Re:Git-cliff – Generate changelog files from the Git history
by jstummbillig on Sunday September 05, 2021 @11:18AM
(#28424959)
Got to admire how smoothly we went from "Props for not selling language x for this" to "I am selling language y for this" in just 3 consecutive posts.
Re:Git-cliff – Generate changelog files from the Git history
by ExtraE on Sunday September 05, 2021 @01:33PM
(#28426036)
Language choice is a legitimate decision, debating which one to use is a legitimate topic. Selling an-already existing product based on its language is questionable, as the parent pointed out.
Re:Git-cliff – Generate changelog files from the Git history
by judge2020 on Sunday September 05, 2021 @11:39AM
(#28425129)
It could matter in edge cases, perhaps someone runs this on google3 or the linux kernel and it takes 10 seconds versus a minute+ on something like Perl (not sure if that's the case).
Re:Git-cliff – Generate changelog files from the Git history
by rwmj on Sunday September 05, 2021 @02:28PM
(#28426503)
I agree. If that's really one of the requirements then Rust or C++ or OCaml or something like that would make a lot of sense.
Also I'd like to add to my original comment above: I don't care at all that this is implemented in Rust. Good on you. Open source software goes where the developers go, and isn't dictated by anything except what the developers want to do.
Re:Git-cliff – Generate changelog files from the Git history
by handrous on Sunday September 05, 2021 @04:13PM
(#28427375)
We don't need more of the "git-[whatever]" commands to be in scripting languages. It's hard enough to bundle, distribute, and support as it is (especially on Windows). Though, yes, parts of it are already Perl so that probably would have been fine, but still a move in the wrong direction.