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.
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 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.
Only if you define "safety" in certain ways. There's no way to magically fix certain cases where Rust is safer because the C source code simply doesn't give enough information to the compiler/runtime to know whether something is intentional or a bug, while the Rust standard library was designed to refuse to compile those cases.
(C and C++ lean in the direction of "trust the programmer" while Rust leans in the direction of "if it can't be proven correct, assume it's incorrect and reject it".)
FilC validates every pointer access much more comprehensively, with no unsafe blocks. Plus the entire library stack gets protected, unlike the C libs that often get linked to Rust code.
Compiled Rust code will be faster but I don't think it's fair to call it more safe, at least from a memory safety point of view.
FilC doesn't check your code ahead of time. It crashes your program at runtime if you make a mistake. A crash is better than RCE, but Rust stops you from making the mistake in the first place.
FilC also doesn't magically retrofit design patterns that are idiomatic in Rust, such as the Hyper HTTP library using the typestate pattern to make it a compile-time error to attempt to set an HTTP header after the body has begun streaming.
(Everyone older than a certain age has probably seen that PHP error message at the top of at least one website.)
I came from Python. Memory safety is table stakes. Rust interests me because of all the additional stuff it catches at compile time. (And yes, I avoid C dependencies wherever possible, if for no other reason than how they complicate cross-compilation... which includes making a statically linked Linux musl-libc build of the binary.)
The one thing I'd say is it's easy to hook up a performant garbage collector in most cases...
What are some of those performant garbage collectors? I haven't written anything but embedded C for over a decade, so I'm curious what application-level C looks like now!
Yes, the Boehm collector has been around a long time. Simple garbage collectors are cheap easy to write, especially if you are not using multiple threads.
A few other things that've been around for 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.
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.
veqq | a day ago
A Racket comp sci course has a if you must learn c attatched which I reallt liked.
ssokolow | a day ago
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.
chauhankiran | a day ago
As now you know, you should try. Or target more specific topic like struct or union or something else while comparing with Rust.
ssokolow | a day ago
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.
viega | a day ago
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
trueandfalsewithout including <stdbool.h>, and has for quite a while.ssokolow | 19 hours ago
Only if you define "safety" in certain ways. There's no way to magically fix certain cases where Rust is safer because the C source code simply doesn't give enough information to the compiler/runtime to know whether something is intentional or a bug, while the Rust standard library was designed to refuse to compile those cases.
(C and C++ lean in the direction of "trust the programmer" while Rust leans in the direction of "if it can't be proven correct, assume it's incorrect and reject it".)
viega | 19 hours ago
FilC validates every pointer access much more comprehensively, with no unsafe blocks. Plus the entire library stack gets protected, unlike the C libs that often get linked to Rust code.
Compiled Rust code will be faster but I don't think it's fair to call it more safe, at least from a memory safety point of view.
hailey | 18 hours ago
FilC doesn't check your code ahead of time. It crashes your program at runtime if you make a mistake. A crash is better than RCE, but Rust stops you from making the mistake in the first place.
ssokolow | 18 hours ago
FilC also doesn't magically retrofit design patterns that are idiomatic in Rust, such as the Hyper HTTP library using the typestate pattern to make it a compile-time error to attempt to set an HTTP header after the body has begun streaming.
(Everyone older than a certain age has probably seen that PHP error message at the top of at least one website.)
I came from Python. Memory safety is table stakes. Rust interests me because of all the additional stuff it catches at compile time. (And yes, I avoid C dependencies wherever possible, if for no other reason than how they complicate cross-compilation... which includes making a statically linked Linux musl-libc build of the binary.)
quad | 20 hours ago
What are some of those performant garbage collectors? I haven't written anything but embedded C for over a decade, so I'm curious what application-level C looks like now!
ssokolow | 19 hours ago
Based on what I've seen applications like Inkscape using in the wild, I assume their list includes https://en.wikipedia.org/wiki/Boehm_garbage_collector
viega | 19 hours ago
Yes, the Boehm collector has been around a long time. Simple garbage collectors are cheap easy to write, especially if you are not using multiple threads.
A few other things that've been around for a while:
masklinn | a day ago
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.
chrismorgan | a day ago
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.