Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C3 Programming Language

c3-lang.org

Post reply on HN
Print view View original

221–230 of 270 posts

Re: The C3 Programming Language

#221

Post by flohofwoe »

rixed wrote: post #35

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: - uses LLVM (so: as portable as LLVM) - sadly, does not support tagged enums 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?

Re: The C3 Programming Language

#222

Post by atombender »

tialaramex wrote: post #90
Fraterkes wrote: post #52

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…

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.

Re: The C3 Programming Language

#223

Post by reactordev »

brabel wrote: post #211
reactordev wrote: post #133

Earlier quoted context omitted.

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

Re: The C3 Programming Language

#224

Post by atombender »

card_zero wrote: post #96
ibuildbots wrote: post #81

Earlier quoted context omitted.

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

Re: The C3 Programming Language

#225

Post by SkiFire13 »

riazrizvi wrote: post #65
SkiFire13 wrote: post #60

Earlier quoted context omitted.

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!

Re: The C3 Programming Language

#226

Post by SkiFire13 »

Phil_Latio wrote: post #84
SkiFire13 wrote: post #60

Earlier quoted context omitted.

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.

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

Re: The C3 Programming Language

#227

Post by reactordev »

avadodin wrote: post #206
reactordev wrote: post #194

Earlier quoted context omitted.

Any flat memory rtos. Not everything is *nix. For example microcontrollers or aerospace systems.

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.

python is not an option in this environment. Correct your tone.

Re: The C3 Programming Language

#228

Post by reactordev »

CyberDildonics wrote: post #197
reactordev wrote: post #194

Earlier quoted context omitted.

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.

Re: The C3 Programming Language

#229

Post by abyesilyurt »

SV_BubbleTime wrote: post #173
impoppy wrote: post #12

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

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

Re: The C3 Programming Language

#230

Post by sph »

reactordev wrote: post #228
CyberDildonics wrote: post #197

Earlier quoted context omitted.

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.

Post reply on HN