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

181–190 of 192 posts

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

#181

Post by throwawaymaths »

mort96 wrote: post #177
throwawaymaths wrote: post #170

Earlier quoted context omitted.

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.

Please enlighten me, what are objects in zig? As far as i know this is not a defined concept in the language, so I'm assuming you think that structs are objects because struct namespace functions can be called with a syntactic sugar that makes it look like an object in a language that has them.

Do you mean object like object file (to be linked)? Those don't have member functions as far as I know.

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

#182

Post by dkersten »

lerno wrote: post #178
dkersten wrote: post #33

Earlier quoted context omitted.

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?

How can you build something in Jai before you have access to Jai?

I heard he only gives access to people who more out less guarantee they will use it relatively heavily, but how can I know of I will before I can scarily try it?

Basically I heard he only gives access if he thinks you will use it — not just so you can try it. That might work fine for people with enough time on their hands that they can say “I’ll do this full project in it, regardless of how it goes”, but I prefer to be able to tinker first to see if I find it suitable. For example, I’ve had projects where I though “ok I’m going to do this in Rust|Zig” and after trying for a few days realising that it’s not the route I want to take.

In any case, anyone can just download C3 and try it. You can’t just download Jai to try it. So my statement is still true.

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

#183

Post by owlstuffing »

sriram_malhar wrote: post #138
owlstuffing wrote: post #118

Earlier quoted context omitted.

You do, that's the point here. You need ifdefs in this example to selectively compile the same code with different compilers, or different language levels with the same compiler. In either case C3 will fail while parsing a newer feature with an older compiler or lang level.

This exact situation is there in Java, using compiler args, after lambda functions were introduced. Older compilers would not be able to handle it, and the newer compilers would not break backward compatibility.

And. . . Java does not have conditional compilation.

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

#184

Post by CyberDildonics »

lerno wrote: post #175
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.

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

The temp allocator is a stack allocator,

How much have you used that? C has that and it will get cleared at the end of a scope too, but it is pretty exotic because it is so fragile. It's a catch-22, if something is so big that you need to allocate the exact size to save stack space, then it could become problematic and blow the stack. This is not a substitute for having allocations be freed at the end of a scope.

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.

I think stuff like this is interesting, but it's interesting in the context of straight C, not in the context of a new language where it could be done better.

In regular C you could already create a custom allocator and macros that would use the fact that a for loop will run something after the scope finishes to mimic some of these effects.

C's syntax may be a little funky, but it's real pain point is the actual semantics that will bite people over and over until they move on.

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

#185

Post by pajko »

johnisgood wrote: post #10
dooglius wrote: post #5

How does this compare to Zig or Odin, which have the same goals of improving upon C and have gotten occasional publicity here on HN?

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

This is missing Nim.

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

#186

Post by mort96 »

throwawaymaths wrote: post #181
mort96 wrote: post #177

Earlier quoted context omitted.

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.

Please enlighten me, what are objects in zig? As far as i know this is not a defined concept in the language, so I'm assuming you think that structs are objects because struct namespace functions can be called with a syntactic sugar that makes it look like an object in a language that has them. Do you mean object like object file (to be linked)? Those don't have member functions as far as I know.

Why would I think that structs are objects?

I'm using "object" as it is commonly used; essentially a value. In e.g Java or C or C++, the struct/class is a type, and an instance of the struct/class is an object.

Accessing an object's members is a different operation from looking up a symbol in a namespace. Even in Zig.

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

#187

Post by lerno »

pajko wrote: post #185
johnisgood wrote: post #10

Earlier quoted context omitted.

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

This is missing Nim.

I haven't used Nim enough to write a good comparison. I am not mentioning Crystal either. If someone wants to contribute a comparison I'd be happy to feature it. It is supposed to be fair and simply outline the differences in features.

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

#188

Post by lerno »

SleepyMyroslav wrote: post #180
lerno wrote: post #179

Earlier quoted context omitted.

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

In C casting a pointer to an int and back again used to be fine. Except later people want to track the pointer to do optimizations and things went... poorly.

I feel that this is a mess better addressed once there are actual implementations that you have to use, rather than the current state where people are still working out the details.

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

#190

Post by lerno »

CyberDildonics wrote: post #184
lerno wrote: post #175

Earlier quoted context omitted.

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

The temp allocator is a stack allocator, How much have you used that? C has that and it will get cleared at the end of a scope too, but it is pretty exotic because it is so fragile. It's a catch-22, if something is so big that you need to allocate the exact size to save stack space, then it could become problematic and blow the stack. This is not a substitute for having allocations be freed at the end of a scope. For…

No, not alloca, I mean a stack allocator as you push / pop memory scopes.

The trailing body macro is something I think you should try out before dismissing it. It's similar to how Ruby can do it, with the closures exiting the "outer scope", which is unusual.

Post reply on HN