Spoiler: the title is clickbait and the article actually says that C isn't really slower.<p>The initial C implementation written by the author that was passed off as representative of C was naive and had a couple of performance blockers. The author points out those performance blockers, and once the author gets rid of those blockers and re-tests te conclusion is that C isn't actually slower.
Better title: why are some C stdlib functions slower than some Bolin stdlib functions. Unlike with many other languages, it's totally fine to write C code and (almost) completely ignore the stdlib functions. The C stdlib is essentially just the least common denominator to get trivial cmdline tools working (badly) across platforms, but that's about it.
According to the website [1] there is a strict license to this programming language.<p>> The License is intended for free learning and hobbyists and is a personal use license which means the Software may be installed and run only on Licensee computer as required for the purposes of Licensee’s code to produce a binary executable output (the “Executable Product”) only on Licensee-controlled Endpoint. An Endpoint is defined as a computer operating system (“OSE”) of any type physically hosted, but limited to Licensee’s internal personal use and not for distribution or any other use. For certainty, Licensee may not: distribute, assign, sell or grant any rights in or to the Software OR the binary executable product created by using the Software.<p>People of course can license the fruits of their labor however they wish to, I just can’t understand why someone would license their compiler in a way that prohibits me from sharing a useful program I made with my family or friends.<p>[1] <a href="https://bolinlang.com/eula" rel="nofollow">https://bolinlang.com/eula</a>
You are comparing file IO, string to int, raw processing, and text output speed all at the same time.
There are pros and cons associated with the choices made in both sets of libraries and compilers for each of those aspects.
What exactly are you trying to measure? Can you isolate those parts more specifically and compare them instead? That would probably be more informative.
When I run the "faster" C code, it takes 176 ms. When I run this C++ code:<p><pre><code> #include <iostream>
#include <fstream>
int main() {
auto& out = *std::cout.rdbuf();
std::filebuf in;
in.open("/tmp/numbers",
std::ios::in);
for (int c, n = 0;
(c = in.snextc()) != EOF;) {
if (c != '\n') {
n = n * 10 + (c - '0');
} else {
out.sputc((n & 7) + '0'), n = 0;
}
}
std::cout << '\n';
}
</code></pre>
it takes 84 ms (and presumably 90 ms on the author's machine).<p>So, why is Bolin slower (and longer) than C++? And why is so much of published code so bad?
I think there is merit to these discussions. One has to ask what the most natural/idiomatic program to solve a problem is, and sometimes the performance of that matters more than the utmost performance you can get from the language.<p>I'm know to be a rust fanboy, so I'll talk about C++ instead. C++ is known to be fast, but theres also some known logic that you should use smart pointers to have more memory safety than raw pointers. If you follow that you'll end up with a slower program. Of course, you can remove those and manage the pointers yourself, but then you have to deal with documenting the lifetimes properly.<p>These are trade offs people agree to when using a language. The easier thing might be slower and that's ok. Speed isn't always critical, so you can't exactly rate languages by that metric alone
Nobody understands C use fgets when he/she wants speed.<p>The whole point of C is the programmer decides the performance himself, not trying to the fastest. None of the popular languages consistently deliver this.