Live data from Hacker News

The C3 Programming Language

c3-lang.org

111–120 of 270 posts

Re: The C3 Programming Language

#111

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 behav…

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?

Re: The C3 Programming Language

#112
post #24

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...

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.

Re: The C3 Programming Language

#113
post #11

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…

> 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.

Re: The C3 Programming Language

#114

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 behav…

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 rea…

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.

Re: The C3 Programming Language

#116
post #69

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.

Re: The C3 Programming Language

#117

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?

Re: The C3 Programming Language

#118

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.

> dangling pointers to raw memory that [are not] cleaned

How do you feel about building special constructs to automatically handle these ?

Re: The C3 Programming Language

#119
post #88

Earlier quoted context omitted.

> 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 facilitie…

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.

Post reply on HN