The C3 Programming Language

  > Why have claude generate a python service when you could write a rust or C3 service with compiler doing a lot of heavy lifting around memory bugs?

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.

I don't intend to downplay the effort involved in creating a large project, but it's evident to me that there's a class of "better C" languages for which LLVM is very well suited.

On purely recreational grounds, one can get something small off the ground in an afternoon with LLVM. It's very enjoyable and has a low barrier to entry, really.

So long as only you use your custom C dialect, all is fine. Trouble starts when you'd like others to use it too or when you'd like to use libraries written by people who used a different language, e.g. C.

AT ANY POINT.

No exist, nothing, that could yield more improvements that a new language. Is the ONLY way to make a paradigm(shift) stick. Is the ONLY way to turn "discipline" into "normal work".

Example:

"Everyone knows that is hard to mutate things":

* Option 1: DISCIPLINE

* Option 2: you have "let" and you have "var" (or equivalent) and remove MILLIONS of times where somebody somewhere must think "this var mutates or not?".

"Manually manage memory is hard"

* Option 1: DISCIPLINE

* Option 2: Not need, for TRILLONS of objects across ALL the codebases with any form of automatic memory management, across ALL the developers and ALL their apps to very close to 100% to never worry about it

* Option 3: And now I can be sure about do this with more safety and across threads and such

---

Make actual progress with a language is hard, because there is a fractal of competing things that in sore need of improvement, and a big subset of users are anti-progress and prefer to suffer decades of C (example) than some gradual progress with something like pascal (where a "string" exist).

Plus, a language need to coordinate syntax (important) with std library (important) with how frameworks will end (important) with compile-time AND runtime outcomes (important) with tooling (important).

And miss dearly any of this and you blew it.

But, there is not other kind of project (apart from a OS, FileSystem, DBs) where the potential positive impact will extend to the future as much.

What is the difference? Using polite words to communicate?

The only thing stopping me from just going full C the rest of my career is cstrings and dangling pointers to raw memory that isn’t cleaned up when the process ends.

I mean… C isn't even an unsafe language. It's just that C implementations and ABIs are unsafe. Some fat pointers, less insanely unsafe varargs implementations, UBSan on by default, MTE… soon you're doing pretty well! (Exceptions apply.)

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.

Here is a comparison to Zig in terms of features: https://c3-lang.org/faq/compare-languages/#zig

And yes, they are all system programming languages with a similar level of abstraction that are suited for similar problem. It is good to have choice. It is like asking what do you need Ruby for when you have Python.

That problem was solved decades ago via object files and linkers. Zig needs a different approach because its language features depend on compiling the entire source code as a single compilation unit, but I don't think that C3 has that same "restriction" (not sure though).

Binary patching is another one. It feels a bit messy and I am sceptical that it can be maintained assuming it works at all.

I think a much better approach would be too make the compilers faster. Why does compiling 1M LOC take more than 1s in unoptimized mode for any language? My guess is part of blame lies with bloated backends and meta programming (including compile time evaluation, templates, etc.)

Are you talking about compiling, or linking, or both?

GNU ld has supported incremental linking for ages, and make systems only recompile things based on file level dependencies.

I guess recompilation could perhaps be smarter based on what changed or was added/deleted to a module definition (e.g C header) file, but this would seem difficult to get right. Maybe you just add a new function to a module, so no need to recompile other modules that use it, right? Except what if there is now a name clash and they would fail if recompiled?

Lisp solved that problem 60 years ago.

A meta answer to your question, I guess.

A tagged union always needs as at least as much memory as the biggest type, but even worse, they nudge the programmer towards 'any-types', which basically moves the type checking from compile-time to run-time, but then why use a statically typed language at all?

And even if they are useful in some rare situations, are the advantages big enough to justify wasting 'syntax surface' instead of rolling your own tagged unions when needed?

You mean tagged unions.

A result is already the informal name of the outcome or return value of every regular operation or function call, whereas an Optional is clearly not a regular thing.

I also think, from a pragmatic systems-design point of view, it might make sense to only support the Either/Result pattern. It's not too much boilerplate to add a `faultdef KeyNotInMap`, and then it's clear to the consumer why a real answer was not returned.

You can name it "Result" or (questionably) "Either."

Not "Option," "Optional," or "Maybe;" those are something else.

It also helps code readability to know that a::b is referring to a namespace, without having to go lookup the definition of "a", while a.b is a variable access.

In particular, C3's "path shortening", where you're allowed to write `file::open("foo.txt")` rather than having to use the full `std::io::file::open("foo.txt")` is only made possible because the namespace is distinct at the grammar level.

If we play with changing the syntax because it isn't as elegant as `file.open("foo.txt")`, we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system. That is a fairly steep semantic cost to pay for a nicer namespace separator.

I might have overlooked some options, if so - let me know.