Roland Illig <roland.illig%gmx.de@localhost> writes: > due to ongoing problems with the portability of the Go programming > language, I have considered to rewrite pkglint in another programming > language. Thanks for thinking about this. I admit that I'm surprised how bad the portability situation is, but I suspect the people who did go never suffered the pain of Haskell because they use only Linux. They seem to be going down the same path, thinking binary bootstraps are ok. > I estimate that rewriting pkglint, which is currently about 14000 lines > of code, will take about half a minute per line, which still amounts to > 120 hours. The good point is that this rewrite is not as risky as the > last one, since the code is covered by unit tests; at least 80 percent > of it. That's great about tests. > My currently preferred language is Vala/Genie from the GNOME project, > which I don't yet speak fluently, but from what I have done in it, it > seems to be very easy. Roy's point about needing a language installed just because of pkglint is a good one. I had a similar but less coherent reaction on reading your note (and am replying after pausing to solidify thoughts). But it's a question of degree and what the footprint of the new language is. If it's Lua, that's not bad, but if it's something big, it's troublesome. vala seems not so bad in this department. It requires glib2, but that's pretty normal. "pkg_info -s vala" is 15M on my system, also not so bad on a developer box. > * It has garbage collection. > * It has memory protection. > * It has a built-in string datatype (unlike C). > * It has concise syntax. Those sound like good things, in terms of writing code and maintaining it. > * It compiles to C, using the glib object model, which I guess is > portable to all platforms pkgsrc will ever run on. That's a good point, and I think the right question. > * It compiles to reasonably fast code. > * Performance-critical parts could be written directly in C. That sounds nice, but I'm not sure it's that important (in terms of a 5x slowdown, but building everywhere probably being a good trade). > For benchmarking the speed, I wrote a recursive grep in Go, Vala, Genie > and Nim, and compared that to the native grep. I chose this simple task > because pkglint heavily depends on IO and parsing text files. The Vala > version was about 50 percent slower than the Go version, which in turn > had half the speed of the native grep. Roy listed python and perl. Those are two languages that have the first few properties you listed, are known to build pretty much everywhere, and are likely installed already on most systems used for developing packages. And, they are unlikely to fade from the earth. I don't have a good basis for asserting the future of vala, since it's a gnome-only thing, AFAICT. > If someone can convince me that C++ or even C is better suited, please > do so. I just fear the undefined behavior too much. I wouldn't try to convince you of that. C++ is really not suitable for portable code, because the history of C++ over the last 20 years is that one constantly has to worry about compiler version, both in terms of updating code for pickiness of earlier compilers, and in terms of having a new enough compiler. I've recently seen code written for C++11 (needs gcc 4.8) arrive at a fairly old but not really ancient compiler: gcc 4.1, as netbsd-5 has, and things did not go well :-( > Or if you prefer it to be written in a scripting languages like Perl, > Python, Ruby, Lua, please provide some hints that it won't execute as > slowly as the old Perl version. And, by the way, I like statically typed > languages with explicit variable name checking, since they catch many > errors at compile time. I see your point about language safety. Lua might or might not be plausible. It's certainly portable enough, and it's fairly fast. But it has latent rather than manifest types. python and ruby seems like good candidates. > Are there any other languages out there that I missed? Or tools that > could help in the translation? I don't think so. The big requirement is that whatever langauge it's in has to be readily available on any platform pkgsrc might run on, which includes older compilers (we might say gcc >= 4.1 now) as would be found on netbsd-5, and operating systems that people writing new tools don't know about. The latter limits us to languages with implementations that need only C99 and have an autoconf feature-test mentality rather than needing to have explicit per-OS support. Another thought is that as far as I can tell, there's nothing wrong with the Go language itself; the real problem is that we don't have a portable implementation in pkgsrc. I hear about "C Go" but don't know about it; I wonder if that would enable building something good enough to run pkglint on any machine with C99/POSIX. It might be less time to make that work, and then pkglint could stick to that Go dialect, and we'd have a good outcome.
Attachment:
signature.asc
Description: PGP signature