Itās interesting how āevolutionary approachā is used. Compare with C2: http://www.c2lang.org/
I think that in the case of C2 itās still a language that will rely on the same paradigms as C, whereas C-for-all is more of a ākitchen sinkā style of language that moves very far from C in how the natural code solutions are. Just the small change adding destructors and constructors is a feature with huge impact on how data will be managed (for better and for worse)
(Full disclosure: I have contributed to C2 in the past and Iām working on the C3 lang which is feature and syntax-wise based on C2 but goes further: https://www.c3-lang.org )
This 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.
Could someone expand on why Rust "isn't a systems language"?
I 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 <string.h>, removing the global locales (changing function behaviors according to LC_* was a really, really bad idea[0]), etc...
Does anyone know of an alternative stdlib for C?
[0] https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02...
I'm sure a lot of very smart people are working on this, and I don't want to detract from their dedication, but man this language looks like a mess. And in no small part because it wants to be backwards compatible with C (the reasoning is unconvincing -- why not just use C++?).
In the age of Go and Rust, which already have a hard time finding niches, I don't really think there's any room for a language like this. And on the other hand, from a research standpoint, it's probably a lot more interesting to build a new language from the ground up.
Can we talk about the proposed new features:
How are tuples different from structs? You can pass around and return whole structs (not pointers) just fine in plain C.
Underscores in int literals should probably be proposed to the ISO committee for C itself. A similar concept works successfully in OCaml. (Binary literals would also be useful).
I've never felt that C lacked sufficient control structures, and the new ones proposed here just seem like they will confuse people. What specific problem is each new control feature trying to solve?
Adding exception handling (to C) seems like an actively bad idea. What are the semantics? How does unwinding work exactly and how would it interact with resource allocation?
Coroutines are today successfully handled in libraries, so I'm not sure what you gain by adding them to the language.
if 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 certainly does not.
I was excited to read about this. An upgraded C would be nice. Unfortunately, after the homepage, this seems disastrously opposed to anything resembling a "better" C.
The features page feels extremely painful to read. It took me at least two minutes to even begin to make sense of the first section: "Declarations", then an explanation of Tuple, immediately followed by:
int i;
double x, y;
int f( int, int, int );
f( 2, x, 3 + i ); // technically ambiguous: argument list or comma expression?
[ y, i ] = [ t.2, t.0 ]; // reorder and drop tuple elements
[ i, x, y ] = *pt; // expand tuple elements to variables
x = t.1; // extract 2nd tuple element (zero origin)
It gets worse the further down the page I try to understand. Very claustrophobic and presented as a mish-mash of syntax examples. I can't see how this is any better than C's syntax, honestly. What C would benefit from is a better baked-in stdlib, OR an easily available, downloadable, lib of helper functionality that doesn't require any modifications to existing code (eg. when I want a hashtable in an already-established project, I don't want to modify my existing structs!)
Wow, this is quite a trainwreck. I think it's possible to improve C while keeping compatibility with C programs, but that's not how you should do it.
I think an improved C would be quite useful, but you really should be careful with what you include it, and keep the language simple. A lot of functionality feels like added because it could be added (WTF are nested routines). This way lies worse C++.
In particular, I wouldn't look too much into what C++ does. Rather, I would look into what Go, Rust and Zig do. `?{}` and `^?{}` are clearly inspired by C++ constructors and destructors, but that's not the only way (in fact, it's a rather bad approach if you want to keep things simple). For instance, you could avoid having constructors and require full initialization for structures with destructors. Hypothetically, it could look like this.
struct Point {
int x;
int y;
};
struct Point new_point(int x, int y) {
return { .x = x, .y = y };
}
Linked page explains rationale, see also the list of features : https://cforall.uwaterloo.ca/features/
For some time I have been puzzled that clang and gcc don't provide an option/ABI (maybe -safe or -mcpu=x86-64-safe) for memory safety.
Last I checked, memory safety for C (e.g. fat pointers with bounds checking) seems to impose a ~60% performance overhead on traditional processors (with hardware support it could be much less.) In many (most?) cases, that overhead is worth the improvements in reliability and security.
For certain applications (probably anything network facing) I'd probably want to compile the whole OS, libraries, and software base with -safe.
What does powered by Huawei mean? Are they what Mozilla is to Rust?
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?
I dream of "better C" as something that I wish existed. Not a "alternative to C" like Rust or ADA (that is BETTER, but not C). I think:
- A C developer must find as low friction as possible to use it.
- It will look alike C as much as possible.
- Will not bring a big semantic/syntax departure
- Not bring any novel stuff or Gc. BetterC is C as will be written by the BEST of the developers with the BEST practiques applied, and removed (as much as possible) the most obvious mistakes or ill-advised features.
- BetterC must be/have a transpiler. Even if that break for a while perfect behaviors it provide a way to cleanly upgrade things forward. Because BetterC is well writen C, the user will be encouraged to use it with the confidence of be in the ecosystem.
- BetterC must be incorporated (eventually?) as a front-end in a C compiler (like LLVM). So is like have "strict on" available.
- This mean is better if is backed by the community as a long, step-by-step goal of C. This also mean must be done for people that actually love/like C, just want it to be better.
- Must provide a set of blessed libraries like unicode strings, arrays, numbers, dates, etc. If not in-built at least included so most that use C as all-around lang not get out (similar in this case as Rust)
- Must encourage rewrite of critical pieces of code, despite zero-cost of FFI with C.
- Fix stupid syntax issues like dangling else. This is the "easiest" part I think.
- Find the biggest issues of the langs/common libraries and kill them.
- NOT ALLOW STUPID BY DEFAULT. Bring the "unsafe" keyboard here. No excuses!
- Bring sane macros.
- Bring AGTD, pattern matching, for ... in ..., and hopefully, fast fast compile times.
Here's a snapshot from the Wayback Machine, given the original website is down https://web.archive.org/web/20181206232625/https://cforall.u...
Some interesting ideas here. However, C is being improved in an evolutionary fashion; the latest revision was C18 in 2018. I like languages like this (my favorite is D), but the only C successor language I use is C11 (this is what clang targets; C18 is an incremental minor update to C11 that only fixes errata).
x = t.1; // extract 2nd tuple element (zero origin)
Obligatory 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 way fewer footguns and higher productivity.
Obviously CForAll has a learning curve advantage over Zig, being based on C directly, but for any readers not aware, I'd say, also check out Zig.
I would like to see C with just the borrow checker - nothing else. I assume someone has probably already done this, and I just don't know about it.
The primary advantage of C is that, and this just parphrasing a Linus Torvald's quote - it was developed at a time when computers weren't that powerful and so it's very close to assembly such that a proficient C programmer knows exactly what's going on under the hood.
I can't say the same for Rust or C++ which both spit out an enormous amount of code thanks to monomorphisation and all the other "zero cost" abstractions they employ.
It started out so great, but at the end I was left with the impression that someone was just trying to shoehorn features into C with quirkier syntax than C++. That type declaration syntax will probably haunt me in my sleep.
Just use the c2rust[1] tool to "extend" C.
YAFUATMCWCIN
Yet Another Fucked Up Attempt To Make C What C Is Not
C is not āunsafeā as in āflawedā: itās designed to fill certain gaps. Its syntactic stability through the decades - as well as its āminimalismā (for a lack of better word) - are among its most important features.
Personally I have been having an hard time trying to figure out why thereās some part of the industry that desperately tries to change what C is in a way or the other.
...but probably Iām just an old Valley fart. Apologies for the rant.
Iām very surprised that no one here has mentioned the Cyclone language[0] yet. It seems to me that it tried to address the same niche as C-for-all.
The one thing I like in c for all seems to be (not sure) but generally every valid c program is a valid c-for-all program. People mentioning C2 seem to ignore that C2 is incompatible with C. Or perhaps I'm wrong on that.
Like we extend the web with "security" ... seems like a recipe for success.
It is concerning that a pro Chinese government entity is sponsoring this project. They're infiltrating North American institutions, where's the oversight?
HN Kiss of death
Thanks
C with modern safety and productivity features is called "C++" and has been around for decades. I'm amazed at how much effort people will expend just to avoid the C++ boogeyman. No, writing C++ does not automatically make your code bloated. No, using C does not guarantee lean design.
Plain C ought to be considered a legacy language and not used for new code. There is zero reason to prefer it over whatever style of C++ you'd like. If you want procedural struct-based C++, you can have that, but gosh, don't write C.
I like the general idea, but the result seems just as full of garbage as C++. Remember the first time you saw a lambda declaration in C++? That sequence of familiar-seeming characters to mean something totally different probably threw you a bit. I know it did me. C-for-all's constructor/destructor syntax reminds me of that.
The syntax for redefining ++ or -- (which already seems spurious) is even more opaque. Other features, like left-to-right declaration syntax and postfix function calls, seem to have no use except to make one programmer's code harder for another programmer to understand. Then they throw in the rest of the kitchen sink, with all of C++'s overloading and polymorphism and inheritance plus both kinds and traits. The result is even more complex and even more surprising (in a bad way) to actual C programmers than C++ or for that matter APL. If not for the absence of templates, I'd say Cforall's complexity is a strict superset of C++'s.If I wanted a direct C replacement with minimal improvements, I'd try D or Zig. If I wanted a systems programming language that had more differences but fewer surprises, Rust or Nim. The last thing I'd want is something that's both more baroque (rococo?) and less known than any of those.