Live data from Hacker News

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

github.com

81–90 of 192 posts

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

#81
post #61
post #26

Earlier quoted context omitted.

> People who "figured out" Zig tend to be fiercely loyal to the language in a similar way as Rust evangelists to Rust. This is very much not productive and you’re now part of spreding this narrative. There’s plenty of people out there who has «figured out» and appreciate both Zig and Rust without becoming attached to it. I’m interested in communities which looks towards other languages for inspiration and admiration,…

This is a good point about narrative spreading, in addition to marketing. People can become evangelized by their use of certain languages or by comments from certain language creators, then go on to attack others for using or even just wanting to try other languages. This shouldn't be what HN is about. It makes it look like HN has a language approval list. As for both C3 and Odin, they've been around for many years,…

Did you know that Wikipedia editors will aggressively remove Wiki entries about less known languages. There are already several wiki articles on Odin by various authors that have been removed over the years.

Talking about GitHub numbers, we can look at VLang, which had an astronomical trajectory initially due to overpromising and selling a language that would solve long standing issues such as no manual memory management but no GC needed etc.

Such viral popularity creates a different trajectory from organically growing word of mouth such as in the Odin case.

Vlang also has a Wikipedia page.

Is this then proof that it is a viable alternative to the general public? This is what you argue.

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

#82
post #57

Earlier quoted context omitted.

C3 has "path shortening", so for example given `open(...)` in std::io::file is usually used as `file::open(...)`. If we would to write this as `file.open(...)`. Consider now the case of mistyping `open`: `file.openn(...)`. Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope? Also, "io", "file", "random" etc are commonly used variable…

> Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope? D uses a spell checker for undefined identifiers, and the dictionary is all the identifiers in scope. It has about a 50% success rate in guessing which identifier was meant, which is quite good. > Also, "io", "file", "random" etc are commonly used variables, so the issue with sha…

If I would have liked, I could have done something like `import std::io::file as file;` but I noticed that we keep getting this issue that we’re renaming things all of the time, and usually in the same way. This is why path shortening is there. To directly get something like the informal `file_open` namespacing in C programs.

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

#83
post #57

Earlier quoted context omitted.

> `::` simplifies the module vs identifier resolution The identifier on the right is looked up in the scope of the identifier on the left. If it resolves to a module, then it's a module. If it resolves to a function, then it's a function. If the left side is a pointer (not a symbol with a scope) then the right side resolves to a member. It also makes refactoring much easier - changing a pointer to a reference does no…

C3 has "path shortening", so for example given `open(...)` in std::io::file is usually used as `file::open(...)`. If we would to write this as `file.open(...)`. Consider now the case of mistyping `open`: `file.openn(...)`. Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope? Also, "io", "file", "random" etc are commonly used variable…

I feel like path shortening is the issue, and IMO it's an unnecessary feature. I don't think most programmers are bothered by the need to explicitly import what they use. I'd personally prefer to explicitly import what I use, and refer to it in whatever way the import statement would imply.

In Rust where modules share a namespace with other identifiers, I just pick different variable names, or write my imports so they don't conflict. It's not that big a deal.

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

#84
post #61
post #26

Earlier quoted context omitted.

> People who "figured out" Zig tend to be fiercely loyal to the language in a similar way as Rust evangelists to Rust. This is very much not productive and you’re now part of spreding this narrative. There’s plenty of people out there who has «figured out» and appreciate both Zig and Rust without becoming attached to it. I’m interested in communities which looks towards other languages for inspiration and admiration,…

This is a good point about narrative spreading, in addition to marketing. People can become evangelized by their use of certain languages or by comments from certain language creators, then go on to attack others for using or even just wanting to try other languages. This shouldn't be what HN is about. It makes it look like HN has a language approval list. As for both C3 and Odin, they've been around for many years,…

I don't think I'd use popularity-contests like Github stars or the presence of a Wikipedia page to judge a language's popularity or future prospects.

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

#85

Earlier quoted context omitted.

Sure, but in practice I believe most developers would find it intuitive to just type . everywhere. It feels more lightweight and consistent, and collisions aren’t super common once you adopt some conventions. It’s a tradeoff for sure, but this preference comes from having lived in both worlds.

I’ve lived in both and I prefer ::.

I prefer a world where there is no distinction between modules (or namespaces) and object, so '.' it is. (and I'm almost exclusively a C++ programmer).

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

#86
post #22

Earlier quoted context omitted.

As the author, let me add something beyond the comparison. Zig and Odin are very different languages, Odin is – as its slogan goes - "for the Joy of Programming". Zig on the other hand doesn't feel that this is a goal. From what I can tell Zig fans like to wrestle with the features of Zig to figure out how to fit their solutions within the constraints of the language. A mental challenge, similar to that of fighting t…

On ziglang.org the very first thing we advertise is: > Focus on debugging your application rather than debugging your programming language knowledge. Clearly, you think the language fails at this criteria (your subjective opinion). Please be honest and say that, rather than implying that it's not explicitly one of the core design principles of the language (objectively false).

(Funny story, I seem to have a bout of visual migraine at the moment and misread your comment until just now and had to remove what I wrote).

I didn't mean to give the impression that I'm putting down Zig. It's more that I've noticed that people tend to frame problems differently with Zig than with Odin.

To explain what I mean by framing, consider OO vs procedural and the way OO will frame the problem as objects with behaviour that interact, and procedural will frame the problem as functions being invoked mutating data.

The difference isn't at all that stark between Odin and Zig, but it's present nonetheless. And clearly Zig is doing something which a lot of people like enjoy. It's just that the person using Zig seems to enjoy different aspects of programming (and it seems to me be in the spirit of "the challenge of finding an optimal solution") than the person using Odin.

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

#87
post #76
post #75

Earlier quoted context omitted.

This is not that novel. It is inspired by the similar feature in the Odin language.

ah, neat if it's becoming a standard convention of sorts. i haven't used odin either.

It's a good language, you should try it out as well.

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

#88

I have used this language for a few things (csv parsing and some simple personal cli tools). Other than the normal pre-1.0 issues it's great. I wish it had a tagged union type, but it looks like that's planned based on the github issue tracker. It is a pretty big improvement on C without changing the ABI. Maybe not the improvements I would make if I was smart enough to make a compiler, but better than doing C which I…

Making compilers are not that hard. Sure, it grows in complexity as you make it more feature-complete. But writing compilers is actually a lot of fun. If you're interested in compilers you should definitely try making a simple one. This book is free and a great starting point: https://craftinginterpreters.com/. I'm not associates with the book author in any way, I just found incredible value in it.

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

#89
post #79

@lerno, how do you feel about contributions to the standard library? For example, I might add BLAKE2 if it is not already implemented. Also I just checked the source code of hash map. What if I want to use a different hashing algorithm for "rehash"? There is no one true implementation of a hash table either, for example, so I am not sure what to do with that. I want a thread-safe hash table, I wonder if it would ever…

Blake2 and other hashes are most welcome. As for HashMap you are completely correct: there are many different types of maps that are needed. Concurrent maps, insertion ordered maps etc. And even variations of the small things: are keys copied or not! I talked about this on a stream recently, how the standard library is in need of a lot of additional Maps, Sets and Lists. So if you’re interested in contributing then y…

> And even variations of the small things: are keys copied or not!

Yeah, or if duplicates are allowed or not, initial size, load factor, and so forth.

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

#90

One thing I just can't understand is proactively using the :: syntax. It's sooo ugly with so much unnecessary line noise. Just use a single period! I think one of the best decisions D made was to get of -> and :: and just use . for everything.

I like to quickly at a glance be able to distinguish between "this is a member access on an object" and "this is referencing something in a module".

I like that the compiler can distinguish those two things too, so that I can refer to things within modules even if I happen to also have a local variable with the same name. Go sometimes annoys me because I need to rename a module or a variable just because the syntax doesn't distinguish between the two things.

Post reply on HN