It might be interesting to note that none of the C alternatives: C3, Zig, Odin, Hare, Jai use ownership nor RAII. Overloading is also generally missing from today's breed of C alternatives. There has certainly been many attempts at C alternatives: eC, Cyclone etc etc
I think Jai has operator overloading. I won't use any of these though because I can't give up value semantics of data structures. In modern C++ it massively simplifies things and basically makes memory and most resource management a non issue.
I would prefer a "lightweight" C++. C++ is fine, but it's insanely slow to compile. I generally like C++, but I could trade anything to make it faster to compile, and most of the time, I just use a small subset of C++ that I feel okay with.
C++ is not slow to compile. The Standard Library is.
C++ is just slow to compile. With the standard library it is much worse. The problem is that with C++ you're not getting as much encapsulation as you would in C unless you do extra work that also has a performance hit (pimpl). This means that C++ code often has to recompile a whole lot more than C code does when doing incremental compilation in my experience.
I wish there was a way to transpile this to C. That way it can be both an escape hatch, and a way to target unusual platforms not directly supported by C3 lang.
This could make sense for a from-scratch language, but C3 is trying to be an evolution of C, and such constraints would make it so much of a different language that it would be way out of scope. I think Rust and similar languages fill that niche already, so there is no real need to try to offer that type of alternative.
I think we are miscommunicating. Let's imagine a language called "C@" where the only difference is that "@" is used in place of "*" for a non-nullable pointer type: typedef struct { foo @*data; //Non-nullable pointer to nullable pointer of foo size_t size; size_t fill; } foo_vec; void foo_vec_push(foo_vec @v, foo @x) { if (v->fill == v->size) { //realloc and zero data } else { data[idx++] = v; } } foo @ foo_vec_get(f…
In this case, how would you prevent the user from seeing an invalid foo_vec before initialization? This is either "oh, it's in an illegal state", in which case it's just an annotation without deeper enforcement or you need to somehow enforce that a non-null pointer is never seen, am I not right?
Problem with Hare is that it is (or at least was last time I checked) Linux/Unix only and so by design. That kinda makes it DOA for many.
Indeed. There’s a port for macOS though. And yet out all these newer C-like languages, it looks like Hare probably takes the crown for simplicity. Among other things, Hare uses QBE[1] as a backend compiler, which is about 10% the complexity of LLVM. [1] https://c9x.me/compile/
It's funny how they say they are at 10% of the code of LLVM in their marketing, when it is actually closer to 0.1%. Throwing LLVM version 20.1 through wc (just the subdirectory llvm/lib) results in 2.3 million lines for all .c and .cpp files. QBE was around 14k last time I checked.
I think we are miscommunicating. Let's imagine a language called "C@" where the only difference is that "@" is used in place of "*" for a non-nullable pointer type: typedef struct { foo @*data; //Non-nullable pointer to nullable pointer of foo size_t size; size_t fill; } foo_vec; void foo_vec_push(foo_vec @v, foo @x) { if (v->fill == v->size) { //realloc and zero data } else { data[idx++] = v; } } foo @ foo_vec_get(f…
In this case, how would you prevent the user from seeing an invalid foo_vec before initialization? This is either "oh, it's in an illegal state", in which case it's just an annotation without deeper enforcement or you need to somehow enforce that a non-null pointer is never seen, am I not right?
1. It's not quite trivial to statically disallow use-before-initialization, but it's definitely a solved problem if you disallow returning uninitialized variables.
2. The other option is to disallow declaration without initialization of non-nullable values. If you can't declare an uninitialized foo_vec, then the user can't ever see an invalid foo_vec.
I wish C3 has simple RAII/object/class built-in(no inheritance needed, no Polymorphism is fine, just some Encapsulation better than c's struct with function pointers), then it becomes a more powerful c, and a much simpler c++, really a sweet spot in the middle of both and works for 90% of the c/c++ use cases.
Hasn't this been done already? C with classes I mean. eC and others.
what is eC? I don't believe there is something like 'C+' existing between C and C++, yet.
>while not finishing the previous attempts I agree, and that applies to many software projects, and not just programming languages only. >so there are quite a few half baked features by now what are some of those half baked features?
The new allocators, some corner cases of the destroy and destructors, not everything on Phobos is @nogc friendly, BetterC still chockes on many common C extensions, DIP 1000, the whole set of @live semantics. Now there is a new GC being redesigned, and there are discussions about a possible Phobos V3.
thanks.
interesting, didn't know about the new GC, or possible Phobos V3
C++ is not slow to compile. The Standard Library is.
C++ is just slow to compile. With the standard library it is much worse. The problem is that with C++ you're not getting as much encapsulation as you would in C unless you do extra work that also has a performance hit (pimpl). This means that C++ code often has to recompile a whole lot more than C code does when doing incremental compilation in my experience.
This is just not true. There's nothing that makes C++ inherently slow to compile.
PImpl doesn't need to have a performance hit as you can implement it with a local fixed-sized buffer that's not heap-allocated.
You can also design your C++ codebase exactly as you would in C, so there's literally no reason why you'll need to recompile more in one language compared to the other.