Show HN: C3 – A C alternative that looks like C

https://news.ycombinator.com/item?id=32005678

by lerno • 4 years ago

182 136 4 years ago

news.ycombinator.com

Compiler link: https://github.com/c3lang/c3c

This is my follow-up "Show HN" from roughly a year ago (https://news.ycombinator.com/item?id=27876570). Since then the language design has evolved and the compiler has gotten much more solid.

Assorted extra info:

- The C3 name is a homage to the C2 language project (http://c2lang.org) which it was originally inspired by.

- Although C3 mostly conforms to C syntax, the most obvious change is requiring `fn` in front of the functions. This is to simplify searching for definitions in editors.

- There is a comparison with some other languages here: http://www.c3-lang.org/compare/

- The parts in C3 which breaks C semantics or syntax: http://www.c3-lang.org/changesfromc/

- Aside from the very C-like syntax, one the biggest difference between C3 and other "C competitors" is that C3 prioritizes C ABI compatibility, so that all C3 special types (such as slices and optionals) can be used from C without any effort. C and C3 can coexist nicely in a code base.

- Currently the standard library is not even alpha quality, it's actively being built, but there is a `libc` module which allows accessing all of libc. Raylib is available to use from C3 with MacOS and Windows, see: https://github.com/c3lang/vendor

- There is a blog with assorted articles I've written during the development: https://c3.handmade.network/blog

addaon5• 4 years ago

Looking at the primer...

    // C
    typedef struct
    {
      int a;
      struct 
      {
        double x;
      } bar;
    } Foo;

    // C3
    struct Foo
    {
      int a;
      struct bar 
      {
        double x;
      }
    }

Very confused by this. The C code declares an anonymous struct type, then aliases the typename "Foo" to that anonymous struct type. The C3 code seems to declares a named struct type "Foo" -- why isn't the C equivalent here just "struct Foo"?

But then within the struct it gets weirder... the C code declares a second anonymous struct, and then declares a member variable of that type. The C3 code... declares a struct named "bar" and also a member variable with name matching the type? Except the primer says that these are equivalent, so the C3 code is declaring an anonymous struct and a member of that type? Using the same syntax as the outer declaration did to declare a named type but no (global) variable?? Is this case sensitive?

I don't think I can get further into the primer than this... even taking the author at their word that the two snippets are equivalent, I don't understand what's in play (case sensitivity? declarations where variable name must match type name?) to make this sane, and there's zero rationale given for these decisions.

addaon5• 4 years ago

Oh gosh... digging further on the same page under "Identifiers" it looks like case sensitivity is the key here. So "struct Foo" declares a type "Foo", and "struct foo" declares a variable "foo" of new anonymous type. I assume "struct Foo foo" and "struct bar Bar" do exactly what you (don't) expect, and maybe even "struct foo bar baz {}" to be the equivalent of the C code "struct {} foo, bar, baz"... yikes.

Edit: "Declaring more than one variable at a time is not allowed." So there's no equivalent to the C code ""struct {} foo, bar, baz"... not clear if "struct IDontNeedANameButTheLanguageIsForcingMe foo {}; IDontNeedANameButTheLanguageIsForcingMe bar; IDontNeedANameButTheLanguageIsForcingMe baz;" is legal (modulo that some of those semicolons are illegal I think?).

Yeah, this needs some rigor in the docs.

Cloudef7• 4 years ago

This doesn't seem very well thought out at all

lerno19• 4 years ago

No, you misunderstand. There is no `struct Foo foo`. Unlike C `struct Foo` would only ever be valid at the top level. Neither `struct Foo foo` nor `struct bar Bar` works.

The reason why `Bar` is a type and `bar` is a variable or function is to resolve the ambiguity of C syntax without having to rely on unlimited lookahead or the lexer hack. Basically it allows tools to parse the code much more easily than they would C.

You can declare multiple fields in a struct, e.g. `struct Foo { int x, y; }`, but you can't write `int x, y = 123;` like in C. This is because it would create ambiguities in the extended for/while/if syntax C3 adds.

lerno19• 4 years ago

The first part about the name is just like C++: you use the name without `struct` unlike C where structs has its own namespace. That's what it's meant to illustrate.

The second question is more subtle. In C, the syntax is `struct { ... } [optional member name] ;`. Because there is no anonymous struct at the top level, the anonymous structs inside of a struct has a different syntax, also eschewing the final `;`, changing the syntax to `struct [optional member name] { ... }`. If the C syntax structure is desired a final `;` would be required. This syntax change comes from C2.

addaon5• 4 years ago

But what if I want to name the inner struct so I can refer to Outer::Inner (for example, for use with sizeof or similar, or to create a temporary to hold a copy of that type) later? Do I need to use typeof(Outer::inner)? And then of course multiple members of the same type...

addaon5• 4 years ago

Also, just to be clear, the removal of semicolons deliberately makes the language whitespace sensitive, right? That is,

    struct Foo {
    } foo

declares a variable of a new empty struct type, but

    struct Foo {}
    foo

is a syntax error?

brabel• 4 years ago

why isn't the C equivalent here just "struct Foo"?

That would not be the equivalent... you would then need to declare the type of Foo variables as:

    struct Foo myVar;

With the typedef, and I assume with C3, you would do the more acceptable:

    Foo myVar;

addaon5• 4 years ago

From the primer, C3 follows the C++ rules here, not C rules. Changing to using C++ struct/enum/union naming rules here is a much less invasive change than what I'm discussing.

_gabe_3• 4 years ago

Very confused by this. The C code declares an anonymous struct type, then aliases the typename "Foo" to that anonymous struct type. The C3 code seems to declares a named struct type "Foo" -- why isn't the C equivalent here just "struct Foo"?

I'm curious how familiar you are with C? In C++ you can do:

  struct Foo {
    // ...
  };
  Foo myVar;

But that's not how it works in C. In C this would be:

  struct Foo {
    // ...
  };
  struct Foo myVar;

Which is why many C developers typedef the struct so that they don't have to prefix struct types with the keyword.

I don't think I can get further into the primer than this... even taking the author at their word that the two snippets are equivalent

Maybe don't judge the author on these things if you're not familiar with how C would work in this case? There's nothing wrong with not understanding a piece of code, but it's generally not a good idea to assume you have understanding of a language like C if you understand C++. People often conflate the two, but there are many quirks of C that C++ doesn't necessarily need to do and vice versa.

Cloudef7• 4 years ago

I hate when c++ does this. I don't want automatic typedefs, keep the struct so I know what it is. Also causes annoying name conflicts ...

SV_BubbleTime• 4 years ago

Which is why many C developers typedef the struct so that they don't have to prefix struct types with the keyword.

Oh, hello. Yes, guilty.

adamius4• 4 years ago

Wrapping structs in typedefs like this should be a distant and quaint memory by now. C'mon guys its 2022. Why hasn't some standard gotten rid of this requirement for typedefs around structs?

Deprecate this requirement already and make it an option. Gcc --stupid-typedef-required

Edit: or stated in another way, please describe the good reason(s) for having typedef struct {} Foo in C. Do it in terms of justifying the extra typing / extra steps. I'd really like to know. This is extra code and one more thing to test and confirm. Don't reference history or "its just how its always been done" - that to me is an admisson that it needs to go into an option. Also you'll need to explain why its bad that C++ doesn't require this. I'd also like to see as part of this rebuttal a formal statement that C++ got it completely wrong.

So: Why in C do we require the extra steps just so we can get rid of the struct keyword having to be plastered everywhere?

Personally I think the typedef struct pattern is kept purely for historical reasons and is no longer necessary. It obscures the code rather than clarifies it. There are much better reasons for using typedef but getting rid of "struct" prefixes everywhere isn’t one of them.

keikobadthebad3• 4 years ago

requiring `fn` in front of the functions. This is to simplify searching for definitions in editors.

You don't have to do that even in C, you can use this style for function defs

  static int
  myfunc(...)
  {
  ...
  }

and search or grep for

  ^myfunc\(

to isolate the definition as opposed to the use.

IshKebab2• 4 years ago

Or just use an IDE. It's 2022 people! We don't have to code like it's 1985.

Cloudef7• 4 years ago

I still haven't used a IDE that has made my developer experience better than simple text editor and some cli tools. They all seem to fail spectacularly if you have to do something bit more different than they were designed for (usually regarding how the project is built), and often feel very sluggish. Also the project files or build files they generate are usually horrible, and not great for version control.

lerno19• 4 years ago

Interestingly removing `fn` was something I've considered more than once, but I had people ask me to keep it. Even though you can get searchability in C by adhering to certain conventions, that's not the same as being able to search ANY code base in a simple manner, which I believe is what people wanted.

keikobadthebad3• 4 years ago

I doubt many C programmers were waiting for someone to force a function naming style on them after 50 years.

gnulinux3• 4 years ago

Yeah but that's a very quirky style; I don't want to change the structure of my code just to make it searchable!

keikobadthebad3• 4 years ago

Sticking fn in front of every def isn't quirkier?

Some parts of the kernel use this style.

It's also advantageous because it enables long return types and long function names neatly at the same time.

ChickeNES• 4 years ago

I was confused by this, thought they added `fn` to simplify the parser which to my understanding is why many languages moved away from C style function declarations. I'd rather they move the return type to the end like in Rust and Go for example

lerno19• 4 years ago

It simplifies the parser somewhat, but C3 restricts the grammar somewhat from C, so it's possible to unambiguously parse it. However, for people writing tools using `fn` is much easier to parse for. Say you want to write a program that dumps all function names in a file. With `fn` that's a simple regex. Without it you have to do more work.

oconnor663• 4 years ago

Simplifying the parser is cool, but what matters most to me is that I can grep/rg for function definitions. This is really hard in languages that don't have some function keyword.

axy• 4 years ago

Glanced. 17 or 18 years ago I implemented my own programming language too so I can only say: keep on. Just a quick note in terms of Art and Beauty: what I expect from a new language is expressiveness, and encouragement of good programming techniques, so that a code written by an average programmer in the worst mood would not look as a total mess.

FpUser• 4 years ago

what is it with fn()? If we are so much into being terse then int abc() should be just fine. If we need readability than function() instead of fn() would do better.

azinman2• 4 years ago

From the post:

- Although C3 mostly conforms to C syntax, the most obvious change is requiring `fn` in front of the functions. This is to simplify searching for definitions in editors.

stormbrew4• 4 years ago

If you haven't heard of it before, look up the "most vexing parse" for the kind of thing languages are trying to avoid with this syntactic approach. That specific one is a c++ thing, but C also has its own versions of it (that c++ inherits).

Basically the C grammar is only context free if you cheat in the lexer, and any language trying to improve on C is likely to try to avoid that (or just give up and go wild).

lelanthran• 4 years ago

I interpreted the GP to mean: "Why use `fn` instead of `function`?"

After all, he did say:

If we need readability than function() instead of fn() would do better.

yellowapple• 4 years ago

fn() strikes me as a reasonable compromise between those two concerns.

throwawaymaths• 4 years ago

int abc() is not context-free Iirc.

EdSchouten• 4 years ago

I'm puzzled with what the market for these kinds of languages are.

C is sort of a dead end. There is very little innovation there. And that's fine; the users of the language seem to want it that way. They just want to write software the same way they've been doing for the last 20 years. Why would such a conservative user base want to switch to a different language like C3?

Linus once said this about Subversion: "Subversion has been the most pointless project ever started... Subversion used to say, 'CVS done right.' With that slogan there is nowhere you can go. There is no way to do CVS right." Could C3 be the Subversion of programming languages?

rwbt• 4 years ago

I'm puzzled with what the market for these kinds of languages are.

There's a significant number of C programmers who want something slightly more modern and convenient but don't want to write C++ due to a number of reasons.

I think Zig, D are examples of this niche but syntax wise they don't completely look like C.

bachmeier• 4 years ago

I think Zig, D are examples of this niche but syntax wise they don't completely look like C.

This is technically true, but someone that likes writing C while wanting a few extra features would mostly be able to write the same C code they always have if they stick to D's betterC. (I'm not familiar enough with Zig to comment on that.)

Edit: Should also add that D now compiles C code, so a C programmer could continue to write C as they want, write a few D functions where those features help, and compile them without writing any binding code.

com2kid4• 4 years ago

I think Zig, D are examples of this niche but syntax wise they don't completely look like C.

That is because C's type declaration format is provably, as in actually provably, terrible.

There is a reason the majority of modern languages have switched away from how C declares types.

Honestly it'd be nice if the C committee could find a way to tack on a new variable declaration syntax to C, so everyone didn't have to keep looking up, or using tools, to declare non-trivial function pointers.

0xFACEFEED• 4 years ago

C is sort of a dead end. There is very little innovation there.

C is a small language. There are benefits to that. But it also has a handful of historical oddities. Innovation here means to keep C small while also getting rid of those quirks.

C++ is enormous. Rust is headed in the direction of similar enormity.

stormbrew4• 4 years ago

C++ is enormous. Rust is headed in the direction of similar enormity

I don't think this is a fair characterization of rust really. For the most part the things on the horizon still for rust seek to reduce complexity by filing down sharp edges that force you to write complicated code. Stuff like GATs seem complicated until you repeatedly slam your head into the lack of them trying to do things that "seem" natural.

C++ on the other hand (after 2011) just never saw an idiom it didn't like enough to throw on the pile and there's little coherence to the way the language has grown in the last decade.

jonathankoren4• 4 years ago

C++ is a monsterous cruel joke compared C, but if you’re just looking for some syntactic niceties, nothing stops you from writing C in C++.

kaba02• 4 years ago

C is a small language which fails even at the most basic abstractions (you can’t really create a safe and ergonomic “zero-overhead” generic vector type). Due to the inherent complexity of low-level programming, expressive languages in this niche (C++, Rust) has to be reasonably complex just for this reason alone.

Zig is an interesting “exception” due to its strong compile-time metaprogramming capabilites, resulting in a small, but quite expressive language. But all 3 has a future. C is here to stay, but I really wouldn’t start any new project in it.

0x20cowboy2• 4 years ago

I love C because it’s so minimal.

And it’s not a dead end at all - embedded systems, wasm, wasi, really fast things, and aside from assembly it’s one of the first things on newer platforms (risc v for example).

I like Go for the same “try to keep it minimal” reasons, and keen to try Zig when I have some time.

I think the bias you are implying might be misplaced.

com2kid4• 4 years ago

The problem with C is that its... kind of minimal, but it also needs tons of extensions to get things done.

Want multiple heaps? That'll be a compiler extension. Want to specify exactly where a variable is laid out in memory? Compile extension.

Have a memory layout that isn't just a flat map of address space? Better reach for a compiler extension.

Hardware registers? Eh, overlay it with a union or a struct or something, it'll be fine. Unless you want some sort of non-trivial typing on those registers.

People forget that C is written against an abstract C machine. C is not written against the underlying hardware platform. And the abstract C machine may differ from your target hardware by a fair bit.

kaba02• 4 years ago

Why would C be the requirement for “really fast things”? It doesn’t even have any support for SIMD instructions other than going inline assembly.

bipson2• 4 years ago

"C is faster/smaller/... than C++" hasn't been true in a long time.

I would argue that the time you need to invest to get something done correctly in C is a cost you can avoid with (modern) C++

lerno19• 4 years ago

C is a great language. Actually it's not that small, it's just that modern languages often are very big (easy if you compare yourself to C++). The feature bloat is a fairly recent trend.

kloch• 4 years ago

C is sort of a dead

C is like a table saw without a blade guard. Simple yet precise, powerful, flexible, and will cut your fingers off if you aren’t careful.

But it’s often exactly the kind of dangerous saw we need sometimes.

There’s no point in trying to improve it - there are plenty of other, safer saws for that.

mst5• 4 years ago

This is kinda my opinion too.

C is awful, C is terrible, C is almost always the wrong answer.

But when it hits the spot, it's a fantastic wrong answer for a bunch of things.

billforsternz• 4 years ago

They just want to write software the same way they've been doing for the last 20 years.

Actually I just want to write software the same way I've been doing it for the last 40 years, but otherwise yeah.

_gabe_3• 4 years ago

This looks awesome! The main thing holding me back from switching from C++ to C is the lack of type safe generic programming. This language looks like it not only solves that, but adds some other interesting features like defer that I've been wanting to try out :D. It looks like there are some examples of large projects getting successfully compiled by C3 (the vkDoom).

Since this is still only alpha 0.2, I'm curious how stable the compiler is and whether the core language features are subject to change? I'd love to start using this on some projects, but I'm always afraid to adopt a language in its early stages.

lerno19• 4 years ago

You shouldn't use C3 on any larger project, but it could be an option for doing gamejams (with raylib or something else with a C API).

For vkDoom it's not a port to C3. What it demonstrates is instead C <=> C3 interop. I removed some of the central functions from the C code and implemented those in C3. The script compiles the C files into .o files with the normal C compiler, then uses the C3 compiler to compile the .c3 files into .o files. Finally all are linked together into a single binary showing off the simple ABI compatibility story (no extra annotations are needed to ensure compatibility - all C3 functions are automatically callable as C functions)

In regards to the versioning, I've gone through two versioning schemes for the pre-alpha. 0.1.0 is the first version I felt was sufficiently feature complete. Minor version changes (e.g. 0.1.x -> 0.2.x) is for any breaking changes. Minor version doesn't say how close it is to version 1.0 (minor version will continue after 0.9.x with 0.10.x). The 0.1 version was out in April. I try to make the compiler as solid as possible, but I would need thousands (rather than somewhere above 400) tests before I feel confident in the compiler.

Releasing 0.1 means I think that the language design is mostly there now, so fewer changes are coming. But joining any language before 1.0 is a bumpy ride.

Did that answer your question?

_gabe_3• 4 years ago

Yep! I appreciate the thorough response and I'll be starring the project and following it's progress. It's very cool and looks great so far. Good luck with the project!

chromatin• 4 years ago

Dlang's betterC mode [1] may be what you're looking for; D also has outstanding typesafe template-based metaprogramming.

[1] https://dlang.org/spec/betterc.html

aidenn0• 4 years ago

I was hoping to see betterC on the C3 comparisons page, but it is compared only to D in the large.

lerno19• 4 years ago

D's betterC is very nice. Very much worth looking at.

JonChesterfield2• 4 years ago

attribute ((overloadable)) in C will name mangle and dispatch using a close approximation to the C++ rules. Much saner in use than _Generic.

WalterBright2• 4 years ago

Should compare with DasBetterC too!

https://dlang.org/spec/betterc.html

asveikau2• 4 years ago

That page specifies a rationale of: code loaded from C will not load the D runtime. Is it also possible to provide a C-callable shared D library that initializes the runtime dynamically? Would you then get some missing features like global constructors?

Googling around seems to suggest there is rt_init or Runtime.initialize for that?

I've never used D, I'm just curious about the problem described.

Ps. Goes without saying that i, like others, appreciate your comments here.

WalterBright2• 4 years ago

The impetus for DasBetterC is to use a subset of D that does not require the D runtime library.

A surprising amount of D users like this and use it.

I use it for projects where I want a small runtime executable. DasBetterC executables are as small as C ones can be.

mhh__2• 4 years ago

If the D code is aware that it needs to initialize the runtime then yes, either that you or you initialize it yourself before using it.

rt_init will fire up the D runtime.

As for constructors the runtime should handle those when the module is initialised, so not necessarily on program start up or the DSO being loaded.

If, however, you want to register a C runtime constructor you can do do so with pragma(crt_constructor).

I actually recently-ish fixed a bug to make the aforementioned type of constructor work on MacOS because Apple decided to deprecate them with no reason.

lerno19• 4 years ago

BetterC is very nice. I'd like to imagine BetterC lifted out of the D compiler with its own spec and separate evolution... That would have been ideal for me. But with BetterC as part of the D compiler it will always feel more like a gateway drug for D rather than a language in its own right :D

There are a lot of C compilers out there, people write them for fun. I like the idea that someone would write a C3 compiler "for fun". So limiting implementation complexity is something I have as a goal. What would it take for someone to write a compiler for just the BetterC subset? Would it be doable like implementing C?

tialaramex• 4 years ago

Aside - Documentation says:

It is possible to cast the variant type to any pointer type, which will return null if the types match, or the pointer value otherwise.

That seems backwards to me. Maybe it's just me? Surely if the types match that's when we get the pointer value ?

My main point - Strings

I think at this point good strings are table stakes. If you're a general purpose language, people are going to use strings. Are they going to make a hash table of 3D vectors? Maybe. Are they going to do finite field arithmetic? Maybe. Are they going to need networking? Maybe. But they are going to use strings. C's strings are reprehensibly awful. C++ strings are, astoundingly, both much more complicated and worse in many ways, like there was a competition. You need to be doing a lot better than that IMHO.

I happen to really like Rust's str but I'm not expecting to see something so feature rich in a language like C3. I am expecting a lot more than from a fifty year old programming language though.

lerno19• 4 years ago

Variants... that's a bug in the documentation. Thanks for finding it!

I agree about strings. There are basically two strings we use: the string builder and the "string data" which is any sort of slice of bytes that can be interpreted as a string. But starting from there are a lot of different ways one can name and implement them. I'm doing some experiments and before those are finished I don't have a strong opinion.

One thing to note though is that C3 does not have RAII or move semantics and so the C++ std::string or similar isn't even an option.

mst5• 4 years ago

If I have that set of semantics I'll use nim compiled to C with ORC attached.

You're aiming for something different, and I appreciate the idea even if I never end up using it.

In the unlikely case you haven't already read it about the only time I got C to do what I wanted without just segfaulting everywhere (my mistakes) was using djb's substdio.

synergy20• 4 years ago

Awesome stuff. It seems like a C+ instead of C++ to me.

I wish it has class/object/ctor/dtor/RAII though, no need for exception. OOD in C using struct and function pointers are doable but is a bit cumbersome. I don't even need runtime overloading or virtual inheritance or any fancy/advanced features of c++, just a better way to organize code in an OOD style is enough, something like Javascript's class sugar syntax to its prototype object syntax(here will be c++ style to struct+function-pointer-style).

lwswl4• 4 years ago

multiple function pointers in a struct is inefficient memory-wise, I think you'd be much better off with a single pointer to a lookup table that can be shared by all instances.

Its even more cumbersome, but its what you pay if you want efficiency in c.

mhh__2• 4 years ago

In my experience of using D at work alongside people who barely know how to program (i.e. smart but not culturally a Dev), and people who just didn't know D: if you have smart devs simplicity doesn't matter very much.

If anything it's easier to teach a concept than wait for a programmer to be able to see through a wall of messy simplicity.

msla• 4 years ago

Hey, I like any language with this kind of goto:

http://www.c3-lang.org/statements/#nextcase-and-labelled-nex...

It's also possible to use nextcase with an expression, to jump to an arbitrary case:

    switch (i)
    {
    case 1:
        doSomething();
        nextcase 3; // Jump to case 3
    case 2:
        doSomethingElse();
    case 3:
        nextcase rand(); // Jump to random case
    default:
        libc::printf("Ended\n");
    }

> Which can be used as structured goto when creating state machines.

sakras• 4 years ago

Holy crap I’ve been wanting to make basically this exact language for a while now: C with modules and defer!

I am wondering how strings are represented (I dislike the sentinel value scheme we have now), and what the library/locale situation is like (hoping it just says everything is UTF8).

Awesome that someone went and did it for me! The one thing I don’t like is the fn declaration, but reading other comments it makes sense why it’s there and I’m sure I’ll get used to it.

lerno19• 4 years ago

There isn't much of a reason to use anything beyond UTF8 today except for interfacing with code and documents that use UTF16.

childintime• 4 years ago

A big win C3 explicitly opts out of are integer types named by their size such as u8/u16/u32/.., yet explicitly sizes the types it does have. Another sore point in C: how do expressions involving different integer types work?

lerno19• 4 years ago

Do you wonder about how type promotion rules work in C3? If so then I can explain them as they differ somewhat from C. The reason for not using bitsize numbered types is readability e.g. `for (i8 i = 8; i > 0; i--)`

pratk• 4 years ago

Looks interesting, thanks! Just curious, any plans for supporting SIMD, similar to gcc's vector extensions ?

lerno19• 4 years ago

Vector types are built in, which you can do operations on, e.g.

    float[<4>] y = { 1, 2, 3, 4 };
    float[<4>] z = { 2, 2, 2, -100 };
    float[<4>] w = y + z;

It's not completely fleshed out with builtins yet, but will be.

sylware• 4 years ago

Just take C, remove the integer promotion and implicit casts (it means casting constant literals, yes), except for void* ofc. Remove those horrible __thread, generic, typedef (use the preprocessor for function types?), restrict, all optimization "hints", etc keywords. Finally standardize properly the preprocessor macro with a variadic number of arguments... Split completely the syntax definition from the the runtime lib (the main() function, etc).

It seems there is more to remove from C than to add.

euclaise2• 4 years ago

I think we do need a language like this, and that Zig/Odin/Myrddin/etc have the issue of having a syntax too different from C (Zig being the least offending; Hare is okay but perhaps a bit too minimal). This is great. Are there plans for a package manager? What's the target stdlib size?

That said, I'm not a big fan of the naming. It irrationally feels kinda hard to justify using a language called "C3" (and I also irrationally like cute names and mascots like Hare has).

lerno19• 4 years ago

There is a dependency relationship defined in C3 for libraries, but there is not (yet anyway) any package manager to actually pull those from a remote repository. It just ensures they are present when using it.

The standard library is far from done, but I imagine it having a common core, supported by all targets. Then a common set of modules that are available on most but not necessarily ALL targets. Outside of that there are “standard library ‘extras’” which will only be of use for certain programs. Beyond that there’s the vendor collection of officially supported external vendor libraries that are not part of the standard library.

lerno19• 4 years ago

Regarding the name, I am not in love with it, but people like my other names even less… Suggestions are always appreciated.

euclaise2• 4 years ago

I've been thinking of "Xi" or something along those lines. You might also consider something mythological like Odin and Myrddin, or something cute like Hare.

Show HN: C3 – A C alternative that looks like C

Related Stories