Live data from Hacker News

The C3 Programming Language

c3-lang.org

21–30 of 270 posts

Re: The C3 Programming Language

#21

This is neat and I wish C3 well. But using Nim has shown me the light on maybe the most important innovation I've seen in a native-compiled systems language: Everything, even heap-allocated data, having value semantics by default. In Nim, strings and seqs exist on the heap, but are managed by simple value-semantic wrappers on the stack, where the pointer's lifetime is easy to statically analyze. Moves and destroys ca…

NOTE: I'm a fan of value semantics, mostly devil's advocate here.

Those implicit copies have downsides that make them a bad fit for various reasons.

Swift doesn't enforce value semantics, but most types in the standard library do follow them (even dictionaries and such), and those types go out of their way to use copy-on-write to try and avoid unnecessary copying as much as possible. Even with that optimization there are too many implicit copies! (it could be argued the copy-on-write makes it worse since it makes it harder to predict when they happen).

Implicit copies of very large datastructures are almost always unwanted, effectively a bug, and having the compiler check this (as in Rust or a C++ type without a copy constructor) can help detect said bugs. It's not all that dissimilar to NULL checking. NULL checking requires lots of extra annoying machinery but it avoids so many bugs it is worthwhile doing.

So you have to have a plan on how to avoid unnecessary copying. "Move-only" types is one way, but then the question is which types do you make move-only? Copying a small vector is usually fine, but a huge one probably not. You have to make the decision for each heap-allocated type if you want it move-only or implicitly copyable (with the caveats above) which is not trivial. You can also add "view" types like slices, but now you need to worry about tracking lifetimes.

For these new C alternative languages, implicit heap copies are a big nono. They have very few implicit calls. There are no destructors, allocators are explicit. Implicit copies could be supported with a default temp allocator that follows a stack discipline, but now you are imposing a specific structure to the temp allocator.

It's not something that can just be added to any language.

Re: The C3 Programming Language

#22

This is neat and I wish C3 well. But using Nim has shown me the light on maybe the most important innovation I've seen in a native-compiled systems language: Everything, even heap-allocated data, having value semantics by default. In Nim, strings and seqs exist on the heap, but are managed by simple value-semantic wrappers on the stack, where the pointer's lifetime is easy to statically analyze. Moves and destroys ca…

NOTE: I'm a fan of value semantics, mostly devil's advocate here. Those implicit copies have downsides that make them a bad fit for various reasons. Swift doesn't enforce value semantics, but most types in the standard library do follow them (even dictionaries and such), and those types go out of their way to use copy-on-write to try and avoid unnecessary copying as much as possible. Even with that optimization there…

And so the size of your data structures matters. I'm processing lots of data frames, but each represents a few dozen kilobytes and, in the worst case, a large composite of data might add up to a couple dozen megabytes. It's running on a server with tons processing and memory to spare. I could force my worst case copying scenario in parallel on each core, and our bottleneck would still be the database hits before it all starts.

It's a tradeoff I am more than willing to take, if it means the processing semantics are basically straight out of the textbook with no extra memory-semantic noise. That textbook clarity is very important to my company's business, more than saving the server a couple hundred milliseconds on a 1-second process that does not have the request volume to justify the savings.

Re: The C3 Programming Language

#23
post #12

I haven’t tried C3 myself, but I happened to interact a lot with Christopher Lerno, Ginger Bill and multiple Zig maintainers before. Was great to learn that C3, Odin and Zig weren’t competing with each other but instead learn from each other and discuss various trade-offs they made when designing their languages. Generally was a very pleasant experience to learn from them on how and why they implemented building diff…

> weren’t competing with each other but instead learn from each other What is the difference? Using polite words to communicate?

You catch more flies with honey than with vinegar

Re: The C3 Programming Language

#26
I was expecting something very bare-bones, but was pleasantly surprised to see a rich list of new and useful features. And maybe it's not the deepest of things to highlight, but what really made me giggle is how C3's analogue to exceptions are called Excuses.

Re: The C3 Programming Language

#27
The GitHub project has more details: https://github.com/c3lang/c3c

Some ways C3 differs from C:

- No mandatory header files

- New semantic macro system

- Module-based namespacing

- Slices

- Operator overloading

- Compile-time reflection

- Enhanced compile-time execution

- Generics via generic modules

- "Result"-based zero-overhead error handling

- Defer

- Value methods

- Associated enum data

- No preprocessor

- Less undefined behavior, with added runtime checks in "safe" mode

- Limited operator overloading (to enable userland dynamic arrays)

- Optional pre- and post-conditions

Re: The C3 Programming Language

#29
We have solved the better C issue, but nobody seems keen on solving the better compiler issue

Why do we still have to recompile the whole program everytime we make a change, the only project i am aware of who wants to tackle this is Zig with binary patching, and that's imo where we should focus our effort on..

C3 does look interesting tho, the idea of ABI compatibility with C is pretty ingenious, you get to tap into C's ecosystem for free

Re: The C3 Programming Language

#30

This looks like Zig. What problems does this solve that Zig doesn't? Potato - potaato?

Looks can be deceiving.

C3 provides a module system for cleaner code organization across files, unlike Zig where files act as modules with nesting limitations.

C3 offers first class lambdas and dynamic interfaces for flexible runtime polymorphism without Zigs struct based workarounds.

C3s operator overloading enables intuitive math types like vectors, which Zig avoids to prevent hidden control flow.

Post reply on HN