lerno

The C backend is still experimental and far from ready for prime time, so it's not unexpected!

This 0.0.1 bump to the C3 compiler and stdlib ended up rather massive: it adds a 15000 loc windowing module and an experimental C backend.

(And don't forget we also released the new playground with graphics and sound, running the entire compiler in the browser, see https://play.c3-lang.org/?example=neon_overdrive)

C3 is a C/C++ alternative for general purpose programming.

Some links:

https://c3-lang.org - main site

https://github.com/c3lang/c3c - github repo

https://learn-c3.org - tutorial

https://c3-lang.org/standard-library/docs.html - standard library docs

<> is the worst choice for generic syntax in a language with C-like syntax. It's not surprising that it was introduced by C++. It is very ambiguous.

Some short examples: `foo<1> * a` – is this `(foo < 1) > (a)` or `(foo<1>) a`? What about `foo<1>>2>a`? Is that `(foo<1> > 2) > a` or `foo<(1>>2)> a`?

Just horrid.

Or `cast{int*}(myage)`

It works visually poorly with things like `int*(ptr)` and `int[2]*(arr)` though.

The C3 temp allocator leans into this though. It’s not a frame allocator but acts like a stack allocator. It solves the ”oh, how do you make sure the data you got back is properly freed”. In Zig you need to create and free arenas by hand, which is not far from freeing the returned allocations by hand.

But I think C3 shows it can be taken further.

Zig, for better or worse, have a strong messaging and isn’t afraid of making big claims. That they don’t always pan out (”faster than C”, ”colorless async” etc), doesn’t matter. Zig was the first C alternative to spring from the interest Jon Blow ignited with his language dev and that marketing lead has been superbly well maintained by Andrew.

Odin and C3 has at least a magnitude fewer people knowing about them. More modest claims, less marketing potential.

So for D, it was to my memory never sold as a silver bullet either. A better C++ certainly, but with enough humility to not market itself as some game changer.

Compare Zig, V and Rust marketing with D’s and you’ll see what I mean.

I believe all examples are derived from C++ examples on its new reflection capabilities.

C3 has an even simpler way than Zig: `Color.RED.description`.

From what I can see the example started from C++, and then comparing how each language would look building it in userland instead.

Yes, lesson learned.

TLDR; people think that a "C-alternative" means "used for what C is used for today". But that's not what the C alternatives (except for Zig) try to achieve.

This is partly true. But I want to add that the ergonomics of C3 is there to make general app development smooth, whereas for Zig that is not really the focus.

So the goal for C3 is to also be used where you'd use C/C++/Swift/ObjC today.

This isn't a very exciting release: it adds a few useful things to libraries and to generic compile time introspection – but that's pretty much it.

Just some incremental improvements.

If you haven't tried C3, feel free to jump to https://learn-c3.org and try it in the browser.

Yep

Counterpoint: https://news.ycombinator.com/item?id=47989154

One funny thing is that if you go on codeberg and want to submit a PR to Zig, you can't. Because Zig's too big for Codeberg, and you're over your free quota, so you can't push your update to your fork.

Yes there are ways around it if you have patience, but what the heck!!

Early days of Wikipedia was the wild west. Surely you must agree to that.

No, Grokipedia is just a crapfest. I'm talking about actually asking ChatGPT

And as an example of bias: I personally witnessed a wikipedia editors adding their own interpretation of a certain written article. This interpretation was very politically biased and not justified by the text, but these were influential wikipedia editors so that it stayed in. I then asked the author of the article on Twitter if this interpretation was correct. I was unambiguously told NO. This information (including the public twitter conversation), was rejected by the wikipedia editors because it was first hand accounts.

Which led to the rather odd result that the interpretation of an article's message by a Wikipedia editor was favoured over the explicit statement by the article's author.

Here I would have thought that it would have been prudent to simply leave out that part of speculation, but they adamantly insisted it should stay.

I must add that this happened on Swedish wikipedia, not the main English Wikipedia – which I actually found much more balanced. But the problem is that this mechanism exists in the first place.

It was at the time (5-10 years ago?) well known that the Wikipedia of some language – I don't recall which one – was at the time pretty much hijacked by a group. Oh, wait I found it - the Croatian Wikipedia.

This is unlikely to happen to the main Wikipedia, but it does demonstrate a certain brittleness and risk of bias in the system.

The C3 grokipedia entry was horribly bad, so I don't really have a favourable impression of it.

It's funny. Today people say that of Wikipedia, as if it was trustworthy. But it used to be common knowledge to just "don't trust anything on Wikipedia". Wikipedia was never like a regular encyclopedia, it just wanted to be one.

Its biggest advantage over traditional encyclopedias was its breadth and how quickly it could be updated. The trade-off was that articles could vary greatly in quality and could be edited by anyone, making accuracy less consistent than in traditionally edited reference works. So the effort to reduce breadth and say it shouldn't be updated quick... that's just strikes me (as someone fairly old) as kind of funny.

What kind of happens is that there are some people who invest their lives in Wikipedia, their opinions is what ends up mattering.

This has boths pros and cons. The good thing about it, is that these people are deeply invested in Wikipedia and therefore have a lot of incitament to do what (they believe at least) is the best for Wikipedia.

The downsides are: (1) that just because you invested a lot of time into Wikipedia you don't have biases (2) you are not immediately qualified to determine whether some article/source is bad or not from a factual point of view.

Also, it's very HARD to become a regular contributor, because you'll have to invest an insane amount of time initially to build up goodwill and reputation, when at the same time anything you do might just get reverted because someone thought it was too much detail or bad in some other way.

So it's a very punishing environment which makes sure that the actual group of Wikipedia editors is a fraction of what one could expect. (Also, the Wikipedia markup... it's really the worst dialect of Wiki syntax)

Anyway, all of this is probably not good for Wikipedia in the long run. LLM's will be much better than humans at creating "beginner" articles, and it will be increasingly hard to know what's LLM-authored. So I expect Wikipedia to go the way of Stack Overflow in the long run.

The Zig C import is going away, moving into a tool invoked from build.zig, so this might not be an ideal thing to point to.

C3 just has everything C compatible so not just calling into C but also C calling to C3 is just completely normal with no special compatibility types/functions, unlike Zig.

So which one has the most compelling feature kind of boils down to what one focuses on.

You can find Odin users that praise Odin for finding their sweet spot. Similarly for C3 users, just like Zig users.

And in each of those, they will say that the others didn’t quite match what they wanted (not in all cases though: the relatively high visibility of Zig means a lot of its users is unaware of the languages with less visibility, and just pick it by default)

If you use LLVM at least, they expand to a lot of code which is repeated on every operation. There’s a point where the inline code will just blow the instruction cache and just create unacceptable binary bloat.