I think this is more of a moot point, as all this proves is that there are differences between the your C stdlib and Bolin's stdlib.
There are always going to be tradeoffs -- as your article admits, the differences themselves come down to a 1 cycle difference, which would show up as about 1ms. If performance is really critical for an application, things like this are more than capable of being rewritten in an optimized form rather than relying on the standard library, which understandably doesn't try to cater to every use case. Or in other words, when performance is a concern, C is more than capable of providing the necessary tools to achieve it.
I don't think a comparison like this will convert anyone from C to Bolin. Where a possible argument may be made is that Bolin is a better language, and argue for the design decisions that were made in its implementation. Even so, people are bound to disagree, and the bottom line is that while C is imperfect, that's what makes it perfect.
C does not enforce rules on how its authors thought code ought to be written, and neither does C enforce one type of memory management over another. C has no preference over the way packages are managed, and neither does C prefer one standard library over another. C is unopinionated: it lets you do whatever you want to do however you want to do it.
Just following up on this, in my opinion there would be more value in writing better C compilers and cross-compilation toolchains, linting tools, static analysis and optimization tools, and alternative standard libraries, than doing things like starting a new language altogether (e.g. Rust, Go, V, etc. etc.)
This is not to say that those languages don't have value: they are awesome and I am very attached to a couple.
However I still recognize that they are all trying to do something right by reinventing the wheel. Rather than building a "new" C from scratch, I think it would be better for everyone if we built on top of C.
One constraint C has is its ABI. Bolin compilation model is different (article went up last week) and being constrained by it would be pointless. C allows unsigned variables to wrap, bolin doesn't (not enforced yet, beta is 0.1.0). If my team and I wanted to compete with speed we'd be handicapped by C constrains. This current article shows a reason why you might want to use posix read instead of fread/fgets, the Bolin compiler doesn't use libc or any other lib at the moment because we wanted it to be fast and because we knew we'd be writing our own libraries.
How do you suppose people can get rid of constrains that would make their language slower? I hear the whole reason carbon exist is because google couldn't get the C++ committee to budge on ABI
There are always going to be tradeoffs -- as your article admits, the differences themselves come down to a 1 cycle difference, which would show up as about 1ms. If performance is really critical for an application, things like this are more than capable of being rewritten in an optimized form rather than relying on the standard library, which understandably doesn't try to cater to every use case. Or in other words, when performance is a concern, C is more than capable of providing the necessary tools to achieve it.
I don't think a comparison like this will convert anyone from C to Bolin. Where a possible argument may be made is that Bolin is a better language, and argue for the design decisions that were made in its implementation. Even so, people are bound to disagree, and the bottom line is that while C is imperfect, that's what makes it perfect.
C does not enforce rules on how its authors thought code ought to be written, and neither does C enforce one type of memory management over another. C has no preference over the way packages are managed, and neither does C prefer one standard library over another. C is unopinionated: it lets you do whatever you want to do however you want to do it.