I've been following C3 for sometime now, and I really appreciate the discipline in the design philosophy here.
Neither does it force a new memory model on you, nor does it try to be C++. The killer feature for me is the full ABI compatibility. The fact that I no longer have to write bindings and can just mix C3 files into my existing C build system reduces the friction to near zero.
Kudos to the maintainer for sticking to the evolution, not revolution vision. If you are looking for a weekend language to learn that doesn't require resetting your brain but feels more modern than C99, I highly recommend giving this a shot. Great work by the team.
But can I still write a library in C3 and export the symbols to use in bindings?
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.
Can you link to one that has individual virtual memory processes where the memory isn't freed? It sounds like what you're talking about is just leaking memory and processes have nothing to do with it.
virtual memory requires pages and this sucker doesn’t have them. Only a heap that you can use with heap_x.c
Everything is manual.
I get you people are trying to be cheeky and point out all modern OS’s don’t have this problem but C runs on a crap ton of other systems. Some of these “OS” are really nothing more than a coroutine from pid 0.
Yeah I think I get your problem. I am prototyping a message-passing actor platform running in a flat address space, and virtual memory is the only way I can do cleanup after a process ends (by keeping track of which pages were allocated to a process and freeing them when it terminates)
Without virtual memory, I would either need to force the use of a garbage collector (which is an interesting challenge in itself to design a GC for a flat address space full of stackless coroutines), or require languages with much stricter memory semantics such as Rust so I can be safe everything is released at the end (though all languages are designed for isolated virtual memory and not even Rust might help without serious re-engineering)
Do you keep notes of these types of platforms you’re working on? Sounds fun.
Not anything I can share. I’m trying to modernize these systems but man oh man was the early 80s tech brutal. Rust is something we looked into heavily and are trying to champion but bureaucracy prevents us. Flight Sims have to integrate with it in order to read/write data and it’s 1000x worse than SimConnect from MSFS.
The good news is that this work is dying out. There isn’t a need to modernize old war birds anymore.
Tbh on such a bare bones system I would use my own trivial arena bump allocator and only do a single malloc at startup and a single free before shutdown (if at all, because why even use the C stdlib on embedded systems instead of talking directly to the OS or hardware)
Why is something running on an rtos even able to leak memory?
If your design is going to be dirty, you've got to account for that.
In 30 years, I've never seen a memory leak in the wild.
Set up a memory pool, memory limits, garbage collectors or just switch to an OS/language that will better handle that for you.
Rust is favored among C++ users, but even Python could be a better fit for your use case.
I think the short answer is that it is very hard, time-consuming, and expensive to develop and prove out formal verification build/test toolchains.
I haven’t looked at C3 yet, but I imagine it can’t be used in a formally verified toolchain either unless the toolchain can compile the C3 bits somehow.
Are you really telling someone to 'correct their tone' because one of their many suggestions doesn't work on your mystery platform that you won't mention?
I don't see anything wrong with my tone. I could have been snarky about it.
I provided the C solutions as well but an interpreter written in C could at least allocate objects and threads within the interpreter context and not leak memory allowing you to restart it along any services within which is apparently better than whatever framework people sharing this sentiment are using.
I'm genuinely curious. What kind of mission-critical embedded real-time design dynamically(!) allocates objects and threads and then loses track of them?
PS: On topic, I really like the decisions made in C3
You drop a keyword and the aero-drones report. I do not mind it and I am not going to reply in kind.
I have 0 experience in aerospace but reading up on ARINC-653, it appears to mandate a reasonable RT design with threads and hard slices. Even comfortable with "partitions".
Where and why does the memory leak? If it is inherent in the mandated interfaces, you don't need to feel personally attacked.
If it is a layer laid down by your software –whether legacy or otherwise– why can't you keep track of allocations and ownership? Unless there are 200 bytes left and all slices are accounted for and running on the edge, I feel a solution could be worked out.
I wish you luck switching to Rust maybe a Rust2C translator could help.
Is full ABI compatibility important? I'm having a hard time seeing why.
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.)
How would you integrate C3 with other programming languages (not just C), or even talk to operating systems if you don't implement a common ABI?
And the various system ABIs supported by C compilers are the defacto standards for that (contrary to popular belief there is no such thing as a "C ABI" - those ABIs are commonly defined by OS and CPU vendors, C compilers need to implement those ABIs just like any other compiler toolchain if they want to talk to operating system interfaces or call into libraries compiled with different compilers from different languages).
> How would you integrate C3 with other programming languages (not just C)
That's the job of an FFI. The internal ABI of most languages isn't anything like their FFI, eg any garbage collected language can't use the OS "C" ABI.
Most operating systems don't use the same ABI for kernel syscalls and userland libraries either. (Darwin is an exception where you do have to link a library instead of making syscalls yourself.)
> contrary to popular belief there is no such thing as a "C ABI"
It is a "C ABI" if it has eg null-terminated strings and varargs with no way to do bounds checking.
"Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all.
However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated.
In safe mode, pre- and post-conditions are checked using runtime asserts."
So I'm probably missing something, but it reads to me like you're adding checks to your code, except there's no guarantee that they will run and whether it's at compile or runtime. And sometimes instead of catching a mistake, these checks will instead silently introduce undefined behaviour into your program. Isn't that kinda bad? How are you supposed to use this stuff reliably?
Contracts are a way to express invariants, "This shall always be true".
There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate.
1. Ignore the invariants. You wrote them down, a human can read them, but the machine doesn't care. You might just as well use comments or annotate the documentation, and indeed some people do.
2. Check the invariants. If the invariant wasn't true then something went wrong and we might tell somebody about that.
3. Assume these invariants are always true. Therefore the optimiser may use them to emit machine code which is smaller or faster but only works if these invariants were correct.
So for example maybe a language lets you say only that the whole program is checked, or, that the whole program can be assumed true, or, maybe the language lets you pick, function A's contract about pointer validity we're going to check at runtime, but function B's contract that you must pick an odd number, we will use assumption, we did tell you about that odd number requirement, have the optimiser emit that slightly faster machine code which doesn't work for N=0 -- because zero isn't an odd number assumption means it's now fine to use that code.
I guess the reason I found it surprising is that I would only use 3 (ie risk introducing UB) for invariants that I was very certain were true, whereas I would mostly use 2 for invariants that I had reason to believe might not always be true.
It struck me as odd that you'd use the same tool for scenario's that feel like opposites, especially when you can just switch between these modes with a compiler flag
It feels pretty clear to me that these Contracts should only be used for the “very certain” case. Writing code for a specific compiler flag seems very sketchy, so the programmer should assume the harshest interpretation.
The runtime check thing just sounds like a debugging feature.
In other words, in production mode it makes your code faster and less safe; in debug mode it makes your code slower and more safe.
That's a valid trade-off to make. But it's unexpected for a language that bills itself as "The Ergonomic, Safe and Familiar Evolution of C".
Those pre/post-conditions are written by humans (or an LLM). Occasionally they're going to be wrong, and occasionally they're not going to be caught in testing.
It's also unexpected for a feature that naive programmers would expect to make a program more safe.
To be clear this sounds like a good feature, it's more about expectations management. A good example of that done well is Rust's unsafe keyword.
> That's a valid trade-off to make. But it's unexpected for a language that bills itself as "The Ergonomic, Safe and Familiar Evolution of C".
No, I think this is a very ergonomic feature. It fits nicely because it allows better compilers to use the constraints to optimize more confidently than equivalently-smart C compilers.
I'd argue it's no less safe than the status quo, just easier to use. The standard "assert" can be switched off. There's "__builtin_unreachable". My personal utility library has "assume" which switches between the two based on NDEBUG.
C is a knife. Knives are sharp. If that's a problem then C is the wrong language.
But people are looking at C3, Odin & Zig because they've determined that C is the wrong language for them; many have determined that it's too sharp. C3 has "safe" in its title, they're expecting fewer sharp edges.
I'm not asking for useful optimizations like constraints to go away, I'm asking for them to be properly communicated as being sharp. If you use "unsafe" incorrectly in your rust code, you invite UB. But because of the keyword they chose, it's hardly surprising.
Is C3 using a different terminology than standard design by contract?
Design by contract (as implemented by Eiffel, Ada, etc.) divides the set of conditions into three: Preconditions, postconditions, and invariants. Pre- and postconditions are not invariants by predicate checks on input and output parameters.
Invariants are conditions expressed on types, and which must be checked on construction and modification. E.g. for a "time range" struct with start/end dates, the invariant should be that the start must precede the end.
So the compiler could have debug mode where it checks the invariants and release mode where it assumes they are true and optimizes around that without checking?
Yes, and that same pattern already does exist in C and C++. Asserts that are checked in debug builds but presumed true for optimization in release builds.
Not unless you write your own assert macro using C23 unreachable(), GNU C __builtin_unreachable(), MSVC __assume(0), or the like. The standard one is defined[1] to either explicitly check or completely ignore its argument.
You've described three different features with three different sets of semantics. Which set of semantics is honored? Unknown!
This is not software engineering. This is an appeal to faith. Software engineering requires precise semantics, not whatever the compiler feels like doing. You can't even declare that this feature has no semantics, because it actually introduces a vector for UB. This is the sort of "feature" that should not be in any language selling itself as an improved C. It would be far better to reduce the scope to the point where the feature can have precise semantics.
Typically it's configurable. For example C++ 26 seems to be intending you'll pick a compiler flag to say if you want its do-nothing semantics, or its "tell me about the problem and press on" semantics or just exit immediately and report that. They're not intending (in the standard at least) to have the assume semantic because that is, as you'd expect, controversial. Likewise more fine-grained configuration they're hoping will be taken up as a vendor extension.
My understanding is that C3 will likely offer the coarse configuration as part of their ordinary fast versus safe settings. Do I think that's a good idea? No, but that's definitely not "Unknown".
Any idea how the situation is handled where third party code was written to expect a certain semantic? Is this just one more rough edge to watch out for when integrating something?
- "Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all." means a compiler doesn't have to use the conditions to select how the code will be compiled, or if there's a compile-time error.
- "However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated." basically, it just states the obvious. the compler assumes a true condition is what the code is meant to address. it won't guess how to compile the code when the condition is false.
- "In safe mode, pre- and post-conditions are checked using runtime asserts." it means that there's a 'mode' to activate the conditions during run-time analysis, which implies there's a mode to turn it off. this allows the conditions to stay in the source code without affecting runtime performance when compiled for production/release.
It’s giving you an expression capability so that you can state your intent, in a standardized way, that other tooling can build off. But it’s recognizing that the degree of enforcement depends on applied context. A big company team might want to enforce them rigidly, but a widely used tool like Visual Studio would not want to prevent code from running, so that folks who are introducing themselves to the paradigm can start to see how it would work, through warnings, while still being able to run code.
Perhaps another helpful paradigm are traffic/construction cones with ‘do not cross’ messages. Sometimes nothing happens, other times you run into wet concrete, other times you get a ticket. They’re just plastic objects, easy to move, but you are not meant to cross them in your vehicle. While concrete bollards are a thing, they are only preferable in some situations.
I don't think this analogy fully respects the situation here. These pre/post condition are not just adding a warning to not do something, they also add a potentially bigger danger if they are broken. It's as if you also added a trap behind the construction cone which can do more damage than stepping on the wet concrete!
> documentation clearly states that it's UB to violate them
Only in "fast" mode. The developer has the choice:
> Compilation has two modes: “safe” and “fast”. Safe mode will insert checks for out-of-bounds access, null-pointer deref, shifting by negative numbers, division by zero, violation of contracts and asserts.
The developer has the choice between fast or safe. They don't have a choice for checking pre/post conditions, or at least avoiding UB when they are broken, while getting the other benefits of the "fast" mode.
And all in all the biggest issue is that these can be misinterpreted as a safety feature, while they actually add more possibilities for UB!
Well, the C3 developer could add more fine grained control if people need it...
I don't really see what's your problem. It's not so much different than disabling asserts in production. Some people don't do that, because they rather crash than walking into invalid program state - and that's fine too. It largely depends on the project in question.
> It's not so much different than disabling asserts in production.
Disabling asserts would be equivalent to not having them at all, while this feature introduces _new_ UB. In "fast" mode it's equivalent to using C's `__builtin_assume` or Rust's `std::hint::assert_unchecked`, except it's marketed with a name that makes it appear a safety/correctness feature.
It seems to me like a way to standardize what happens all the time anyway. Compilers are always looking for ways to optimize, and that generally means making assumptions. Specifying those assumptions in the code, instead of in flags to the compiler, seems like a win.
I think they are there to help the compiler so the optimizer might (but doesn't have to) assume they are true. It's sometimes very useful to be able to do so. For example if you know that two numbers are always different or that some value is always less than x. In standard C it's impossible to do but major compilers have a way to express it as extensions. GCC for example has:
if (x)
__builtin_unreachable();
C3 makes it a language construct.
If you want runtime checks for safety you can use assert.
The compiler turns those into asserts in safe/debug mode because that help catching bugs in non performance critical builds.
The way I reason about it is that the contracts are more soft conditions that you expect to not really reach. If something always has to be true, even on not-safe mode, you use "actual" code inside the function/macro to check that condition and fail in the desired way.
The difference from an assert is that for "require" they are compiled into the caller frame, so things like stack traces (which is available in safe mode) will point exactly to where the violation happened.
Because of inlining them at the call site happens, static analysis will already pick up some obvious violations.
Finally, these contracts may be used to compile time check otherwise untyped arguments to macros.
“However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated”
This implies that a compiler would be permitted to remove precisely that actual code that checks the condition in non-safe mode.
My understanding of this was that the UB starts only after the value is passed/returned. So if foo() has a contract to only return positive integers, the code within foo can check and ensure this, but if the calling code does it, the compiler might optimize it away.
Assuming that is correct, it's still exactly the same footgun. Checks like that are introduced to guard against bugs: you are strictly safer to not declare such a constraint.
[ Object-Oriented Software Construction, also called OOSC, is a book by Bertrand Meyer, widely considered a foundational text of object-oriented programming.[citation needed] The first edition was published in 1988; the second edition, extensively revised and expanded (more than 1300 pages), in 1997. Many translations are available including Dutch (first edition only), French (1+2), German (1), Italian (1), Japanese (1+2), Persian (1), Polish (2), Romanian (1), Russian (2), Serbian (2), and Spanish (2).[1] The book has been cited thousands of times. As of 15 December 2011, The Association for Computing Machinery's (ACM) Guide to Computing Literature counts 2,233 citations,[2] for the second edition alone in computer science journals and technical books; Google Scholar lists 7,305 citations. As of September 2006, the book is number 35 in the list of all-time most cited works (books, articles, etc.) in computer science literature, with 1,260 citations.[3] The book won a Jolt award in 1994.[4] The second edition is available online free.[5] ]
So far so good. The feature set is bit random though. Things i personally miss is function overloading, default values in parameters and tuple returns.
I think there is an important difference here from both Option<T> and Result<T, E>: the C3 optional doesn’t allow an arbitrary error type, it’s just a C-style integer error code. I think that makes a lot of sense and fits perfectly with their “evolution, not revolution” philosophy. And the fact that the syntax is ‘type?’ rather than ‘Optional<type>’ also eases any confusion.
I share your distaste for arbitrarily renaming concepts. However, I think if you only have one of the two in the language, Optional is the clearer name.
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.
It's not just arbitrary renaming (Rust Result vs C++ Expected is fine) -- it's choosing a conflicting name for an extremely common abstract data type. If they wanted to call it "Elephant," great, but Optional is a well-known concept and Result/Expected isn't the same thing.
(I don't really object to the idea of skipping a real Optional<T> type in a language in favor of just Result<T, ()>.)
I would guess the two languages have little overlap in who they appeal to, and this is a bit closer to C semantics which is their north star. In C for functions that don’t return a value you often return a null for success or a return code that is a defined error code, which is exactly how Optional works in C3 (but you don’t write the word Optional in the function head). If you need to return a value in C you often pass an out param pointer and then still return either null or a defined error value. The improvement is you just write ‘type?’ for the return type to enable this and you don’t need an out param, but you still need the define (faultdef).
It's not about C semantics it's about the name of a commonly understood concept. What you just described there is the "result" pattern not the "optional" pattern. Of course the designers are free to call it whatever they want but swapping common terminology like that is a blunder from my perspective.
This is not exactly the same as the Result pattern. It doesn't require an ADT feature and does not require the programmer to specify a type for the possible error value.
Also syntactically it is quite different: it means you add exactly one character to the function head to denote that its possible to return an error.
So, calling that feature "Result" could also be confusing to people who have not yet learned this language.
Tell me, was it a blunder when Rust swapped "Result" from the commonly understood name of "Either" from OCaml/Haskell ?
> It doesn't require an ADT feature and does not require the programmer to specify a type for the possible error value.
I don't think that really matters? Result is "A or error" whereas optional is "A or nil".
Admittedly my wording was sloppy. It's technically a subset of the pattern when taken literally. But there's a very strong convention for the error type in C so at least personally I don't find the restriction off putting.
To me the issue is the name clash. This is most definitely not the "optional" pattern. I actually prefer C++'s "expected" over "result" as far as name clarity goes. "Maybe" would presumably also work.
At the end of the day it's all a non-issue thanks to the syntax. I might not agree with what you expressed but I also realize a name that only shows up in the docs isn't going to pose a problem in practice. Probably more than half the languages out there confuse or otherwise subtly screw up remainder, modulus, and a few closely related mathematical concepts but that doesn't get in the way of doing things.
From what I can see there you never write the word “Optional” in your code. This is just what they named the feature which stays close to C semantics without the burden of *out params.
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 differently or what itch they were scratching when choosing or refusing to implement certain features.
Competing with each other would be trying to one-up each other feature-wise, whereas what I have witnessed was things like discussing trade-offs made in different languages and juggling around ideas on if some feature from language A would make sense in language B too.
"Head over heels" is actually a corruption of "heels over head".
It's one of those corruptions which flips the meaning (ironically, in this case!) on its head, or just becomes meaningless over time as it's reinterpreted (like "the exception that proves the rule" or "begs the question").
IMHO the downsides of tagged unions (e.g. what Rust confusingly calls "enums") are big enough that they should only be used rarely if at all in a systems programming language since they're shoehoerning a dynamic type system concept back into an otherwise statically typed language.
A tagged union always needs 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?
tagged unions (not enums, sorry) are not a dynamic type system concept. Actually, I would not be able to name a single dynamically typed language that has them.
As for the memory allocation, I can't see why any object should have the size of the largest alternative. When I do the manual equivalent of a tagged union in C (ie. a struct with a tag followed by a union) I malloc only the required size, and a function receiving a pointer to this object has better not assume any size before looking at the tag. Oh you mean when the object is automatically allocated on the stack, or stored in an array? Yes then, sure. But that's going to be small change if it's on the stack and for the array, well there is no way around it ; if it does not suit your design then have only the tags on the array?
Tagged unions are a thing, whether the language helps or not. When I program in a language that has them then it's probably a sizeable fraction of all the types I define. I believe they are fundamental to programming, and I'd prefer the language to help with syntax and some basic sanity checks; Like, with a dynamical sizeof that to reads the tag so it's easier to malloc the right amount, or a syntax that makes it impossible to access the wrong field (ie. any lightweight pattern matching will do).
In other words, I couldn't really figure out the downside you had in mind :)
> Actually, I would not be able to name a single dynamically typed language that has them.
That's because every type in a dynamically typed language is a tagged union ;) For instance in Javascript you need to inspect a variable with 'typeof' to find out if it is a string, a boolean, a number or something else.
In a dynamically typed language, the runtime system needs to carry information around what type an item actually is, and this is the same thing as the type-tag in a tagged union - and Rust's match is the same sort of runtime type inspection as the typeof in JS, just with slightly different syntax sugar.
> As for the memory allocation, I can't see why any object should have the size of the largest alternative.
...then every Bla object is always at least 16 bytes even when the active item is 'AByte' (assuming an empty String also fits into 16 bytes). Plain unions in C have the same problem of course, but those are rarely used (the one thing where unions are really useful in C (not C++!) is to have different views on the same memory).
> When I program in a language that has them then it's probably a sizeable fraction of all the types I define
...IMHO 'almost always sum types' is a serious design smell, it might be ok in 'everything is a reference' languages like Typescript, but that's because you pay for the runtime overhead anyway, no matter if sum types are used or not.
I don't think we speak the same language.
I was refering to the use case (in C) that's been described by sph.
Where you indeed malloc only the relevant size, and you have to manually and carefully check the tag before casting the payload into the proper type. This is what I am tired of doing over and over and over again, and would like a system programing language to help with.
...what else is a select on a tagged union than 'runtime casting' though. You have a single 'sum type' which you don't know what concrete type it actually is at runtime until you look at the tag and 'cast' to the concrete type associated with the tag. The fact that some languages have syntax sugar for the selection doesn't make the runtime overhead magically disappear.
Not sure why you call it runtime overhead. That’s core logic, nothing fancy, to have a pointer to a number of possible types. That’s what `void *` is, and sometimes you want a little logic to restrict the space of possibilities to a few different choices.
Not having syntactic sugar for this ultra-common use case doesn’t make it disappear. It just makes it more tedious.
There are many implementations and names, and what I refer to runtime casting/any type, which is unnecessary for low-level programming, is the one that uses types and reflection at runtime to be 100% sure you are casting to the correct type. Like Go’s pattern (syntax might be a bit off):
var s *string
var unknown interface{}
// panics at runtime if unknown is not a string pointer
s = unknown.(*string)
This is overkill for low-level programming and has much higher overhead (i.e. having to store type info in the binary, fat pointers, etc.) than tagged unions, which are the bread and butter of computing.
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 can be automatic by default. All string ops return string, there are no special derivative types. Seq ops return seq, there are no special derivative types. Do you pay the price of the occasional copy? Yes. But there are opt-in trapdoors to allocate RC- or manually-managed strings and seqs. Otherwise, the default mode of interacting with heap data is an absolute breeze.
For the life of me, I don't know why other languages haven't leaned harder into such a transformative feature.
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.
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.
It's not just the size of the data but also the amount of copies. Consider a huge tree structure: even if each node is small, doing individual "malloc-style" allocations for millions of nodes would cause a huge performance hit.
Obviously for your use case it's not a problem but other use cases are a different story. Games in particular are very sensitive to performance spikes. Even a naive tracing GC would do better than hitting such an implicit copy every few frames.
I wonder, at which point it is worth it to make a language? I personally implemented generics, slices and error propagation in C… that takes some work, but doable. Obviously, C stdlib goes to the trash bin, but there is not much value in it anyway. Not much code, and very obsolete.
Meanwhile, a compiler is an enormously complicated story. I personally never ever want to write a compiler, cause I already had more fun than I ever wanted working with distributed systems. While idiomatic C was not the way forward, my choice was a C dialect and Go for higher-level things.
How can we estimate these things? Or let's have fun, yolo?
> Meanwhile, a compiler is an enormously complicated story.
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.
Yes, this is fine for basic exploration but, in the long run, I think LLVM taketh at least as much as it giveth. The proliferation of LLVM has created the perception that writing machine code is an extremely difficult endeavor that should not be pursued by mere mortals. In truth, you can get going writing x86_64 assembly in a day. With a few weeks of effort, it is possible to emit all of the basic x86_64 instructions. I have heard aarch64 is even easier but I only have experience with x86_64.
What you then realize is that it is possible to generate quality machine code much faster than LLVM and using far fewer resources. I believe both that LLVM has been holding back compiler evolution and that it is close to if not already at peak popularity. As LLMs improve, the need for tighter feedback loops will necessitate moving off the bloat of LLVM. Moreover, for all of the magic of LLVMs optimization passes, it does very little to prevent the user from writing incorrect code. I believe we will demand more from a compiler backend than LLVM can ever deliver.
The main selling point of LLVM is that you gain access to all of the targets, but this is for me a weak point in its favor. Firstly, one can write a quality self hosting compiler with O(20) instructions. Adding new backends should be trivial. Moreover, the more you are thinking about cross platform portability, the more you are worrying about hypothetical problems as well as the problems of people other than yourself. Get your compiler working well first on your machine and then worry about other machines.
I agree. I've found that, for the languages I'm interesting in compiling (strict functional languages), a custom backend is desirable simply because LLVM isn't well suited for various things you might like to do when compiling functional programming languages (particularly related to custom register conventions, split stacks, etc.).
I'm particularly fond of the organisation of the OCaml compiler: it doesn't really follow a classical separation of concerns, but emits good quality code. E.g. its instruction selection is just pattern matching expressed in the language, various liveness properties of the target instructions are expressed for the virtual IR (as they know which one-to-one instruction mapping they'll use later - as opposed to doing register allocation strictly after instruction selection), garbage collection checks are threaded in after-the-fact (calls to caml_call_gc), its register allocator is a simple variant of Chow et al's priority graph colouring (expressed rather tersely; ~223 lines, ignoring the related infrastructure for spilling, restoring, etc.)
--
As a huge aside, I believe the hobby compiler space could benefit from someone implementing a syntactic subset of LLVM, capable of compiling real programs. You'd get test suites for free and the option to switch to stock LLVM if desired. Projects like Hare are probably a good fit for such an idea: you could switch out the backend for stock LLVM if you want.
Hare is a very pleasant language to use, and I like the way the code looks vs something like Zig. I also like that it uses QBE for the reasons they explained.
That said, I suspect it’ll never be more than a small niche if it doesn’t target Mac and Windows.
If only that was only about emitting byte code in a file then calling the linker... you also have the problem of debug information, optimizers passes, the amount of tests required to prove the output byte code is valid, etc.
>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.
Is there something analogous for those wanting to create language interpreters, not compilers? And preferably for interpreters one wants to develop in Python?
Doesn't have to literally just an afternoon, it could be even a few weeks, but something that will ease the task for PL newbies? The tasks of lexing and parsing, I mean.
There's quite neat lexer and parser generators for Python that can ease the barrier to entry. For example, I've used PLY now and then for very small things.
On the non-generated side, lexer creation is largely mechanical - even if you write it by hand. For example, if you vaguely understand the idea of expressing a disjunctive regular expression as a state machine (its DFA), you can plug that into skeleton algorithms and get a lexer out (for example, the algorithm shown in Reps' "“Maximal-Munch” Tokenization in Linear Time
" paper). For parsing, taking a day or two to really understand Pratt parsing is incredibly valuable. Then, recursive descent is fairly intuitive to learn and implement, and Pratt parsing is a nice way to structure your parser for the more expressive parts of your language's grammar.
Nowadays, Python has a match (pattern matching) construct - even if its semantics are somewhat questionable (and potentially error-prone). Overall, though, I don't find Python too unenjoyable for compiler-related programming: dataclasses (and match) have really improved the situation.
I am a big fan of Ragel[1]. That is a high performance parser generator. In fact, it can generate different types of parsers, very powerful. Unfortunately, it takes a lot of skill to operate. I wrote a parser generator generator to make it all smooth[2], but after 8 years I still can't call it effortless. A colleague of mine once "broke the internet" with a Ragel bug. So, think twice. Still, for weekend activities I highly recommend it, just for the way of thinking it embodies.
Is this the same Ragel that Zed Shaw wrote about in one of his posts back in the day, during Ruby and Rails heydays? I vaguely remwmber that article. I think he used it for Mongrel, his web server.
The worst part of designing a language is the parsing stage.
Simple enough to do it by hand, but there’s a lot of boilerplate and bureaucracy involved that is painfully time-wasting unless you know exactly what syntax you are going for.
But if you adopt a parser-generator such as Flex/Bison you’ll find yourself learning and debugging and obtuse language that has to be forcefully bent to your needs, and I hope your knowledge of parsing theory is up-to-scratch when you’re facing with shift-reduce conflicts or have to decide whether LR or LALR(1) or whatever is most appropriate to your syntax.
> I wonder, at which point it is worth it to make a language?
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.
At the point you want to interface with people outside of your direct influence. That's the value of a language — a shared understanding.
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.
This actually started of by Christoffer (C3 author) contributing to C2 but not being satisfied with the development speed there, wanting to try his own things and moving forward more quickly.
Apparently together with LLVM it was doable to write a new compiler for what is a successor to C2.
I've enjoyed using the C3 language to make some simple games [0] and found it really easy to pick up. The only thing that I got hung up on at first was the temporary memory arenas which I didn't know existed and ultimately really liked.
To be honest, my favorite language is my own language Tentacode [0], closely followed by my recent experimental language Gar [1]. Tenta is not publicly released yet, but the source can be downloaded on github [2]. I've been experimenting with making games in a bunch of languages to inform the design of Tenta by seeing how much I can strip away and still successfully, efficiently make a meaningful game.
I'd argue the opposite. My first thought once the page had loaded was that it looked childish and amateurish, the addition of a Discord chat link in the site navigation only reinforcing that perspective.
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.
Please consider a variable `List{int}[3] x`, this is an array of 3 List{int} containing List{int}. If we do `x[1]` we will get an element of List{int}, from the middle element in the array. If we then further index this with [5], like `x[1][5]` we will get the 5th element of that list.
If we look at `int*`, the dereference will peel off the `*` resulting in `int`.
So, the way C3 types are declared is the most inside one is to the left, the outermost to the right. Indexing or dereferencing will peel off the rightmost part.
C uses a different way to do this, we place `*` and `[]` not on the type but on the variable, in the order it must be unpacked. So given `int (*foo) x[4]` we first dereference it (from inside) int[4], then index from the right.
If we wanted to extract a standalone type from this, we'd have `int(*)[4]` for a pointer to an array of 4 integers. For "left is innermost", the declaration would instead be `int[4]*`. If left-is-innermost we can easily describe a pointer to an array of int pointers (which happens in C3 since arrays don't implicitly decay) int*[4]*. In C that be "int*(*)[4]", which is generally regarded as less easy to read, not the least because you need to think of which of * or [] has priority.
That said, I do think that C has a really nice ordering to subscripts, but it was unfortunately not possible to retain it.
Please consider a variable `List{int}[3] x`, this is an array of 3 List{int} containing List{int}. If we do `x[1]` we will get an element of List{int}, from the middle element in the array. If we then further index this with [5], like `x[1][5]` we will get the 5th element of that list.
I get that motivation. In C++ it's an odd case that where `std::vector<int> x[4]` is "reversed" in a sense compared to `int x[4][100]`. And this quirk is shared with other languages (Java, C#).
But in my experience, mixing generic datatypes like this with arrays is quite rare, and multi-dimensional array like structures with these types is often specified via nesting (`std::vector<std::vector>>`) which avoids confusion.
The argument re. pointers is more convincing though.
I have already opened a discussion about this with the author, and I must say I agree to disagree that a language needs arr[start..end] (inclusive) as well as arr[start:len] (up to len-1) and if you use the wrong one, you’ve now lost a foot and your memory is corrupted.
I see from `test/test_suite/compile_time_introspection/paramsof.c3t` that there is a way to get names & types of function parameters [1]. The language also seems to support default values { e.g. `int foo(int a, int b = 2) {...}` } and even call with keyword arguments/named parameters [2], but I couldn't find any `defaultof` or similar thing in the code. Does anyone know if this is just an oversight / temporary omission?
I don't think it is available no, and it's the first time I heard about such an idea. Thinking on it, this would allow such cursed code (love that :D). I'll put it up for discussion in the Discord as I'm interested in hearing whether `.defaultof` is a good idea or not.
One application of such a feature would be something like a "cligen.c3" (like the Nim https://github.com/c-blake/cligen or its /python/cg.py port or etc.). Mostly it just seems a more complete signature extraction, though. Any other kind of documentation system might benefit.
Zig feels too much in flux, has some incredible ideas, but I really don't like it syntactically wise, and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors which I believe it's the worst thing to ever have been invented and drives me up the wall. Documentation was still pretty bad last I checked, and that's the bare minimum before I can seriously adopt a new language.
C3 feels like home for C developers, there is a real market for language evolutions rather than revolutions (imagine Typescript). The issue is that pretty much nobody knows about C3, most posts about it never get any traction on HN, and it's hard to choose a language with no mind share for anything more serious than toys.
Odin is quite nice, has some hype behind it, deservedly. Feels like a nice improvement over C without completely throwing the baby away with the bathwater; perhaps one negative thing might be that it's so opinionated it feels less of a general purpose language than others (with the main dev focused on graphics, there's a lot of syntax sugar for that use case which feels out of place for anyone that is not writing desktop UI or games). Also, while I agree with the author's choice on not rewriting the compiler itself in Odin, as most other languages do, it doesn't strike much confidence that the author would rather develop in C++ than eat his own dog food.
I must admit I don't keep up with alternative languages much any more because I believe the Lindy effect to be a force multiplier, and for serious applications it's better to stick with something that is known to work, despite its shortcomings. You only have a few points you can spend on innovation, and if you're developing a complex application, at the very least you want a rock-solid base to build upon. This is why I'm still sticking with C for very low-level programming.
> and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors
FWIW, they also have a goal to emit as much output as possible, even in the face of compilation errors. They have stated that even syntax errors should have the compiler exit with a non-zero exit code, but still produce an executable that will give you a syntax error at runtime. The point of this being to allow you to iterate quickly, but force things like CI to fail.
The Eclipse Java Compiler is similar to this, and Haskell can defer type errors to runtime. You wouldn't make production builds that way, but it's otherwise a perfectly valid mode for a compiler to operate in.
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.
It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still.
I suppose it has less of the ability to blow your foot off and so isn't a very dangerous way to code, therefore not cool. If any of you younger folk haven't looked at it, I'd suggest having a look, there is Delphi - a cross platform dev environment that addresses all these problems and compiles in less than a second, or there's the free, open source alternative Lazarus. They also compile to mobile platforms and even the raspberry pi (Lazarus) or Arduino.
If you like contracts then ADA is the way to go, but I haven't used this for many years, so not sure what is the state of the compilers.
Both Pascal and C (and their offspring) are wonderful gifts for us to receive from their designers, and I enjoy writing code in both.
> It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still.
Here's Brian Kernighan's view on the shortcomings of Pascal resulting from a practical book project idea:
Isn't that interesting, I do vaguely recall this from many years ago. These complaints have mostly been addressed a long time ago, the solutions were mostly stolen from C where applicable, I refer to Delphi, but I think Lazarus is the same. These are the dot points from the summary:
- Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.
There's a TArray<T> type now, it uses generics and can be declared if you like, also lots of other structured types - lists, stacks etc, though the original array type is still available for backwards compatibility. There was also an array of without size to pass as a parameter but TArray is mostly used now.
- The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality'' of a program - variables require much more scope than they ought to.
Statics are now a thing
- The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.
This can be an issue still, though the one pass is why the compiler is fast.
- The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
Not an issue any more, it has packages and libraries
- The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
Not an issue any more it uses the C method
- The 'case' statement is emasculated because there is no default clause.
Does now, though a case with string alternatives still doesn't exist in Delphi, Lazarus has it.
- The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.
Many different sorts of file access - random, binary etc
- The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
Not true any more, it has packages and include files (though limited), and the macro facility is very limited, nothing like C's but its not really needed, you can have inline functions for the performance boost macros would give you (stolen from C++)
- There is no escape.
This refers to the type system, you can use casts just like C now
Just as a counterpoint C still doesn't have a standard string type. Delphi has generics now like C++, and many of the things that are external libraries in C/C++ are just included. If you really need high performance then C is still better, but what I've done in the past is just rewrite bits in C, though the need for this is very infrequent. If you look at comparable things for Delphi in C++ like Qt's slots and signals for example, the Delphi solution is so much more elegant, and Qt is perhaps the only comparable commercial cross platform library to Delphi's Firemonkey. It's really worth a look, times have changed. There's a reason MS hired away Anders Hejlsberg to architect C# and then typescript.
I would argue that Go is the closest spiritual descendant of Wirth's languages. If you changed braces into BEGIN/END and so on, it would look a ton like Oberon or Modula 2/3.
It adds features (goroutines, channels, slices), changes some (modules become packages), the generics are a little different,
and it eschews some of Wirth's pragmatic type safety ideas (like range types). It even has ":=" for assignment.
The general spirt is the same, I think: Small language, simple compiler (compared to many other languages), "dumb" type system, GC, engineering-focused rather than-type theory-focused.
The part of Delphi that is interesting, and isn't really mentioned much for some reason, is the component library - VCL (windows only) and Firemonkey (Cross platform). Like the language does what's needed, garbage collection would be nice, and is on iOS, but the really nice part is the ability to make things by dragging and dropping visual and non visual components, and making your own components in the same language.
Sounds intriguing. But then, the first thing I noticed in their example is a double-colon scope operator.
I understand that it's part of the culture (and Rust, C#, and many other languages), but I find the syntax itself ugly.
I dunno. Maybe I have the visual equivalent of misophonia, in addition to the auditory version, but :: and x << y << z << whatever and things like that just grate.
I like C. But I abhor C++ with a passion, partly because of what, to me, is jarring syntax. A lot of languages have subsequently adopted this sort of syntax, but it really didn't have that much thought put into it at the beginning, other than that Stroustrup went out of his way to use different symbols for different kinds of hierarchies, because some people were confused.
Think about that. The designer of a language that is practically focused on polymorphism went out of his way to _not_ overload the '.' operator for two things that are about as close semantically as things ever get (hierarchical relationships), simply because some of his customers found that overloading to be confusing. (And yet, '<<' is used for completely disparate things in the same language, but, of course, apparently, that is not at all confusing.)
I saw in another comment here just now that one of the differentiators between zig and C3 is that C3 allows operator overloading.
Honestly, that's in C3's favor (in my book), so why don't they start by overloading '.' and get rid of '::' ?
Two reasons, the second being the important: (1) If I read "io.print", is this "the print function in the module io" or "the print method for the variable io". There tends to be an overlap in naming here so that's a downside (2) parsing and semantic checking is much easier if the namespace is clear from the grammar.
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.
I have never found either (1) or (2) to be a problem in hundreds of thousands of lines of Python.
> In particular, C3's "path shortening" ... we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system.
You can easily and explicitly shorten paths in other languages. For example, in Python "from mypackage.mysubpackage import mymodule; mymodule.myfunc()"
Python even gracefully handles name collisions by allowing you to change the name of the local alias, e.g. "from my_other_package.mysubpackage import mymodule as other_module"
I find the "from .. import" to be really handy to understand touchpoints for other modules, and it is not very verbose, because you can have a comma-separated list of things that you are aliasing into the current namespace.
(You can also use "from some_module import *" to bring everything in, which is highly useful for exploratory programming but is an anti-pattern for production software.)
Of course you can explicitly shorten paths. I was talking about C3's path shortening which is doing this for you. This means you do not need to alias imports, which is otherwise how languages do it.
I don't want to get too far into details, but it's understandable that people misunderstand it if they haven't used it, as it's a novel approach not used by any other language.
Oh, I understand it. I just think that (a) explicit is better than implicit; and (b) the amount of characters that Python requires to keep imports explicit is truly minimal, and is a huge aid to figuring out where things came from.
Let's say you have find foo::bar(), then we know that the path is <some path>::foo, the function is `bar` consequently we search for all modules matching the substring ::foo, and depending on whether (1) we get multiple matches (2) we only get a match that is not properly visible (3) we get a match that isn't imported, (4) we get no match or (5) we get a visible match, we print different things. In the case 1-4, we give good errors to allow the user to take the proper action.
If instead we had foo.bar(), we cannot know if this is the method "bar" on local or global foo, or a function "bar()" in a path matching the substring "foo". Consequently we cannot properly issue 4, since we don't know what the intent was.
So far, not so bad. Let's say it's instead foo::baz::bar(). In the :: case, we don't have any change in complexity, we simply match ::foo::baz instead.
However, for foo.baz.bar(), we get more cases, and let us also bring in the possibility of a function pointer being invoked:
1. It is invoking the method bar() on the global baz is a module that ends with "foo"
2. It is calling a function pointer stored in member bar on the global variable baz is a module that ends with "foo"
3. It is calling the function bar() in a module that ends with "foo.baz"
4. It is calling the function pointer stored in the global bar in a module that ends with "foo.baz"
5. It is invoking the method bar on the member baz of the local foo
6. It is calling a function pointer stored in the member bar in the member baz of the local foo
This might seem doable, but note that for every module we have that has a struct, we need to speculatively dive into it to see if it might give a match. And then give a good error message to the user if everything fails.
Note here that if we had yet another level, `foo.bar.baz.abc()` then the number of combinations to search increases yet again.
This is exactly the syntax Python uses, and there is no "search" per se.
Either an identifier is in the current namespace or not.
And if it is in the current namespace, there can only be one.
The only time multiple namespaces are searched is when you are scoped within a function or class which might have a local variable or member of the same name.
> find foo::bar(), then we know that the path is <some path>::foo, the function is `bar` consequently we search for all modules matching the substring ::foo,
The only reason you need to have a search and think about all the possibilities is that you are deliberately allowing implicit lookups. Again, in Python:
1) Everything is explicit; but
2) you can easily create shorthand aliases when you want.
> note that for every module we have that has a struct, we need to speculatively dive into it to see if it might give a match. And then give a good error message to the user if everything fails.
Only if you rely on search, as opposed to, you know, if you 'import foo' then 'foo' refers to what you imported.
It's horses for courses, right? Pick the right language for the job. LISP was designed for 60's era GOFAI, designed for that with code not differentiated from data, but a COBOL or FORTRAN even BASIC programmer would presumably (and justifiably from the perspective of those typical use cases) regard LISP as the toy/unserious language.
As I get older, I realize that everybody's sweet spot is a little different.
Lisp and APL both have their adherents.
I personally find a bit more syntax than lisp to be nice. Occasionally I long for the homoiconicity of lisp; otoh, many of the arguments for it fall flat with me. For example, DSLs -- yeah, no, it's hard enough to get semi-technical people to use DSLs to start with, never mind lisp-like ones.
It definitely is possible, because languages like Vlang (for example), are able to use '.' instead of '::'. Always saw this as language creator preference, versus any inescapable technical reason.
Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy.
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.
> Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy.
That's a perspective. Are we talking about the 'bar' that comes from 'foo' or are we talking about the 'bar' that comes from 'baz'?
But another perspective is that 'foo' is important and provides several facilities that are intimately related to foo, so 'bar' is simply one of the features of foo.
> It also helps code readability to know that a::b is referring to a namespace
For you, perhaps. As someone who reads a lot of Python, I don't personally find this argument persuasive.
Right - I just wanted to point out that not everyone is going to conceptualize namespaces and members, the same as structs and members, as both being about "hierarchy".
I'm generally of the camp that code is written once, read many times, and that anything that adds to readability is therefore a win.
I like the idea of strict improvements to C without taking anything away or making any controversial (as far as language design goes) choices.
One thing I am wondering is why new low level languages remove goto (Zig, C3, Nim). I think it's sometimes the cleanest, most readable and most maintainable solution. I get that's rare but especially when you are expressing low level algorithm operating on arrays/blocks/bit streams it can be useful. It's not that you can't express it with "structured" constructs but sometimes it's just not the best way.
I get removing backwards goto when you provide alternative constructs for state machines but forward one is useful in other contexts.
Is it a purely ideological choice or does it make the compiler simpler/faster?
In C3 it's complicated. On one hand the lack of goto means defers are more straightforward, but the biggest problem is that once you have a different way to handle cleanup and you have labelled break/continue, and you have the nextcase to jump to arbitrary cases, there's very little left for goto to do.
It is limited to when you want to jump from within an if statement out across some statements and run the remaining code. It saves one level of indentation, but being so rare, it's hard to justify the complexity.
I keep going back and see if I find some usecase that could motivate putting goto back in but it so far nothing. The "nextcase" allows C3 to express arbitrary jumps back and forth, although not as straightforward as goto.
Looking at my own code one case I wouldn't get with defer and better switch is avoiding a flag pattern.
For example when you iterate over a block and check if positions are 0 (+ do some work) and once you encounter a non zero you jump to a different "non-empty" section but if it's zeros to the end you jump over non-empty to go to end section. Without goto you need to set a flag and add another conditional there.
Other than that what you mentioned: flatting the if structure is nice. When you have a few simple cases and then a complicated one and a finishing session at the end it's just cleaner and easier to read with goto.
It could be handled with a switch statement but not everything is "switchable" and the way most people write it it's another 2 indentation levels (1 with a convention of not indenting cases but I see C3 docs avoid it).
I get it's rare but goto (other than error handling) is rare and I don't think people have a tendency to abuse it. If anything people abuse "structured" construct building an arrow pattern with multiple indentation levels for no good reason.
That's the kind of thing I was thinking about. You can solve that with a switch in C3, but it's not as nice. However, this accounts for no more than 1% of all my goto uses (from a quick inspection), which is too little to build a feature from (discipline is needed to prevent a language from ballooning, it's hard to say no). I am looking for some use for it that can redeem its inclusion.
I agree it's very rare.
I have this goto. A few that go to common return block that can be handled by other means and the rest is either error handling or things handled by labelled break or switch.
I mean we know you can program without it and defer/labelled switch and labelled break/continue cover 99%+ of use cases of it. I am still not convinced those are in fact easier to read but I get it's a reasonable design choice to make.
They have different wins. I think labelled break/continue help because they are clearer in locally expressing what the point is. If you see `goto NEXT;` you can kind of guess the intention, but `continue OUTER;` doesn't require you to read the code at the label and check what's happening there. `defer catch` and `defer try` helps avoiding some booleans otherwise needed with just a basic defer. `defer` on its own otherwise sometimes needs booleans to track what should be closed. With goto those naturally go to different cleanup sections.
I keep revisiting goto though. I like it a lot for its simplicity.
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
> Why do we still have to recompile the whole program everytime we make a change
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).
To a large extent, this problem is primarily due to slow compilation. It is possible to write a direct to machine code compiler that compiles at greater than one million lines per second. That is more code than I am likely to write in my lifetime. A fast compiler with no need for incremental compilation is a superior default and can always be adapted to add incrementalism when truly needed.
C3 doesn't have a recompile everything model, in fact it's pretty much designed around supporting separate compilation and dynamic linking (unlike Zig and Odin), it even supports Objective-C style dynamic calls.
Separate compilation is one solution to the problem of slow compilation.
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.)
Ha, I did not see your post before making mine. You are correct in your assessment of the blame.
Moreover, I view optimization as an anti-pattern in general, especially for a low level language. It is better to directly write the optimal solution and not be dependent on the compiler. If there is a real hotspot that you have identified through profiling and you don't know how to optimize it, then you can run the hotspot through an optimizing compiler and copy what it does.
> Why do we still have to recompile the whole program everytime we make a change
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?
It seems great to have something that is C but cleaned up, although clay had all that with templates and move semantics.
I think leaving out move semantics and destructors is inexcusable at this point. It is not only fundamental, but doesn't affect things like standard libraries, runtimes, or ABIs.
But it of course move semantics and destructors affect all things. If the goal is to call and be callable from C without special constructs, how would you make the C code respect the move semantics and destructors?
Was an interesting ready but sad to see that there is nothing special for matching or restructuring tagged unions (beyond the special cased optional type). That's one of the things from Rust I miss the most in my day to day work with C/C++.
Why have features but then the compiler doesn’t make programs that enforce it…
I’m seeing a lot of this in the docs:
“However, just like for const the compiler might not detect whether the annotation is correct or not! This program might compile, but will behave strangely:”
This seems pretty neat! Still holding out for a language with Go's runtime and compilation and performance characteristics, but language syntax and semantics like Gleam... Maybe one day
Unfortunately the current trend among new languages seems to be eschewing GC; a clear mistake IMO — we don't really need yet another low-level systems programming language, but we badly need the go-to GC'd lang — one that'd take the faults of Java and Go into account.
There is lots of languages that already do that: Kotlin, Dart, typescript, OCaml, D, Haskell and the list goes on!
Non GC languages OTOH are rare and we absolutely need more of them!
I like OCaml in theory a lot! This is not a bad suggestion. The problem is it doesn't have the awesome concurrency model of Go (just barely got regular threads recently), and IMHO the build and package management situation for OCaml isn't very good. Plus, I don't know, I just subjectively don't like using it, and the ecosystem isn't very good. Ecosystem is very important for me.
I understood the sibling comment recommending Ocaml and to a lesser extent Borgo, but OP is looking for a high level functional programming language based on giving Gleam as the reference point. How does C# fit here.
I do think the compilation speed and runtime is at least in the same ballpark, but C#, while a perfectly fine language, is definitely not a functional language in syntax or semantics.
Interesting! If today I wanted to start a project in a C-like language, I'd have chosen Zig. Would you tell a rough overview of how C3 differs from something like Zig?
C3 is pretty much aimed at those who would use C for a task but prefer something a bit more modern. I find it more fun to program in compared to plain C, and it's definitely more simple than reaching for C++.
I see 'fn void main()'. There's probably a good reasson but why the 'fn'? It doesn't really add anything because 'void main()' already communicates it's a function.
The main draw of C (to me) is it's terseness and it's avoidance of 'filler' syntax words.
I admit I didn't (yet) look much further into it, but this first thing jumped out to me and slightly diminished my desire to look further into C3...
Sadly many of us are so used to the C fall-through behavior that this would be quite a surprise.
Personally, I'd rather see a different syntax switch (perhaps something like the Java pattern switch) or no switch at all than one that looks the same as in all C-style languages but works just slightly differently.
It reads naturally but I can see people getting tripped up writing this. Worse for changing existing code. Refactor in a way that removes a body? Likely forget to add a breake
I agree it's not the best choice.
I mean it's true that you almost always want fall-through when the body is empty and break where it isn't but maybe it would be better to at least require explicit break (or fall-through keyword) and just make it a compiler error if one is missing and the body is not empty. That would be the least surprising design imo.
I keep thinking about perhaps LLMs would make writing code in these lower-level-but-far-better-performing languages in vogue. 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?
> 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?
The architecture of my current project is actually a Python/Qt application which is a thin wrapper around an LLM generated Rust application. I go over almost every line of the LLM generated Rust myself, but that machine is far more skilled at generating quality Rust than I currently am. But I am using this as an opportunity to learn.
> that machine is far more skilled at generating quality Rust than I currently am. But I am using this as an opportunity to learn.
I'm currently doing this with golang. It is not that bad of an experience. LLMs do struggle with concurrency, though. My current project has proved to be pretty challenging for LLMs to chew through.
Having worked with rust in the past couple years, I can say that it hands down much better fit for LLMs than Python thanks to its explicitness and type information. This provides a lot of context for LLM to incrementally grow the codebase.
You still have to watch it, of course. But the experience is very pleasant.
You can throw Claude at a completely private Rust code base with very specific niche requirements and conventions that are not otherwise common in Rust and it will demonstrate a remarkably strong ability to explain it and program according to the local idioms. I think your statement is based on liking a popular language, not on evidence..
I find that having a code-base properly scaffolded really, really helps a model handle implementing new features or performing bug-fixes. There's this grey area between greenfield and established that I hit every time I try to take a new project to a more stable state. I'm still trying to sort out how to get through that grey area.
I had Claude nearly one-shot (well, sequence-of-oneshots) a fairly complex multi-language file pretty-printer, but only after giving it a very specific 150-line TODO file with examples of correct results, so I think pure greenfield is very achievable if you steer it well enough. I did have to really focus on writing the tasks to be such that there wasn't much room for going off the rails, thought about their ordering, etc; it was pretty far from vibecoding, produced a strict data-driven test suite, etc.
But ultimately, I agree with you, in most projects, having enough existing style, arranged in a fairly specific way, for Claude to imitate makes results a lot better. Or at least, until you get to that "good-looking codebase", you have to steer it a lot more explicitly, to the level of telling it what function signatures to use, what files to edit, etc.
Currently on another project, I've had Claude make ~10 development spikes on specific ~5 high-uncertainty features on separate branches, without ever telling it what the main project structure really is. Some of the spikes implement the same functionality with e.g. different libraries, as I'm exploring my options (ML inference as a library is still a shitshow). I think that approach has some whiff of "future of programming" to it. Previously I would have spent more effort studying the frameworks up front and committed to a choice harder, now it's "let's see if this is good enough".
I think the same. It sounds quite more practical to have LLMs code in languages whose compilers provide as much compile-time guardrails as possible (Rust, Haskell?). Ironically in some ways this applies to humans writing code as well, but there you run into the (IMO very small) problem of having to write a bit more code than with more dynamic languages.
The price of not requiring fn is mandatory forward declarations, header files, and a slower parser (because then the syntax requires knowing whether every symbol is a type or a function/variable to be parsed correctly)
I think that trade-off is absolutely not worth it. I'll take order-independent declarations and fast modules over strictly sticking to C syntax any day.
> We do want WASM to be working really well, so if you’re interested in writing something in WASM please reach out to the C3 development team and we’ll help you get things working.
I've been following C3 for sometime now, and I really appreciate the discipline in the design philosophy here.
Neither does it force a new memory model on you, nor does it try to be C++. The killer feature for me is the full ABI compatibility. The fact that I no longer have to write bindings and can just mix C3 files into my existing C build system reduces the friction to near zero.
Kudos to the maintainer for sticking to the evolution, not revolution vision. If you are looking for a weekend language to learn that doesn't require resetting your brain but feels more modern than C99, I highly recommend giving this a shot. Great work by the team.
But can I still write a library in C3 and export the symbols to use in bindings?
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.
Maybe I misunderstand but if the process ends its entire virtual address space is gone no? Did you mean subprocess or something different?
On some OS’s
If it isn't cleaned up by process exit, it's not really a process, is it? Just another co-routine running in the bare metal kernel or whatever.
Which one specifically does ending a process not clean up the memory?
Any flat memory rtos. Not everything is *nix.
For example microcontrollers or aerospace systems.
Can you link to one that has individual virtual memory processes where the memory isn't freed? It sounds like what you're talking about is just leaking memory and processes have nothing to do with it.
virtual memory requires pages and this sucker doesn’t have them. Only a heap that you can use with heap_x.c
Everything is manual.
I get you people are trying to be cheeky and point out all modern OS’s don’t have this problem but C runs on a crap ton of other systems. Some of these “OS” are really nothing more than a coroutine from pid 0.
I have 30 years experience in this field.
Yeah I think I get your problem. I am prototyping a message-passing actor platform running in a flat address space, and virtual memory is the only way I can do cleanup after a process ends (by keeping track of which pages were allocated to a process and freeing them when it terminates)
Without virtual memory, I would either need to force the use of a garbage collector (which is an interesting challenge in itself to design a GC for a flat address space full of stackless coroutines), or require languages with much stricter memory semantics such as Rust so I can be safe everything is released at the end (though all languages are designed for isolated virtual memory and not even Rust might help without serious re-engineering)
Do you keep notes of these types of platforms you’re working on? Sounds fun.
Not anything I can share. I’m trying to modernize these systems but man oh man was the early 80s tech brutal. Rust is something we looked into heavily and are trying to champion but bureaucracy prevents us. Flight Sims have to integrate with it in order to read/write data and it’s 1000x worse than SimConnect from MSFS.
The good news is that this work is dying out. There isn’t a need to modernize old war birds anymore.
Tbh on such a bare bones system I would use my own trivial arena bump allocator and only do a single malloc at startup and a single free before shutdown (if at all, because why even use the C stdlib on embedded systems instead of talking directly to the OS or hardware)
RTOSes I'm aware of call them tasks rather than processes, specifically because they don't provide the sort of isolation that a "proper" OS does.
Why is something running on an rtos even able to leak memory? If your design is going to be dirty, you've got to account for that. In 30 years, I've never seen a memory leak in the wild. Set up a memory pool, memory limits, garbage collectors or just switch to an OS/language that will better handle that for you. Rust is favored among C++ users, but even Python could be a better fit for your use case.
I think the short answer is that it is very hard, time-consuming, and expensive to develop and prove out formal verification build/test toolchains.
I haven’t looked at C3 yet, but I imagine it can’t be used in a formally verified toolchain either unless the toolchain can compile the C3 bits somehow.
python is not an option in this environment. Correct your tone.
Are you really telling someone to 'correct their tone' because one of their many suggestions doesn't work on your mystery platform that you won't mention?
I don't see anything wrong with my tone. I could have been snarky about it.
I provided the C solutions as well but an interpreter written in C could at least allocate objects and threads within the interpreter context and not leak memory allowing you to restart it along any services within which is apparently better than whatever framework people sharing this sentiment are using.
I'm genuinely curious. What kind of mission-critical embedded real-time design dynamically(!) allocates objects and threads and then loses track of them?
PS: On topic, I really like the decisions made in C3
ARINC-653
But no, tell me I’m wrong, tell me I’m an idiot for doing things this way, put me down for asking, and then deny my reality when I tell you.
This is why people dislike software engineers, they think they know everything.
You're the only one being aggressive here.
You drop a keyword and the aero-drones report. I do not mind it and I am not going to reply in kind.
I have 0 experience in aerospace but reading up on ARINC-653, it appears to mandate a reasonable RT design with threads and hard slices. Even comfortable with "partitions".
Where and why does the memory leak? If it is inherent in the mandated interfaces, you don't need to feel personally attacked.
If it is a layer laid down by your software –whether legacy or otherwise– why can't you keep track of allocations and ownership? Unless there are 200 bytes left and all slices are accounted for and running on the edge, I feel a solution could be worked out.
I wish you luck switching to Rust maybe a Rust2C translator could help.
> But can I still write a library in C3 and export the symbols to use in bindings?
Yes, it has the same ABI.
> dangling pointers to raw memory that [are not] cleaned
How do you feel about building special constructs to automatically handle these ?
I totally can but my gripe is about not wanting to.
c3 has a @pool annotation that makes a block use an arena to allocate, that should help since all memory is freed upon exiting the block.
That is dope
Is full ABI compatibility important? I'm having a hard time seeing why.
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.)
How would you integrate C3 with other programming languages (not just C), or even talk to operating systems if you don't implement a common ABI?
And the various system ABIs supported by C compilers are the defacto standards for that (contrary to popular belief there is no such thing as a "C ABI" - those ABIs are commonly defined by OS and CPU vendors, C compilers need to implement those ABIs just like any other compiler toolchain if they want to talk to operating system interfaces or call into libraries compiled with different compilers from different languages).
> How would you integrate C3 with other programming languages (not just C)
That's the job of an FFI. The internal ABI of most languages isn't anything like their FFI, eg any garbage collected language can't use the OS "C" ABI.
Most operating systems don't use the same ABI for kernel syscalls and userland libraries either. (Darwin is an exception where you do have to link a library instead of making syscalls yourself.)
> contrary to popular belief there is no such thing as a "C ABI"
It is a "C ABI" if it has eg null-terminated strings and varargs with no way to do bounds checking.
Dumb question about contracts: I was reading the docs (https://c3-lang.org/language-common/contracts/) and this jumped out
"Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all.
However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated.
In safe mode, pre- and post-conditions are checked using runtime asserts."
So I'm probably missing something, but it reads to me like you're adding checks to your code, except there's no guarantee that they will run and whether it's at compile or runtime. And sometimes instead of catching a mistake, these checks will instead silently introduce undefined behaviour into your program. Isn't that kinda bad? How are you supposed to use this stuff reliably?
(otherwise C3 seems really cool!)
Contracts are a way to express invariants, "This shall always be true".
There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate.
1. Ignore the invariants. You wrote them down, a human can read them, but the machine doesn't care. You might just as well use comments or annotate the documentation, and indeed some people do.
2. Check the invariants. If the invariant wasn't true then something went wrong and we might tell somebody about that.
3. Assume these invariants are always true. Therefore the optimiser may use them to emit machine code which is smaller or faster but only works if these invariants were correct.
So for example maybe a language lets you say only that the whole program is checked, or, that the whole program can be assumed true, or, maybe the language lets you pick, function A's contract about pointer validity we're going to check at runtime, but function B's contract that you must pick an odd number, we will use assumption, we did tell you about that odd number requirement, have the optimiser emit that slightly faster machine code which doesn't work for N=0 -- because zero isn't an odd number assumption means it's now fine to use that code.
I guess the reason I found it surprising is that I would only use 3 (ie risk introducing UB) for invariants that I was very certain were true, whereas I would mostly use 2 for invariants that I had reason to believe might not always be true. It struck me as odd that you'd use the same tool for scenario's that feel like opposites, especially when you can just switch between these modes with a compiler flag
It feels pretty clear to me that these Contracts should only be used for the “very certain” case. Writing code for a specific compiler flag seems very sketchy, so the programmer should assume the harshest interpretation.
The runtime check thing just sounds like a debugging feature.
In other words, in production mode it makes your code faster and less safe; in debug mode it makes your code slower and more safe.
That's a valid trade-off to make. But it's unexpected for a language that bills itself as "The Ergonomic, Safe and Familiar Evolution of C".
Those pre/post-conditions are written by humans (or an LLM). Occasionally they're going to be wrong, and occasionally they're not going to be caught in testing.
It's also unexpected for a feature that naive programmers would expect to make a program more safe.
To be clear this sounds like a good feature, it's more about expectations management. A good example of that done well is Rust's unsafe keyword.
> That's a valid trade-off to make. But it's unexpected for a language that bills itself as "The Ergonomic, Safe and Familiar Evolution of C".
No, I think this is a very ergonomic feature. It fits nicely because it allows better compilers to use the constraints to optimize more confidently than equivalently-smart C compilers.
I'll give you "more ergonomic" if you'll give me "less safe".
I'd argue it's no less safe than the status quo, just easier to use. The standard "assert" can be switched off. There's "__builtin_unreachable". My personal utility library has "assume" which switches between the two based on NDEBUG.
C is a knife. Knives are sharp. If that's a problem then C is the wrong language.
But people are looking at C3, Odin & Zig because they've determined that C is the wrong language for them; many have determined that it's too sharp. C3 has "safe" in its title, they're expecting fewer sharp edges.
I'm not asking for useful optimizations like constraints to go away, I'm asking for them to be properly communicated as being sharp. If you use "unsafe" incorrectly in your rust code, you invite UB. But because of the keyword they chose, it's hardly surprising.
Maybe also worth mentioning is that some static analysis is done using these contracts as well. With more coming.
Is C3 using a different terminology than standard design by contract?
Design by contract (as implemented by Eiffel, Ada, etc.) divides the set of conditions into three: Preconditions, postconditions, and invariants. Pre- and postconditions are not invariants by predicate checks on input and output parameters.
Invariants are conditions expressed on types, and which must be checked on construction and modification. E.g. for a "time range" struct with start/end dates, the invariant should be that the start must precede the end.
So the compiler could have debug mode where it checks the invariants and release mode where it assumes they are true and optimizes around that without checking?
Yes, and that same pattern already does exist in C and C++. Asserts that are checked in debug builds but presumed true for optimization in release builds.
Not unless you write your own assert macro using C23 unreachable(), GNU C __builtin_unreachable(), MSVC __assume(0), or the like. The standard one is defined[1] to either explicitly check or completely ignore its argument.
[1] https://port70.net/~nsz/c/c11/n1570.html#7.2
Yeah, I meant it's common for projects to make their own 'assume' macros.
In Rust you can wrap core::hint::assert_unchecked similarly.
You've described three different features with three different sets of semantics. Which set of semantics is honored? Unknown!
This is not software engineering. This is an appeal to faith. Software engineering requires precise semantics, not whatever the compiler feels like doing. You can't even declare that this feature has no semantics, because it actually introduces a vector for UB. This is the sort of "feature" that should not be in any language selling itself as an improved C. It would be far better to reduce the scope to the point where the feature can have precise semantics.
> Which set of semantics is honored?
Typically it's configurable. For example C++ 26 seems to be intending you'll pick a compiler flag to say if you want its do-nothing semantics, or its "tell me about the problem and press on" semantics or just exit immediately and report that. They're not intending (in the standard at least) to have the assume semantic because that is, as you'd expect, controversial. Likewise more fine-grained configuration they're hoping will be taken up as a vendor extension.
My understanding is that C3 will likely offer the coarse configuration as part of their ordinary fast versus safe settings. Do I think that's a good idea? No, but that's definitely not "Unknown".
Any idea how the situation is handled where third party code was written to expect a certain semantic? Is this just one more rough edge to watch out for when integrating something?
not enforced for any given implementation is hardly "unknown". presumably the tin comes with a label saying what's inside
- "Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all." means a compiler doesn't have to use the conditions to select how the code will be compiled, or if there's a compile-time error.
- "However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated." basically, it just states the obvious. the compler assumes a true condition is what the code is meant to address. it won't guess how to compile the code when the condition is false.
- "In safe mode, pre- and post-conditions are checked using runtime asserts." it means that there's a 'mode' to activate the conditions during run-time analysis, which implies there's a mode to turn it off. this allows the conditions to stay in the source code without affecting runtime performance when compiled for production/release.
It’s giving you an expression capability so that you can state your intent, in a standardized way, that other tooling can build off. But it’s recognizing that the degree of enforcement depends on applied context. A big company team might want to enforce them rigidly, but a widely used tool like Visual Studio would not want to prevent code from running, so that folks who are introducing themselves to the paradigm can start to see how it would work, through warnings, while still being able to run code.
This is not just expressing intent. The documentation clearly states that it's UB to violate them, so you need to be extra careful when using them.
Perhaps another helpful paradigm are traffic/construction cones with ‘do not cross’ messages. Sometimes nothing happens, other times you run into wet concrete, other times you get a ticket. They’re just plastic objects, easy to move, but you are not meant to cross them in your vehicle. While concrete bollards are a thing, they are only preferable in some situations.
I don't think this analogy fully respects the situation here. These pre/post condition are not just adding a warning to not do something, they also add a potentially bigger danger if they are broken. It's as if you also added a trap behind the construction cone which can do more damage than stepping on the wet concrete!
> documentation clearly states that it's UB to violate them
Only in "fast" mode. The developer has the choice:
> Compilation has two modes: “safe” and “fast”. Safe mode will insert checks for out-of-bounds access, null-pointer deref, shifting by negative numbers, division by zero, violation of contracts and asserts.
> The developer has the choice
The developer has the choice between fast or safe. They don't have a choice for checking pre/post conditions, or at least avoiding UB when they are broken, while getting the other benefits of the "fast" mode.
And all in all the biggest issue is that these can be misinterpreted as a safety feature, while they actually add more possibilities for UB!
Well, the C3 developer could add more fine grained control if people need it...
I don't really see what's your problem. It's not so much different than disabling asserts in production. Some people don't do that, because they rather crash than walking into invalid program state - and that's fine too. It largely depends on the project in question.
> It's not so much different than disabling asserts in production.
Disabling asserts would be equivalent to not having them at all, while this feature introduces _new_ UB. In "fast" mode it's equivalent to using C's `__builtin_assume` or Rust's `std::hint::assert_unchecked`, except it's marketed with a name that makes it appear a safety/correctness feature.
It seems to me like a way to standardize what happens all the time anyway. Compilers are always looking for ways to optimize, and that generally means making assumptions. Specifying those assumptions in the code, instead of in flags to the compiler, seems like a win.
I think they are there to help the compiler so the optimizer might (but doesn't have to) assume they are true. It's sometimes very useful to be able to do so. For example if you know that two numbers are always different or that some value is always less than x. In standard C it's impossible to do but major compilers have a way to express it as extensions. GCC for example has:
C3 makes it a language construct. If you want runtime checks for safety you can use assert. The compiler turns those into asserts in safe/debug mode because that help catching bugs in non performance critical builds.In the current C standard that's unreachable() from <stddef.h>
Thank you, I've just recently read the list of new features and missed this one!
The way I reason about it is that the contracts are more soft conditions that you expect to not really reach. If something always has to be true, even on not-safe mode, you use "actual" code inside the function/macro to check that condition and fail in the desired way.
>The way I reason about it is that the contracts are more soft conditions that you expect to not really reach
What's the difference from an assert then?
The difference from an assert is that for "require" they are compiled into the caller frame, so things like stack traces (which is available in safe mode) will point exactly to where the violation happened.
Because of inlining them at the call site happens, static analysis will already pick up some obvious violations.
Finally, these contracts may be used to compile time check otherwise untyped arguments to macros.
“However, violating either pre- or post-conditions is unspecified behaviour, and a compiler may optimize code as if they are always true – even if a potential bug may cause them to be violated”
This implies that a compiler would be permitted to remove precisely that actual code that checks the condition in non-safe mode.
Seems like a deliberately introduced footgun.
My understanding of this was that the UB starts only after the value is passed/returned. So if foo() has a contract to only return positive integers, the code within foo can check and ensure this, but if the calling code does it, the compiler might optimize it away.
Assuming that is correct, it's still exactly the same footgun. Checks like that are introduced to guard against bugs: you are strictly safer to not declare such a constraint.
Unspecified behavior != UB https://en.wikipedia.org/wiki/Unspecified_behavior
Design by contract is good. I've used it in some projects.
https://en.wikipedia.org/wiki/Design_by_contract
I first came across it when I was reading Bertrand Meyer's book, Object-oriented Software Construction.
https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...
From the start of the article:
[ Object-Oriented Software Construction, also called OOSC, is a book by Bertrand Meyer, widely considered a foundational text of object-oriented programming.[citation needed] The first edition was published in 1988; the second edition, extensively revised and expanded (more than 1300 pages), in 1997. Many translations are available including Dutch (first edition only), French (1+2), German (1), Italian (1), Japanese (1+2), Persian (1), Polish (2), Romanian (1), Russian (2), Serbian (2), and Spanish (2).[1] The book has been cited thousands of times. As of 15 December 2011, The Association for Computing Machinery's (ACM) Guide to Computing Literature counts 2,233 citations,[2] for the second edition alone in computer science journals and technical books; Google Scholar lists 7,305 citations. As of September 2006, the book is number 35 in the list of all-time most cited works (books, articles, etc.) in computer science literature, with 1,260 citations.[3] The book won a Jolt award in 1994.[4] The second edition is available online free.[5] ]
https://en.wikipedia.org/wiki/Bertrand_Meyer
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
So far so good. The feature set is bit random though. Things i personally miss is function overloading, default values in parameters and tuple returns.
> default values in parameters
C3 has you covered
https://c3-lang.org/language-fundamentals/functions/#functio...
It also has operator overloading and methods which you could use in place of function overloading I guess.
They named Result (or Expected) Optional? No, no, "optional" means "T or empty." Not "T or E."
https://c3-lang.org/language-fundamentals/functions/#functio...
I think there is an important difference here from both Option<T> and Result<T, E>: the C3 optional doesn’t allow an arbitrary error type, it’s just a C-style integer error code. I think that makes a lot of sense and fits perfectly with their “evolution, not revolution” philosophy. And the fact that the syntax is ‘type?’ rather than ‘Optional<type>’ also eases any confusion.
Sure, there is a restriction on the type of E. This is similar to Zig's result ADT, I think?
I share your distaste for arbitrarily renaming concepts. However, I think if you only have one of the two in the language, Optional is the clearer name.
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.
It's not just arbitrary renaming (Rust Result vs C++ Expected is fine) -- it's choosing a conflicting name for an extremely common abstract data type. If they wanted to call it "Elephant," great, but Optional is a well-known concept and Result/Expected isn't the same thing.
(I don't really object to the idea of skipping a real Optional<T> type in a language in favor of just Result<T, ()>.)
I would guess the two languages have little overlap in who they appeal to, and this is a bit closer to C semantics which is their north star. In C for functions that don’t return a value you often return a null for success or a return code that is a defined error code, which is exactly how Optional works in C3 (but you don’t write the word Optional in the function head). If you need to return a value in C you often pass an out param pointer and then still return either null or a defined error value. The improvement is you just write ‘type?’ for the return type to enable this and you don’t need an out param, but you still need the define (faultdef).
It's not about C semantics it's about the name of a commonly understood concept. What you just described there is the "result" pattern not the "optional" pattern. Of course the designers are free to call it whatever they want but swapping common terminology like that is a blunder from my perspective.
This is not exactly the same as the Result pattern. It doesn't require an ADT feature and does not require the programmer to specify a type for the possible error value.
Also syntactically it is quite different: it means you add exactly one character to the function head to denote that its possible to return an error.
So, calling that feature "Result" could also be confusing to people who have not yet learned this language.
Tell me, was it a blunder when Rust swapped "Result" from the commonly understood name of "Either" from OCaml/Haskell ?
> It doesn't require an ADT feature and does not require the programmer to specify a type for the possible error value.
I don't think that really matters? Result is "A or error" whereas optional is "A or nil".
Admittedly my wording was sloppy. It's technically a subset of the pattern when taken literally. But there's a very strong convention for the error type in C so at least personally I don't find the restriction off putting.
To me the issue is the name clash. This is most definitely not the "optional" pattern. I actually prefer C++'s "expected" over "result" as far as name clarity goes. "Maybe" would presumably also work.
At the end of the day it's all a non-issue thanks to the syntax. I might not agree with what you expressed but I also realize a name that only shows up in the docs isn't going to pose a problem in practice. Probably more than half the languages out there confuse or otherwise subtly screw up remainder, modulus, and a few closely related mathematical concepts but that doesn't get in the way of doing things.
From what I can see there you never write the word “Optional” in your code. This is just what they named the feature which stays close to C semantics without the burden of *out params.
Oof.
You can name it "Result" or (questionably) "Either."
Not "Option," "Optional," or "Maybe;" those are something else.
Tsoding did a bunch of livestreams using C3. Over 30h worth if anyone’s interested.
https://youtube.com/playlist?list=PLpM-Dvs8t0VYwdrsI_O-7wpo-...
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 differently or what itch they were scratching when choosing or refusing to implement certain features.
Which one for is most reasonable for embedded?
C3 was quite easy to get running. I have a minimal project to use C3 for ESP32-C3 chips here: https://github.com/abyesilyurt/c3-for-c3
> weren’t competing with each other but instead learn from each other
What is the difference? Using polite words to communicate?
Competing with each other would be trying to one-up each other feature-wise, whereas what I have witnessed was things like discussing trade-offs made in different languages and juggling around ideas on if some feature from language A would make sense in language B too.
You catch more flies with honey than with vinegar
why would I want to attract bugs? Vinegar keeps them away from me
It isn't even true.
https://xkcd.com/357/
"Head over heels" is another weird idiom. I'm so in love, I'm standing in a normal orientation.
"Head over heels" is actually a corruption of "heels over head".
It's one of those corruptions which flips the meaning (ironically, in this case!) on its head, or just becomes meaningless over time as it's reinterpreted (like "the exception that proves the rule" or "begs the question").
But then you are left with less honey.
Just browsed the doc to get the answers to two burning questions, which I will dump here in case it saves some time to others:
Apart from that it adds a few very desirable things, such as introspection and macros.IMHO the downsides of tagged unions (e.g. what Rust confusingly calls "enums") are big enough that they should only be used rarely if at all in a systems programming language since they're shoehoerning a dynamic type system concept back into an otherwise statically typed language.
A tagged union always needs 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?
tagged unions (not enums, sorry) are not a dynamic type system concept. Actually, I would not be able to name a single dynamically typed language that has them.
As for the memory allocation, I can't see why any object should have the size of the largest alternative. When I do the manual equivalent of a tagged union in C (ie. a struct with a tag followed by a union) I malloc only the required size, and a function receiving a pointer to this object has better not assume any size before looking at the tag. Oh you mean when the object is automatically allocated on the stack, or stored in an array? Yes then, sure. But that's going to be small change if it's on the stack and for the array, well there is no way around it ; if it does not suit your design then have only the tags on the array?
Tagged unions are a thing, whether the language helps or not. When I program in a language that has them then it's probably a sizeable fraction of all the types I define. I believe they are fundamental to programming, and I'd prefer the language to help with syntax and some basic sanity checks; Like, with a dynamical sizeof that to reads the tag so it's easier to malloc the right amount, or a syntax that makes it impossible to access the wrong field (ie. any lightweight pattern matching will do).
In other words, I couldn't really figure out the downside you had in mind :)
> Actually, I would not be able to name a single dynamically typed language that has them.
That's because every type in a dynamically typed language is a tagged union ;) For instance in Javascript you need to inspect a variable with 'typeof' to find out if it is a string, a boolean, a number or something else.
In a dynamically typed language, the runtime system needs to carry information around what type an item actually is, and this is the same thing as the type-tag in a tagged union - and Rust's match is the same sort of runtime type inspection as the typeof in JS, just with slightly different syntax sugar.
> As for the memory allocation, I can't see why any object should have the size of the largest alternative.
When you have a Rust enum like this:
...then every Bla object is always at least 16 bytes even when the active item is 'AByte' (assuming an empty String also fits into 16 bytes). Plain unions in C have the same problem of course, but those are rarely used (the one thing where unions are really useful in C (not C++!) is to have different views on the same memory).> When I program in a language that has them then it's probably a sizeable fraction of all the types I define
...IMHO 'almost always sum types' is a serious design smell, it might be ok in 'everything is a reference' languages like Typescript, but that's because you pay for the runtime overhead anyway, no matter if sum types are used or not.
I don't think we speak the same language. I was refering to the use case (in C) that's been described by sph. Where you indeed malloc only the relevant size, and you have to manually and carefully check the tag before casting the payload into the proper type. This is what I am tired of doing over and over and over again, and would like a system programing language to help with.
Tagged enums != any type (i.e. runtime casting)
Tagged enums are everywhere. I am writing a micro kernel in C and how I wish I had tagged enums instead of writing the same boilerplate of
> ...runtime casting...
...what else is a select on a tagged union than 'runtime casting' though. You have a single 'sum type' which you don't know what concrete type it actually is at runtime until you look at the tag and 'cast' to the concrete type associated with the tag. The fact that some languages have syntax sugar for the selection doesn't make the runtime overhead magically disappear.
Not sure why you call it runtime overhead. That’s core logic, nothing fancy, to have a pointer to a number of possible types. That’s what `void *` is, and sometimes you want a little logic to restrict the space of possibilities to a few different choices.
Not having syntactic sugar for this ultra-common use case doesn’t make it disappear. It just makes it more tedious.
There are many implementations and names, and what I refer to runtime casting/any type, which is unnecessary for low-level programming, is the one that uses types and reflection at runtime to be 100% sure you are casting to the correct type. Like Go’s pattern (syntax might be a bit off):
This is overkill for low-level programming and has much higher overhead (i.e. having to store type info in the binary, fat pointers, etc.) than tagged unions, which are the bread and butter of computing.There is https://github.com/c3lang/c3c/issues/829
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 can be automatic by default. All string ops return string, there are no special derivative types. Seq ops return seq, there are no special derivative types. Do you pay the price of the occasional copy? Yes. But there are opt-in trapdoors to allocate RC- or manually-managed strings and seqs. Otherwise, the default mode of interacting with heap data is an absolute breeze.
For the life of me, I don't know why other languages haven't leaned harder into such a transformative feature.
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.
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.
It's not just the size of the data but also the amount of copies. Consider a huge tree structure: even if each node is small, doing individual "malloc-style" allocations for millions of nodes would cause a huge performance hit.
Obviously for your use case it's not a problem but other use cases are a different story. Games in particular are very sensitive to performance spikes. Even a naive tracing GC would do better than hitting such an implicit copy every few frames.
I wonder, at which point it is worth it to make a language? I personally implemented generics, slices and error propagation in C… that takes some work, but doable. Obviously, C stdlib goes to the trash bin, but there is not much value in it anyway. Not much code, and very obsolete.
Meanwhile, a compiler is an enormously complicated story. I personally never ever want to write a compiler, cause I already had more fun than I ever wanted working with distributed systems. While idiomatic C was not the way forward, my choice was a C dialect and Go for higher-level things.
How can we estimate these things? Or let's have fun, yolo?
> Meanwhile, a compiler is an enormously complicated story.
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.
Yes, this is fine for basic exploration but, in the long run, I think LLVM taketh at least as much as it giveth. The proliferation of LLVM has created the perception that writing machine code is an extremely difficult endeavor that should not be pursued by mere mortals. In truth, you can get going writing x86_64 assembly in a day. With a few weeks of effort, it is possible to emit all of the basic x86_64 instructions. I have heard aarch64 is even easier but I only have experience with x86_64.
What you then realize is that it is possible to generate quality machine code much faster than LLVM and using far fewer resources. I believe both that LLVM has been holding back compiler evolution and that it is close to if not already at peak popularity. As LLMs improve, the need for tighter feedback loops will necessitate moving off the bloat of LLVM. Moreover, for all of the magic of LLVMs optimization passes, it does very little to prevent the user from writing incorrect code. I believe we will demand more from a compiler backend than LLVM can ever deliver.
The main selling point of LLVM is that you gain access to all of the targets, but this is for me a weak point in its favor. Firstly, one can write a quality self hosting compiler with O(20) instructions. Adding new backends should be trivial. Moreover, the more you are thinking about cross platform portability, the more you are worrying about hypothetical problems as well as the problems of people other than yourself. Get your compiler working well first on your machine and then worry about other machines.
I agree. I've found that, for the languages I'm interesting in compiling (strict functional languages), a custom backend is desirable simply because LLVM isn't well suited for various things you might like to do when compiling functional programming languages (particularly related to custom register conventions, split stacks, etc.).
I'm particularly fond of the organisation of the OCaml compiler: it doesn't really follow a classical separation of concerns, but emits good quality code. E.g. its instruction selection is just pattern matching expressed in the language, various liveness properties of the target instructions are expressed for the virtual IR (as they know which one-to-one instruction mapping they'll use later - as opposed to doing register allocation strictly after instruction selection), garbage collection checks are threaded in after-the-fact (calls to caml_call_gc), its register allocator is a simple variant of Chow et al's priority graph colouring (expressed rather tersely; ~223 lines, ignoring the related infrastructure for spilling, restoring, etc.)
--
As a huge aside, I believe the hobby compiler space could benefit from someone implementing a syntactic subset of LLVM, capable of compiling real programs. You'd get test suites for free and the option to switch to stock LLVM if desired. Projects like Hare are probably a good fit for such an idea: you could switch out the backend for stock LLVM if you want.
>Adding new backends should be trivial.
Sounds like famous last words :-P
And I don't really know about faster once you start to handle all the edge cases that invariably crop up.
Point in case: gcc
It's the classic pattern where you redefine the task as only 80% of the original.
That is why the Hare languages uses QBE instead: https://c9x.me/compile/
Sure it can't do all the optimizations LLVM can but it is radically simpler and easier to use.
Hare is a very pleasant language to use, and I like the way the code looks vs something like Zig. I also like that it uses QBE for the reasons they explained.
That said, I suspect it’ll never be more than a small niche if it doesn’t target Mac and Windows.
If only that was only about emitting byte code in a file then calling the linker... you also have the problem of debug information, optimizers passes, the amount of tests required to prove the output byte code is valid, etc.
>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.
Is there something analogous for those wanting to create language interpreters, not compilers? And preferably for interpreters one wants to develop in Python?
Doesn't have to literally just an afternoon, it could be even a few weeks, but something that will ease the task for PL newbies? The tasks of lexing and parsing, I mean.
https://craftinginterpreters.com/introduction.html
AST interpreter in Java from scratch, followed by the same language in a tight bytecode VM in C.
Great book; very good introduction to the subject.
There's quite neat lexer and parser generators for Python that can ease the barrier to entry. For example, I've used PLY now and then for very small things.
On the non-generated side, lexer creation is largely mechanical - even if you write it by hand. For example, if you vaguely understand the idea of expressing a disjunctive regular expression as a state machine (its DFA), you can plug that into skeleton algorithms and get a lexer out (for example, the algorithm shown in Reps' "“Maximal-Munch” Tokenization in Linear Time " paper). For parsing, taking a day or two to really understand Pratt parsing is incredibly valuable. Then, recursive descent is fairly intuitive to learn and implement, and Pratt parsing is a nice way to structure your parser for the more expressive parts of your language's grammar.
Nowadays, Python has a match (pattern matching) construct - even if its semantics are somewhat questionable (and potentially error-prone). Overall, though, I don't find Python too unenjoyable for compiler-related programming: dataclasses (and match) have really improved the situation.
I am a big fan of Ragel[1]. That is a high performance parser generator. In fact, it can generate different types of parsers, very powerful. Unfortunately, it takes a lot of skill to operate. I wrote a parser generator generator to make it all smooth[2], but after 8 years I still can't call it effortless. A colleague of mine once "broke the internet" with a Ragel bug. So, think twice. Still, for weekend activities I highly recommend it, just for the way of thinking it embodies.
[1]: https://www.colm.net/open-source/ragel/
[2]: https://github.com/gritzko/librdx/blob/master/rdx/JDR.lex
Is this the same Ragel that Zed Shaw wrote about in one of his posts back in the day, during Ruby and Rails heydays? I vaguely remwmber that article. I think he used it for Mongrel, his web server.
https://github.com/mongrel/mongrel
The worst part of designing a language is the parsing stage.
Simple enough to do it by hand, but there’s a lot of boilerplate and bureaucracy involved that is painfully time-wasting unless you know exactly what syntax you are going for.
But if you adopt a parser-generator such as Flex/Bison you’ll find yourself learning and debugging and obtuse language that has to be forcefully bent to your needs, and I hope your knowledge of parsing theory is up-to-scratch when you’re facing with shift-reduce conflicts or have to decide whether LR or LALR(1) or whatever is most appropriate to your syntax.
Not even PEG is gonna come to your rescue.
Thanks to those who replied.
> I wonder, at which point it is worth it to make a language?
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.
At the point you want to interface with people outside of your direct influence. That's the value of a language — a shared understanding.
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.
This actually started of by Christoffer (C3 author) contributing to C2 but not being satisfied with the development speed there, wanting to try his own things and moving forward more quickly. Apparently together with LLVM it was doable to write a new compiler for what is a successor to C2.
I've enjoyed using the C3 language to make some simple games [0] and found it really easy to pick up. The only thing that I got hung up on at first was the temporary memory arenas which I didn't know existed and ultimately really liked.
[0] https://github.com/Syn-Nine/c3-mini-games
I took a look at your github and saw you implemented the same games in multiple languages, which one did you like the most and why?
To be honest, my favorite language is my own language Tentacode [0], closely followed by my recent experimental language Gar [1]. Tenta is not publicly released yet, but the source can be downloaded on github [2]. I've been experimenting with making games in a bunch of languages to inform the design of Tenta by seeing how much I can strip away and still successfully, efficiently make a meaningful game.
[0] https://tentacode.org/docs/language/basic_types/
[1] https://github.com/Syn-Nine/gar-lang
[2] https://github.com/Syn-Nine/tentacode/tree/llvm
This is what a website for a programming language should look like.
I'd argue the opposite. My first thought once the page had loaded was that it looked childish and amateurish, the addition of a Discord chat link in the site navigation only reinforcing that perspective.
Nothing childish about putting the important stuff up front and a link to contact the people who made it.
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.
Reading through, something small caught me by surprise.
https://c3-lang.org/language-common/arrays/#fixed-size-multi...
Multi dimensional arrays are not declared in the same way they are accessed; the order of dimensions is reversed.
Accessing the multi-dimensional fixed array has inverted array index order to when the array was declared.
That is, the last element of 'int[3][10] x = {...}' is accessed with 'x[9][2]'.
This seems bizarre to me. What am I missing? Are there other languages that do this?
Please consider a variable `List{int}[3] x`, this is an array of 3 List{int} containing List{int}. If we do `x[1]` we will get an element of List{int}, from the middle element in the array. If we then further index this with [5], like `x[1][5]` we will get the 5th element of that list.
If we look at `int*`, the dereference will peel off the `*` resulting in `int`.
So, the way C3 types are declared is the most inside one is to the left, the outermost to the right. Indexing or dereferencing will peel off the rightmost part.
C uses a different way to do this, we place `*` and `[]` not on the type but on the variable, in the order it must be unpacked. So given `int (*foo) x[4]` we first dereference it (from inside) int[4], then index from the right.
If we wanted to extract a standalone type from this, we'd have `int(*)[4]` for a pointer to an array of 4 integers. For "left is innermost", the declaration would instead be `int[4]*`. If left-is-innermost we can easily describe a pointer to an array of int pointers (which happens in C3 since arrays don't implicitly decay) int*[4]*. In C that be "int*(*)[4]", which is generally regarded as less easy to read, not the least because you need to think of which of * or [] has priority.
That said, I do think that C has a really nice ordering to subscripts, but it was unfortunately not possible to retain it.
Thanks for pointing out what I was missing.
Please consider a variable `List{int}[3] x`, this is an array of 3 List{int} containing List{int}. If we do `x[1]` we will get an element of List{int}, from the middle element in the array. If we then further index this with [5], like `x[1][5]` we will get the 5th element of that list.
I get that motivation. In C++ it's an odd case that where `std::vector<int> x[4]` is "reversed" in a sense compared to `int x[4][100]`. And this quirk is shared with other languages (Java, C#).
But in my experience, mixing generic datatypes like this with arrays is quite rare, and multi-dimensional array like structures with these types is often specified via nesting (`std::vector<std::vector>>`) which avoids confusion.
The argument re. pointers is more convincing though.
File it with the footgun of the two different array slicing syntaxes: https://c3-lang.org/language-common/arrays/#slicing-arrays
I have already opened a discussion about this with the author, and I must say I agree to disagree that a language needs arr[start..end] (inclusive) as well as arr[start:len] (up to len-1) and if you use the wrong one, you’ve now lost a foot and your memory is corrupted.
The closed intervals for slices caught my eye as well, but I simply filed that under 'that's a weird quirk' rather than 'wtf?'.
It would require more thinking on my end to change that to either 'this is an acceptable choice' or 'this is a terrible idea'.
But the array indices being reversed on declaration? I cannot think of an upside to that at all.
I see from `test/test_suite/compile_time_introspection/paramsof.c3t` that there is a way to get names & types of function parameters [1]. The language also seems to support default values { e.g. `int foo(int a, int b = 2) {...}` } and even call with keyword arguments/named parameters [2], but I couldn't find any `defaultof` or similar thing in the code. Does anyone know if this is just an oversight / temporary omission?
[1] https://github.com/c3lang/c3c/blob/master/test/test_suite/co...
[2] https://c3-lang.org/language-fundamentals/functions/
I don't think it is available no, and it's the first time I heard about such an idea. Thinking on it, this would allow such cursed code (love that :D). I'll put it up for discussion in the Discord as I'm interested in hearing whether `.defaultof` is a good idea or not.
One application of such a feature would be something like a "cligen.c3" (like the Nim https://github.com/c-blake/cligen or its /python/cg.py port or etc.). Mostly it just seems a more complete signature extraction, though. Any other kind of documentation system might benefit.
Google is making a similar attempt with C++ called Carbon Language: https://github.com/carbon-language/carbon-lang
C3 is more targeting C instead of C++. I'm interested to see where both C3 and Carbon will be in a few years/decades.
Does anyone who has actually used C3, Odin, and Zig talk about how to think of these three?
Zig feels too much in flux, has some incredible ideas, but I really don't like it syntactically wise, and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors which I believe it's the worst thing to ever have been invented and drives me up the wall. Documentation was still pretty bad last I checked, and that's the bare minimum before I can seriously adopt a new language.
C3 feels like home for C developers, there is a real market for language evolutions rather than revolutions (imagine Typescript). The issue is that pretty much nobody knows about C3, most posts about it never get any traction on HN, and it's hard to choose a language with no mind share for anything more serious than toys.
Odin is quite nice, has some hype behind it, deservedly. Feels like a nice improvement over C without completely throwing the baby away with the bathwater; perhaps one negative thing might be that it's so opinionated it feels less of a general purpose language than others (with the main dev focused on graphics, there's a lot of syntax sugar for that use case which feels out of place for anyone that is not writing desktop UI or games). Also, while I agree with the author's choice on not rewriting the compiler itself in Odin, as most other languages do, it doesn't strike much confidence that the author would rather develop in C++ than eat his own dog food.
I must admit I don't keep up with alternative languages much any more because I believe the Lindy effect to be a force multiplier, and for serious applications it's better to stick with something that is known to work, despite its shortcomings. You only have a few points you can spend on innovation, and if you're developing a complex application, at the very least you want a rock-solid base to build upon. This is why I'm still sticking with C for very low-level programming.
Still, all three languages are worth your time.
> and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors
FWIW, they also have a goal to emit as much output as possible, even in the face of compilation errors. They have stated that even syntax errors should have the compiler exit with a non-zero exit code, but still produce an executable that will give you a syntax error at runtime. The point of this being to allow you to iterate quickly, but force things like CI to fail.
Why not just use compile warnings and configure CI with -WError (same like your release build).
It seems like trying to fix the world of undisciplined developers at the cost of a common use case (experimenting and temporary accepting warnings).
The Eclipse Java Compiler is similar to this, and Haskell can defer type errors to runtime. You wouldn't make production builds that way, but it's otherwise a perfectly valid mode for a compiler to operate in.
This looks like Zig. What problems does this solve that Zig doesn't? Potato - potaato?
C3 is more comparable to Odin or the Better C mode in D in that it tries to be a pragmatic evolution not revolution of C.
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.
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.
Zig doesn't have operator overloading. This does.
It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still.
I suppose it has less of the ability to blow your foot off and so isn't a very dangerous way to code, therefore not cool. If any of you younger folk haven't looked at it, I'd suggest having a look, there is Delphi - a cross platform dev environment that addresses all these problems and compiles in less than a second, or there's the free, open source alternative Lazarus. They also compile to mobile platforms and even the raspberry pi (Lazarus) or Arduino.
If you like contracts then ADA is the way to go, but I haven't used this for many years, so not sure what is the state of the compilers.
[1] https://www.embarcadero.com/products/delphi
[2] https://www.lazarus-ide.org
Both Pascal and C (and their offspring) are wonderful gifts for us to receive from their designers, and I enjoy writing code in both.
> It's funny seeing the problems with C Niklaus Wirth pointed out originally still trying to be solved. He solved them with pascal and its OO successors, though for some reason it's not cool still.
Here's Brian Kernighan's view on the shortcomings of Pascal resulting from a practical book project idea:
https://www.lysator.liu.se/c/bwk-on-pascal.html
Not sure to what extent the latest Oberon or Ada have addressed all of these, since I've not kept up with Ada news.
Isn't that interesting, I do vaguely recall this from many years ago. These complaints have mostly been addressed a long time ago, the solutions were mostly stolen from C where applicable, I refer to Delphi, but I think Lazarus is the same. These are the dot points from the summary:
- Since the size of an array is part of its type, it is not possible to write general-purpose routines, that is, to deal with arrays of different sizes. In particular, string handling is very difficult.
There's a TArray<T> type now, it uses generics and can be declared if you like, also lots of other structured types - lists, stacks etc, though the original array type is still available for backwards compatibility. There was also an array of without size to pass as a parameter but TArray is mostly used now.
- The lack of static variables, initialization and a way to communicate non-hierarchically combine to destroy the ``locality'' of a program - variables require much more scope than they ought to.
Statics are now a thing
- The one-pass nature of the language forces procedures and functions to be presented in an unnatural order; the enforced separation of various declarations scatters program components that logically belong together.
This can be an issue still, though the one pass is why the compiler is fast.
- The lack of separate compilation impedes the development of large programs and makes the use of libraries impossible.
Not an issue any more, it has packages and libraries
- The order of logical expression evaluation cannot be controlled, which leads to convoluted code and extraneous variables.
Not an issue any more it uses the C method
- The 'case' statement is emasculated because there is no default clause.
Does now, though a case with string alternatives still doesn't exist in Delphi, Lazarus has it.
- The standard I/O is defective. There is no sensible provision for dealing with files or program arguments as part of the standard language, and no extension mechanism.
Many different sorts of file access - random, binary etc
- The language lacks most of the tools needed for assembling large programs, most notably file inclusion.
Not true any more, it has packages and include files (though limited), and the macro facility is very limited, nothing like C's but its not really needed, you can have inline functions for the performance boost macros would give you (stolen from C++)
- There is no escape.
This refers to the type system, you can use casts just like C now
Just as a counterpoint C still doesn't have a standard string type. Delphi has generics now like C++, and many of the things that are external libraries in C/C++ are just included. If you really need high performance then C is still better, but what I've done in the past is just rewrite bits in C, though the need for this is very infrequent. If you look at comparable things for Delphi in C++ like Qt's slots and signals for example, the Delphi solution is so much more elegant, and Qt is perhaps the only comparable commercial cross platform library to Delphi's Firemonkey. It's really worth a look, times have changed. There's a reason MS hired away Anders Hejlsberg to architect C# and then typescript.
I would argue that Go is the closest spiritual descendant of Wirth's languages. If you changed braces into BEGIN/END and so on, it would look a ton like Oberon or Modula 2/3.
It adds features (goroutines, channels, slices), changes some (modules become packages), the generics are a little different, and it eschews some of Wirth's pragmatic type safety ideas (like range types). It even has ":=" for assignment.
The general spirt is the same, I think: Small language, simple compiler (compared to many other languages), "dumb" type system, GC, engineering-focused rather than-type theory-focused.
The part of Delphi that is interesting, and isn't really mentioned much for some reason, is the component library - VCL (windows only) and Firemonkey (Cross platform). Like the language does what's needed, garbage collection would be nice, and is on iOS, but the really nice part is the ability to make things by dragging and dropping visual and non visual components, and making your own components in the same language.
" the C-like for programmers who like C."
Sounds intriguing. But then, the first thing I noticed in their example is a double-colon scope operator.
I understand that it's part of the culture (and Rust, C#, and many other languages), but I find the syntax itself ugly.
I dunno. Maybe I have the visual equivalent of misophonia, in addition to the auditory version, but :: and x << y << z << whatever and things like that just grate.
I like C. But I abhor C++ with a passion, partly because of what, to me, is jarring syntax. A lot of languages have subsequently adopted this sort of syntax, but it really didn't have that much thought put into it at the beginning, other than that Stroustrup went out of his way to use different symbols for different kinds of hierarchies, because some people were confused.
Source: https://medium.com/@alexander.michaud/the-double-colon-opera...
Think about that. The designer of a language that is practically focused on polymorphism went out of his way to _not_ overload the '.' operator for two things that are about as close semantically as things ever get (hierarchical relationships), simply because some of his customers found that overloading to be confusing. (And yet, '<<' is used for completely disparate things in the same language, but, of course, apparently, that is not at all confusing.)
I saw in another comment here just now that one of the differentiators between zig and C3 is that C3 allows operator overloading.
Honestly, that's in C3's favor (in my book), so why don't they start by overloading '.' and get rid of '::' ?
Two reasons, the second being the important: (1) If I read "io.print", is this "the print function in the module io" or "the print method for the variable io". There tends to be an overlap in naming here so that's a downside (2) parsing and semantic checking is much easier if the namespace is clear from the grammar.
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.
I have never found either (1) or (2) to be a problem in hundreds of thousands of lines of Python.
> In particular, C3's "path shortening" ... we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system.
You can easily and explicitly shorten paths in other languages. For example, in Python "from mypackage.mysubpackage import mymodule; mymodule.myfunc()"
Python even gracefully handles name collisions by allowing you to change the name of the local alias, e.g. "from my_other_package.mysubpackage import mymodule as other_module"
I find the "from .. import" to be really handy to understand touchpoints for other modules, and it is not very verbose, because you can have a comma-separated list of things that you are aliasing into the current namespace.
(You can also use "from some_module import *" to bring everything in, which is highly useful for exploratory programming but is an anti-pattern for production software.)
Of course you can explicitly shorten paths. I was talking about C3's path shortening which is doing this for you. This means you do not need to alias imports, which is otherwise how languages do it.
I don't want to get too far into details, but it's understandable that people misunderstand it if they haven't used it, as it's a novel approach not used by any other language.
Oh, I understand it. I just think that (a) explicit is better than implicit; and (b) the amount of characters that Python requires to keep imports explicit is truly minimal, and is a huge aid to figuring out where things came from.
> (1) If I read "io.print", is this "the print function in the module io" or "the print method for the variable io"
I don't see the issue. Just look up the id ? Moreover, if modules are seen as objects, the meaning is quite the same.
> checking is much easier if the namespace is clear from the grammar.
Again (this time by the checker) just look up the symbol table ?
Let's say you have find foo::bar(), then we know that the path is <some path>::foo, the function is `bar` consequently we search for all modules matching the substring ::foo, and depending on whether (1) we get multiple matches (2) we only get a match that is not properly visible (3) we get a match that isn't imported, (4) we get no match or (5) we get a visible match, we print different things. In the case 1-4, we give good errors to allow the user to take the proper action.
If instead we had foo.bar(), we cannot know if this is the method "bar" on local or global foo, or a function "bar()" in a path matching the substring "foo". Consequently we cannot properly issue 4, since we don't know what the intent was.
So far, not so bad. Let's say it's instead foo::baz::bar(). In the :: case, we don't have any change in complexity, we simply match ::foo::baz instead.
However, for foo.baz.bar(), we get more cases, and let us also bring in the possibility of a function pointer being invoked: 1. It is invoking the method bar() on the global baz is a module that ends with "foo" 2. It is calling a function pointer stored in member bar on the global variable baz is a module that ends with "foo" 3. It is calling the function bar() in a module that ends with "foo.baz" 4. It is calling the function pointer stored in the global bar in a module that ends with "foo.baz" 5. It is invoking the method bar on the member baz of the local foo 6. It is calling a function pointer stored in the member bar in the member baz of the local foo
This might seem doable, but note that for every module we have that has a struct, we need to speculatively dive into it to see if it might give a match. And then give a good error message to the user if everything fails.
Note here that if we had yet another level, `foo.bar.baz.abc()` then the number of combinations to search increases yet again.
I think you are overcomplicating this.
This is exactly the syntax Python uses, and there is no "search" per se.
Either an identifier is in the current namespace or not.
And if it is in the current namespace, there can only be one.
The only time multiple namespaces are searched is when you are scoped within a function or class which might have a local variable or member of the same name.
> find foo::bar(), then we know that the path is <some path>::foo, the function is `bar` consequently we search for all modules matching the substring ::foo,
The only reason you need to have a search and think about all the possibilities is that you are deliberately allowing implicit lookups. Again, in Python:
1) Everything is explicit; but 2) you can easily create shorthand aliases when you want.
> note that for every module we have that has a struct, we need to speculatively dive into it to see if it might give a match. And then give a good error message to the user if everything fails.
Only if you rely on search, as opposed to, you know, if you 'import foo' then 'foo' refers to what you imported.
As a long time lisper I can't stand how much syntax languages have and I think of excess syntax as a sign of a childish mind, but what can you do?
It's horses for courses, right? Pick the right language for the job. LISP was designed for 60's era GOFAI, designed for that with code not differentiated from data, but a COBOL or FORTRAN even BASIC programmer would presumably (and justifiably from the perspective of those typical use cases) regard LISP as the toy/unserious language.
As I get older, I realize that everybody's sweet spot is a little different.
Lisp and APL both have their adherents.
I personally find a bit more syntax than lisp to be nice. Occasionally I long for the homoiconicity of lisp; otoh, many of the arguments for it fall flat with me. For example, DSLs -- yeah, no, it's hard enough to get semi-technical people to use DSLs to start with, never mind lisp-like ones.
It definitely is possible, because languages like Vlang (for example), are able to use '.' instead of '::'. Always saw this as language creator preference, versus any inescapable technical reason.
Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy.
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.
> Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy.
That's a perspective. Are we talking about the 'bar' that comes from 'foo' or are we talking about the 'bar' that comes from 'baz'?
But another perspective is that 'foo' is important and provides several facilities that are intimately related to foo, so 'bar' is simply one of the features of foo.
> It also helps code readability to know that a::b is referring to a namespace
For you, perhaps. As someone who reads a lot of Python, I don't personally find this argument persuasive.
Right - I just wanted to point out that not everyone is going to conceptualize namespaces and members, the same as structs and members, as both being about "hierarchy".
I'm generally of the camp that code is written once, read many times, and that anything that adds to readability is therefore a win.
> anything that adds to readability is therefore a win.
Right, the entire question is whether '::' ever adds to readability.
For me, it's a huge negative.
Obviously, YMMV.
I like the idea of strict improvements to C without taking anything away or making any controversial (as far as language design goes) choices.
One thing I am wondering is why new low level languages remove goto (Zig, C3, Nim). I think it's sometimes the cleanest, most readable and most maintainable solution. I get that's rare but especially when you are expressing low level algorithm operating on arrays/blocks/bit streams it can be useful. It's not that you can't express it with "structured" constructs but sometimes it's just not the best way. I get removing backwards goto when you provide alternative constructs for state machines but forward one is useful in other contexts.
Is it a purely ideological choice or does it make the compiler simpler/faster?
In C3 it's complicated. On one hand the lack of goto means defers are more straightforward, but the biggest problem is that once you have a different way to handle cleanup and you have labelled break/continue, and you have the nextcase to jump to arbitrary cases, there's very little left for goto to do.
It is limited to when you want to jump from within an if statement out across some statements and run the remaining code. It saves one level of indentation, but being so rare, it's hard to justify the complexity.
I keep going back and see if I find some usecase that could motivate putting goto back in but it so far nothing. The "nextcase" allows C3 to express arbitrary jumps back and forth, although not as straightforward as goto.
Looking at my own code one case I wouldn't get with defer and better switch is avoiding a flag pattern.
For example when you iterate over a block and check if positions are 0 (+ do some work) and once you encounter a non zero you jump to a different "non-empty" section but if it's zeros to the end you jump over non-empty to go to end section. Without goto you need to set a flag and add another conditional there.
Other than that what you mentioned: flatting the if structure is nice. When you have a few simple cases and then a complicated one and a finishing session at the end it's just cleaner and easier to read with goto. It could be handled with a switch statement but not everything is "switchable" and the way most people write it it's another 2 indentation levels (1 with a convention of not indenting cases but I see C3 docs avoid it).
I get it's rare but goto (other than error handling) is rare and I don't think people have a tendency to abuse it. If anything people abuse "structured" construct building an arrow pattern with multiple indentation levels for no good reason.
That's the kind of thing I was thinking about. You can solve that with a switch in C3, but it's not as nice. However, this accounts for no more than 1% of all my goto uses (from a quick inspection), which is too little to build a feature from (discipline is needed to prevent a language from ballooning, it's hard to say no). I am looking for some use for it that can redeem its inclusion.
I agree it's very rare. I have this goto. A few that go to common return block that can be handled by other means and the rest is either error handling or things handled by labelled break or switch.
I mean we know you can program without it and defer/labelled switch and labelled break/continue cover 99%+ of use cases of it. I am still not convinced those are in fact easier to read but I get it's a reasonable design choice to make.
They have different wins. I think labelled break/continue help because they are clearer in locally expressing what the point is. If you see `goto NEXT;` you can kind of guess the intention, but `continue OUTER;` doesn't require you to read the code at the label and check what's happening there. `defer catch` and `defer try` helps avoiding some booleans otherwise needed with just a basic defer. `defer` on its own otherwise sometimes needs booleans to track what should be closed. With goto those naturally go to different cleanup sections.
I keep revisiting goto though. I like it a lot for its simplicity.
Previous discussions:
July 2025 (159 comments, 143 points): https://news.ycombinator.com/item?id=44532527
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
> Why do we still have to recompile the whole program everytime we make a change
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).
To a large extent, this problem is primarily due to slow compilation. It is possible to write a direct to machine code compiler that compiles at greater than one million lines per second. That is more code than I am likely to write in my lifetime. A fast compiler with no need for incremental compilation is a superior default and can always be adapted to add incrementalism when truly needed.
C3 doesn't have a recompile everything model, in fact it's pretty much designed around supporting separate compilation and dynamic linking (unlike Zig and Odin), it even supports Objective-C style dynamic calls.
Separate compilation is one solution to the problem of slow compilation.
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.)
Ha, I did not see your post before making mine. You are correct in your assessment of the blame.
Moreover, I view optimization as an anti-pattern in general, especially for a low level language. It is better to directly write the optimal solution and not be dependent on the compiler. If there is a real hotspot that you have identified through profiling and you don't know how to optimize it, then you can run the hotspot through an optimizing compiler and copy what it does.
> Why do we still have to recompile the whole program everytime we make a change
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?
> 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
Lisp solved that problem 60 years ago.
A meta answer to your question, I guess.
It seems great to have something that is C but cleaned up, although clay had all that with templates and move semantics.
I think leaving out move semantics and destructors is inexcusable at this point. It is not only fundamental, but doesn't affect things like standard libraries, runtimes, or ABIs.
But it of course move semantics and destructors affect all things. If the goal is to call and be callable from C without special constructs, how would you make the C code respect the move semantics and destructors?
C++ is already callable from C, you can make functions have any call signature that you want. What is the actual problem?
Was an interesting ready but sad to see that there is nothing special for matching or restructuring tagged unions (beyond the special cased optional type). That's one of the things from Rust I miss the most in my day to day work with C/C++.
Still looking for a good design: https://github.com/c3lang/c3c/issues/829
Did you manage to get more discussion on the Discord?
I don't recall exactly, I think we rehashed the same points.
Why have features but then the compiler doesn’t make programs that enforce it…
I’m seeing a lot of this in the docs:
“However, just like for const the compiler might not detect whether the annotation is correct or not! This program might compile, but will behave strangely:”
This seems pretty neat! Still holding out for a language with Go's runtime and compilation and performance characteristics, but language syntax and semantics like Gleam... Maybe one day
Unfortunately the current trend among new languages seems to be eschewing GC; a clear mistake IMO — we don't really need yet another low-level systems programming language, but we badly need the go-to GC'd lang — one that'd take the faults of Java and Go into account.
There is lots of languages that already do that: Kotlin, Dart, typescript, OCaml, D, Haskell and the list goes on! Non GC languages OTOH are rare and we absolutely need more of them!
It is called OCaml. Fast compilation and state of the art statically typed functional programming.
Sure it is a bit more complex than Gleam and the syntax is different but you can manage.
I like OCaml in theory a lot! This is not a bad suggestion. The problem is it doesn't have the awesome concurrency model of Go (just barely got regular threads recently), and IMHO the build and package management situation for OCaml isn't very good. Plus, I don't know, I just subjectively don't like using it, and the ecosystem isn't very good. Ecosystem is very important for me.
Borgo could be your thing? https://borgo-lang.github.io
It looked really good! But seems kinda dead, and I don't know the Go ecosystem well enough to know if dead things can sort of keep working forever
There is also Dingo https://github.com/MadAppGang/dingo https://dingolang.com (heavy AI project)
Xgo
That would be C# ?
I understood the sibling comment recommending Ocaml and to a lesser extent Borgo, but OP is looking for a high level functional programming language based on giving Gleam as the reference point. How does C# fit here.
I do think the compilation speed and runtime is at least in the same ballpark, but C#, while a perfectly fine language, is definitely not a functional language in syntax or semantics.
They probably meant F#
[dead]
Interesting! If today I wanted to start a project in a C-like language, I'd have chosen Zig. Would you tell a rough overview of how C3 differs from something like Zig?
Looks interesting, but operator overloading is an anti-pattern. Leading with that is like leading with "full support for null pointers."
The front page reads like a D language checklist :-)
Check it out on the comparisons page: https://c3-lang.org/faq/compare-languages/#d
I think they're aware of and like D :)
It was very nice of the C3 crowd to write that comparison. Thanks for pointing it out to me!
I agree that D has gotten a bit complex. We're introducing the notion of "editions" in order dispose of obsolete and unnecessary features.
What old features would you like to dispose of in a modern redesign of D? What would this new edition look like?
I am not a C programmer but I always find these low level languages intriguing.
I am wondering though: when does one pick C3 for a task/problem?
C3 is pretty much aimed at those who would use C for a task but prefer something a bit more modern. I find it more fun to program in compared to plain C, and it's definitely more simple than reaching for C++.
I see 'fn void main()'. There's probably a good reasson but why the 'fn'? It doesn't really add anything because 'void main()' already communicates it's a function.
The main draw of C (to me) is it's terseness and it's avoidance of 'filler' syntax words.
I admit I didn't (yet) look much further into it, but this first thing jumped out to me and slightly diminished my desire to look further into C3...
It's to remove a syntax ambiguity with c-style function declarations https://en.wikipedia.org/wiki/Most_vexing_parse
The syntax ambiguity adds a lot of complexity to the grammar that makes parsing a lot more complicated than it needs to be.
Sticking `fn` in front fixes a lot of problems.
https://c3.handmade.network/blog/p/8886-why_does_c3_use_%252...
My university had us program in c++ with resolve. Which looks very similar to the contract stuff here.
Anyone use zig vs C3? Seems like a lot of overlap, curious about people’s experiences with both
Maybe these two could be interesting?
https://lowbytefox.dev/blog/from-zig-to-c3/
https://alloc.dev/2025/05/29/learning_c3
I think the switch statement design is a foot gun: defaults to fall-through when empty and break when there is a body.
https://c3-lang.org/language-overview/examples/#enum-and-swi...
This feels very natural though, in a "principle of least surprise" kinda way. This is what you'd expect a properly designed switch statement to do.
Least surprise to who? Are there any other mainstream languages that behave this way?
I think consistency is the best correlate of least surprise, so having case statements that sometimes fall though, sometimes not, seems awful.
Swift
Sadly many of us are so used to the C fall-through behavior that this would be quite a surprise.
Personally, I'd rather see a different syntax switch (perhaps something like the Java pattern switch) or no switch at all than one that looks the same as in all C-style languages but works just slightly differently.
It reads naturally but I can see people getting tripped up writing this. Worse for changing existing code. Refactor in a way that removes a body? Likely forget to add a breake
If I aimed and shot a gun at my foot and a bullet didn’t go through it, I would trash the gun.
To be fair, I would probably toss the gun away if a bullet went through my foot.
Er, Forth guy as a, would foot trash I the and bullet gun the. Word!
I agree it's not the best choice. I mean it's true that you almost always want fall-through when the body is empty and break where it isn't but maybe it would be better to at least require explicit break (or fall-through keyword) and just make it a compiler error if one is missing and the body is not empty. That would be the least surprising design imo.
I keep thinking about perhaps LLMs would make writing code in these lower-level-but-far-better-performing languages in vogue. 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?
> that machine is far more skilled at generating quality Rust than I currently am. But I am using this as an opportunity to learn.
I'm currently doing this with golang. It is not that bad of an experience. LLMs do struggle with concurrency, though. My current project has proved to be pretty challenging for LLMs to chew through.
Having worked with rust in the past couple years, I can say that it hands down much better fit for LLMs than Python thanks to its explicitness and type information. This provides a lot of context for LLM to incrementally grow the codebase. You still have to watch it, of course. But the experience is very pleasant.
Because there’s more python on the internet to interpolate from. LLMs are not equally good at all languages
You can throw Claude at a completely private Rust code base with very specific niche requirements and conventions that are not otherwise common in Rust and it will demonstrate a remarkably strong ability to explain it and program according to the local idioms. I think your statement is based on liking a popular language, not on evidence..
I find that having a code-base properly scaffolded really, really helps a model handle implementing new features or performing bug-fixes. There's this grey area between greenfield and established that I hit every time I try to take a new project to a more stable state. I'm still trying to sort out how to get through that grey area.
I had Claude nearly one-shot (well, sequence-of-oneshots) a fairly complex multi-language file pretty-printer, but only after giving it a very specific 150-line TODO file with examples of correct results, so I think pure greenfield is very achievable if you steer it well enough. I did have to really focus on writing the tasks to be such that there wasn't much room for going off the rails, thought about their ordering, etc; it was pretty far from vibecoding, produced a strict data-driven test suite, etc.
But ultimately, I agree with you, in most projects, having enough existing style, arranged in a fairly specific way, for Claude to imitate makes results a lot better. Or at least, until you get to that "good-looking codebase", you have to steer it a lot more explicitly, to the level of telling it what function signatures to use, what files to edit, etc.
Currently on another project, I've had Claude make ~10 development spikes on specific ~5 high-uncertainty features on separate branches, without ever telling it what the main project structure really is. Some of the spikes implement the same functionality with e.g. different libraries, as I'm exploring my options (ML inference as a library is still a shitshow). I think that approach has some whiff of "future of programming" to it. Previously I would have spent more effort studying the frameworks up front and committed to a choice harder, now it's "let's see if this is good enough".
That’s been my experience. LLMs excel at languages that are popular. JavaScript and Python are two great examples.
I think the same. It sounds quite more practical to have LLMs code in languages whose compilers provide as much compile-time guardrails as possible (Rust, Haskell?). Ironically in some ways this applies to humans writing code as well, but there you run into the (IMO very small) problem of having to write a bit more code than with more dynamic languages.
It seems cynically fitting that the future we're getting and deserve is one where we've automated the creation of memory bugs with AI.
You still want to be able to easily review the LLM generated code. At least I want to.
Windows is a horse that is becoming less and less rideable. Be great to get this to build on ReactOS as just a hobby or side effort.
Its successor will be C4!
Does c3 use llvm?
Delete "fn" and I might get onboard
The price of not requiring fn is mandatory forward declarations, header files, and a slower parser (because then the syntax requires knowing whether every symbol is a type or a function/variable to be parsed correctly)
I think that trade-off is absolutely not worth it. I'll take order-independent declarations and fast modules over strictly sticking to C syntax any day.
It has many usability benefits: https://c3.handmade.network/blog/p/8886-why_does_c3_use_%252...
not being able to do alias i32 = int; was the biggest turn off for me
c3 is as easy as 1,2,3
[dead]
[flagged]
Does this compile to Rust with an LLVM?
No, C3 does not compile to Rust or use Rust in its compilation process.
Honestly if your programming language does not compile to wasm I don't care for it. That's my new rule.
> We do want WASM to be working really well, so if you’re interested in writing something in WASM please reach out to the C3 development team and we’ll help you get things working.
It does compile to WASM.
If I had a dollar for every C successor...