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

Show HN: The C3 programming language (C alternative language)

github.com

Post reply on HN
Print view View original

171–180 of 192 posts

Re: Show HN: The C3 programming language (C alternative language)

#171

Post by CyberDildonics »

Joshringuk wrote: post #163
CyberDildonics wrote: post #159

Earlier quoted context omitted.

Does it just deallocate at the end of a scope? Why go halfway? It's obviously valuable and destructors are not complicated. Destructors can also close files, sockets, deallocate buffers from the GPU, etc. I think when people want C semantics they will just use C in general, but if there is something that solves these extreme pain points in a simple way it might be enough to get someone to switch.

Yes the temp allocator will remove things at the end of it's scope. It makes it very clear when memory will be affected and gives predictable code execution. There are other contexts for managing mutex locks so they auto close and you could dream up one for database connections and transactions too. The nice things about a context is you can always see it's there, destructors by design are a bit hidden which can make…

Destructors take care of all these situations and because they are hidden and run automatically at the end of a scope you don't forget them or mess them up.

I have never heard anyone say they are hard to reason about, especially if there is no garbage collection or inheritance.

Re: Show HN: The C3 programming language (C alternative language)

#172

Post by lerno »

lerno wrote: post #144
owlstuffing wrote: post #119

Earlier quoted context omitted.

Well, if your language gains traction that plan may not succeed. For your sake, I hope that's the case :)

I know it’s hard.

That one was missing a comma: "I know, it's hard". I'll do my best.

Re: Show HN: The C3 programming language (C alternative language)

#173

Post by lerno »

djmips wrote: post #156
lerno wrote: post #152

Earlier quoted context omitted.

You could still do it as a userland feature and implement add/sub/mult/div as methods on the type.

That never works as well as having it built into the compiler.

Well, you're free to revive this issue: https://github.com/c3lang/c3c/issues/1451. I'd need a more solid proposal.

Re: Show HN: The C3 programming language (C alternative language)

#175

Post by lerno »

CyberDildonics wrote: post #159
lerno wrote: post #157

Earlier quoted context omitted.

Personally I think it is reasonable that a C alternative is an alternative to C, and not a C++ alternative. C3 uses a temp allocator that removes a large number of cases where C++ would need RAII to manage memory. Did you try C3?

Does it just deallocate at the end of a scope? Why go halfway? It's obviously valuable and destructors are not complicated. Destructors can also close files, sockets, deallocate buffers from the GPU, etc. I think when people want C semantics they will just use C in general, but if there is something that solves these extreme pain points in a simple way it might be enough to get someone to switch.

The temp allocator is a stack allocator, so it's a bit more flexible than that and can be used for return values or even more long lived allocations. It doesn't use the standard heap allocator to alloc, so there is a potential win in speed and cache coherence as well.

For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.

There is an example here: https://c3-lang.org/generic-programming/macros/#trailing-blo... but it's used in the stdlib quite a lot.

Re: Show HN: The C3 programming language (C alternative language)

#177

Post by mort96 »

throwawaymaths wrote: post #170
mort96 wrote: post #168

Earlier quoted context omitted.

Right, that's what I thought. So object member lookup and module/namespace lookup are not the same thing

Depends. Your module can have top level member fields or declarations. (By convention these modules would be capitalized) and in that case it would be instantiated as a struct (no objects in zig) MyModule.zig somefield: u32, fn get(self: @This()) u32 { return this.somefield; } main.zig const Module = @import("MyModule"); // note there are build parameters necessary to make this a module fn main() void { var x: Module…

I don't understand why you're repeating this. The module is a struct, not an object. That means that in Zig, module lookup and object member lookup are different things. A module is not an object, it is a struct, so looking something up in a module is not looking up a member in an object.

Re: Show HN: The C3 programming language (C alternative language)

#178

Post by lerno »

dkersten wrote: post #33
johnisgood wrote: post #10

Earlier quoted context omitted.

It is answered here: https://c3-lang.org/faq/compare-languages/

I feel like its missing a point for "In C3 but not in Jai": you can actually download and use C3...

Well, it's not that difficult to get into the Jai beta if you are building something with Jai I think?

I seem to recall that Jon just asked beta testers that they actually have a project that they will use it for?

Re: Show HN: The C3 programming language (C alternative language)

#179

Post by lerno »

SleepyMyroslav wrote: post #167
lerno wrote: post #166

Earlier quoted context omitted.

I don't have any particularly strong stance on provenance. But I've yet to see a strong argument for it in C. There is not much of a guide I'm afraid. I translated some of the raylib examples to C3: https://github.com/c3lang/c3c/tree/master/resources/examples... But those are straight up conversions of the original C code. I think any C tutorial on gamedev would work fine to follow in C3, and then one can leverage fe…

Judging from 'comparing pointers of different provenance' can produce 'any result' ( here https://c3-lang.org/language-rules/undefined-behaviour/#list... ) everyone has to deal with it. More low effort questions. Question about optional debug traps: are they available in optimized builds? Are any LLVM sanitizers available? It usually means language needs to have APIs to mark up your own allocators/containers/etc. Doe…

I think that one is a bit wrong, I must have written it many years ago. There are machines where pointers do have different address spaces, like the Arduino obviously, but that support isn't in the language yet, and maybe there might be issues there but comparing something like `int` and `float` pointers, that shouldn't be UB. I'll look at that text.

Debug traps can be kept in optimized builds, you can always do something like "-O3 --safe=yes". Right now it's not possible to set it per function or module, but that might be added if there is demand for it.

Because C3 also has contracts, the plan is to step by step increase static analysis to catch more of the contract violations at compile time.

For example:

     10
     @require b 
    fn void test(int a, int b) {}
Will error at compile time for `test(5, 2)` (first @require), or `test(5, 10)` (second @require). These will also be checked at runtime, but catching low hanging fruits a compile time will be very helpful I think.

LLVM address and thread sanitizers work. The memory sanitizer still has some issues but will be fixed.

Currently there are just cross platform threads available and some rudimentary thread pools. This needs to be expanded and we'll see if there are things the language could help with but there will not be any async built in.

Re: Show HN: The C3 programming language (C alternative language)

#180

Post by SleepyMyroslav »

lerno wrote: post #179
SleepyMyroslav wrote: post #167

Earlier quoted context omitted.

Judging from 'comparing pointers of different provenance' can produce 'any result' ( here https://c3-lang.org/language-rules/undefined-behaviour/#list... ) everyone has to deal with it. More low effort questions. Question about optional debug traps: are they available in optimized builds? Are any LLVM sanitizers available? It usually means language needs to have APIs to mark up your own allocators/containers/etc. Doe…

I think that one is a bit wrong, I must have written it many years ago. There are machines where pointers do have different address spaces, like the Arduino obviously, but that support isn't in the language yet, and maybe there might be issues there but comparing something like `int ` and `float ` pointers, that shouldn't be UB. I'll look at that text. Debug traps can be kept in optimized builds, you can always do so…

if you plan to look at pointer provenance please check recent HN discussions like this one ( https://news.ycombinator.com/item?id=42878450 ) and transitively links to source papers for C.

TLDR (imho) C has failed to define pointer provenance but had to acknowledge its existence. LLVM and GCC have their own ideas on it which means their open issues on it are different. For practical languages aiming to be useful in embedded ie Rust there are complex workarounds: https://doc.rust-lang.org/std/ptr/index.html#exposed-provena.... What is relevant for C3 is that it is likely to be exposed to open issues from LLVM and people will need practical ways to solve them.

ps Don't take my word for it. My tldr might be wrong because of my gamedev experience (like we dont ship products with GCC).

Post reply on HN