More interesting page, IMO: https://cforall.uwaterloo.ca/features/. Personally it has a bit more than I would be comfortable adding to C while taking the similarity stance they are. Are there safety improvements planned with regards to bounds checking?
C-for-all: Extending C with modern safety and productivity features
31–40 of 143 posts
Re: C-for-all: Extending C with modern safety and productivity features
#32HN Kiss of death
HN's version of Slashdotted. They might well use UWaterloo's CS Club infrastructure, which can withstand enough traffic. For instance, the FOSS mirror at https://mirror.csclub.uwaterloo.ca
Or they should use a static website and handle any amount of traffic on a $3 VPS :)
Re: C-for-all: Extending C with modern safety and productivity features
#33Earlier quoted context omitted.
I think that assertion muddles their argument. Their key points seem to be that Rust (and other existing languages) lack backwards compatibility and have different memory management strategies. Lumping Rust in with GC languages is confusing. Whether either of those things matter is another story. From using TypeScript, I'm personally inclined to believe that a superset of a difficult language can't solve all of the u…
All memory allocations in Rust follow a `malloc`-like API that ends up calling `malloc` and similar at some point.
With memory management, the question is often when and how to release resources, not how to get untyped memory from the operating system.
Re: C-for-all: Extending C with modern safety and productivity features
#34Re: C-for-all: Extending C with modern safety and productivity features
#35This has been posted here a couple of times in the distant past but for whatever reason I can only find one old post: https://news.ycombinator.com/item?id=9829133 Anyway, it seemed like an interesting project the last time I looked at it but Rust wound up getting all my attention.
Here's the discussion from 2018 [0], which has some responses from people involved with the C-for-all project.
Re: C-for-all: Extending C with modern safety and productivity features
#36if safety is what they want without departing from C just use MISRA-C > While C++, like C∀, takes an evolutionary approach to extending C, C++'s complex and interdependent features (e.g., overloading, object oriented, templates) mean idiomatic C++ code is difficult to use from C, and C programmers must expend significant effort learning C++. the "significant effort" for learning C++ pays off (financially), while this…
> use MISRA-C
MISRA-C's idea of safety is banning function pointers.
Re: C-for-all: Extending C with modern safety and productivity features
#37Obligatory name-drop: Zig is an awesome low level programming language targeting the same space as C and CForAll. It isn't at all compatible with C on the source level like CForAll is, but it does make it super easy to interop with C, because it can include .h files. That means it lets you move projects from C to Zig file-by-file. Because Zig benefits from decades of insights about how C could've been better, it has…
I second the props for Zig. It's basically a really well designed, trimmed down C with "compile time values" that, as an emergent phenomenon gets generics, and composable allocators.
C interop is beautiful. My primary language is on the Erlang Virtual machine, and it's easier to write FFI using Zig than it is to write it in C.
Re: C-for-all: Extending C with modern safety and productivity features
#38Obligatory name-drop: Zig is an awesome low level programming language targeting the same space as C and CForAll. It isn't at all compatible with C on the source level like CForAll is, but it does make it super easy to interop with C, because it can include .h files. That means it lets you move projects from C to Zig file-by-file. Because Zig benefits from decades of insights about how C could've been better, it has…
I second the props for Zig. It's basically a really well designed, trimmed down C with "compile time values" that, as an emergent phenomenon gets generics, and composable allocators. C interop is beautiful. My primary language is on the Erlang Virtual machine, and it's easier to write FFI using Zig than it is to write it in C.
I upvote
Re: C-for-all: Extending C with modern safety and productivity features
#39I really don’t need an extended-C with productivity features... as that’s one of the defining points of C(the language is small). Fixing the warts (like different behavior between the overflow of unsigned ints & signed inta) would have been fine. I personally want a better stdlib for C; fix the defiancies of , removing the global locales (changing function behaviors according to LC_* was a really, really bad idea[0])…
If you are targeting nix/BSD/MacOS/Windows then https://developer.gnome.org/glib/ is pretty good standard library for C. Not supported on bare-metal though.
Re: C-for-all: Extending C with modern safety and productivity features
#40Earlier quoted context omitted.
Long compile times are almost always because of bad use of header files which include basically everything, insteda of only the used component. And this sometimes is because of bad separation of concersn / modularization.
I'm yet to see a C++ project that compiles as fast as a C one.
About a decade ago I used a Zipit Z2 as my primary machine, as a fun experiment. It had 32 megabytes of RAM. Back then, that meant you could just about run Debian (who needs X11 anyway). Believe it or not, I often compiled software on this thing, and I quickly noticed that projects written in C would generally compile, while C++ builds would invariably choke from memory exhaustion. This was actually the first time I became aware of any difference between the two.
A very educational experience!