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

201–210 of 270 posts

Re: The C3 Programming Language

#201

Post by jeremyjh »

fc417fc802 wrote: post #195
jeremyjh wrote: post #178

Earlier quoted context omitted.

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

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 ?

Re: The C3 Programming Language

#202

Post by WalterBright »

sureglymop wrote: post #168
WalterBright wrote: post #106

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.

Re: The C3 Programming Language

#203

Post by sixthDot »

norir wrote: post #79
contificate wrote: post #41

Earlier quoted context omitted.

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

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.

Re: The C3 Programming Language

#206

Post by avadodin »

reactordev wrote: post #194
CyberDildonics wrote: post #184

Earlier quoted context omitted.

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.

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.

Re: The C3 Programming Language

#207

Post by bluecalm »

lerno wrote: post #136
bluecalm wrote: post #108

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

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…

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.

Re: The C3 Programming Language

#208

Post by bluecalm »

florianist wrote: post #176
bluecalm wrote: post #97

Earlier quoted context omitted.

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…

In the current C standard that's unreachable() from

Thank you, I've just recently read the list of new features and missed this one!

Re: The C3 Programming Language

#209

Post by bryanlarsen »

fc417fc802 wrote: post #187
bryanlarsen wrote: post #181

Earlier quoted context omitted.

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.

Re: The C3 Programming Language

#210

Post by irishcoffee »

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.

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.

Post reply on HN