C for Rust Programmers
21 points by BD103
21 points by BD103
I wish I'd thought of this.
As a Python→Rust programmer who later picked up C for MS-DOS retro-hobby programming, it never occurred to me to blog about what I learned.
As now you know, you should try. Or target more specific topic like struct or union or something else while comparing with Rust.
Once I get my time in order enough to finish the posts I already have as drafts, maybe I'll focus on something more unique to my hobby project, such as how it's surprisingly viable to implement your own string/slice type which uses Rust/Pascal-style counted strings instead of null-terminated ones, and to do zero-copy parsing with it.
I loosely planned a short book “Python for Rust programmers” in 2014. It was to be humorous but at least mildly insightful. I never quite made it (the previous project took far longer than anticipated) and the time for that sort of thing has kinda passed by now. But honestly I do think it’s a useful concept, and might eventually do something significantly briefer. I’m exploring a new direction of technical book, handwritten, with no paragraphs and not much prose, and probably not more than 50–100 pages long.
All of these things are true, but mainly with historical reasons. They then cannot be undone because so much of the world is dependent on C code, so lots of things need to keep compiling.
The one thing I'd say is it's easy to hook up a performant garbage collector in most cases... or just use FilC to compile, which gives you better safety than you'd get in Rust.
I'm certainly not saying C's a better language; Rust has the benefit of being developed ~40 years later. It is not hard to make a better language than C. Still, Rust and Zig both deserve a lot of credit for being able to compete at all in C's niche-- they may eventually become as important as C is.
And just a nit on your footnote: C23 in Clang accepts true and false without including <stdbool.h>, and has for quite a while.
The corresponding Rust function is not idiomatic, and can only correctly handle ASCII text. If I were writing a production version of this function, it would be a single line of code
Of note: because it works on codepoints the line in question only works for scripts without combining characters or those which have all the precomposed form you need and you have normalised the input. I believe that is a very common issue for Aramaic and Brahmic scripts, but even the first can occur in Latin scripts despite their favoured position: the guarani script uses the character g̃ which afaik has no precomposed form, it only exists as the sequence Latin Small Letter G, Combining Tilde.