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

131–140 of 192 posts

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

#131

Post by baranul »

lerno wrote: post #81
baranul wrote: post #61

Earlier quoted context omitted.

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

Wikipedia and their processes are independent to any language. It means that if Odin or other languages were removed, they were likely judged as not meeting the standard or not popular enough. That the Odin language is so old (around 9 years), and still not on it, is indicative of it not being as popular as various people are hoping.

The use of negative catch phrases and envious put downs by competitors of Vlang has no bearing on the Wikipedia process. They will not care about any competition or politics among programming languages. The language either meets their standard and proves its case, that it should have a page, or not. Just like Zig, Nim, Rust, etc... have done.

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

#132

Post by fuzztester »

tialaramex wrote: post #98
lerno wrote: post #49

Earlier quoted context omitted.

Other than C3, there is Jai, Odin, Zig and Hare which are the ones that have any traction right now that I know of. Many interesting projects have been started but ultimately later abandoned. Going to C++ competitors there is obviously Rust, but also Nim, Crystal, Beef and a lot of others. (And Jai is a C++ competitor too)

Notably all of these you mentioned aren't finished. C3 is 0.7, Jai is an "internal beta", Odin is working through a series of "dev" builds, Zig is 0.14, and Hare 0.24.2 This is maybe more striking when comparing against C which was already very old and battle tested in 1989 when it was standardized. If you pick any of these languages you're accepting an unknowable amount of churn. It better be worth it.

>This is maybe more striking when comparing against C which was already very old and battle tested in 1989 when it was standardized. If you pick any of these languages you're accepting an unknowable amount of churn.

C has plenty of issues too, even though it is very old, battle tested and standardized.

(How about all the UB in C, for example?)

That is why people are looking for C alternatives in the first place.

>It better be worth it.

It better be worth it for C too (and for C3; pun unintended but evaluated).

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

#133

Post by baranul »

kelnos wrote: post #84
baranul wrote: post #61

Earlier quoted context omitted.

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.

Have to disagree. Some type of solid metric has to be used, beyond claims by fans or language creators bombarding multiple social media sites.

First, "future prospect", is a claim almost any language can try to make. Unless it is a language created by a well known corporation (Carbon for example) or famous programmer (Jai or Mojo), such claims lack a foundation. A new language can really only make the argument of truly being a future prospect, if it comes from something already successful or famous.

Thus, for most newer languages, GitHub is a valid metric. Not just stars, but the number of contributors and activity associated with the repo. Other things like books on Amazon by third parties or articles about the language in well known magazines, would clearly count too. These things are measurables, beyond just hype.

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

#134

Post by baranul »

maleldil wrote: post #93
baranul wrote: post #63

Earlier quoted context omitted.

> Zig bdfl himself accused vlang of committing fraud a while back. That was truly foul. On top of that, begged readers to give their money to Zig. Clearly some have no limits on what to say and do against other languages or to sell their language. That's why whatever bad things a creator or evangelist says about another language, people shouldn't just swallow, and instead take with a grain of salt and some skepticism…

> That was truly foul Is it because, as the leader of a language, he shouldn't be making "attacks" against other languages? Because, as far as V being a fraud, he was 100% correct.

> Is it because, as the leader of a language, he shouldn't be making "attacks" against other languages?

Actually, yes. Not only from the angle of common decency or adhering to a code of conduct, but as a matter of professionalism and setting the example for followers.

> as far as V being a fraud...

That is a provably false claim from competitors, who should not be engaging in such activity.

Paying supporters[1][2][3] (ylluminate, gompertz, etc...) of the V language have even gone on record at HN, to clearly state such competitor or evangelist claims are false, and that they are happy with the language.

Not only can such competitor generated claims be seen as false, through direct V supporter refutation, but by the visible progress of the project as a whole. Over the years, the V language repo continually amasses thousands of stars and hundreds of contributors, that can be plainly seen on GitHub. It is a significantly large and successful project. To pretend or argue otherwise, is very disingenuous. People are there, because they like using Vlang[4].

[1] https://news.ycombinator.com/item?id=31801287

[2] https://news.ycombinator.com/item?id=31801262

[3] https://news.ycombinator.com/item?id=31812189

[4] https://github.com/vlang/awesome-v

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

#135

Post by throwawaymaths »

mort96 wrote: post #110
throwawaymaths wrote: post #100

Earlier quoted context omitted.

> distinguish between "this is a member access on an object" and "this is referencing something in a module". zig: what's the difference?

Surely Zig differentiates between, say, a function in a module, and a member on an object? Or are "modules" literally just instances of classes or something?

all structs are namespaces (there no classes). namespaces may contain declarations (consts and functions) or fields ("fields" are slightly different for unions or certain builtins like arrays and slices)

unions and enums also create namespaces. any @import creates a namespace that is a struct.

If a function's first argument is the type of the function's namespace or a pointer to the type of the namespace, you may (and by convention are encouraged to) use dot dereferencing (like python firso parameter self) as a lexical sugar to call the function with the "implicitly rearranged" first parameter ("oop style caling, but not really oop")

modules are somewhat different, in zig these are collections of code you can map to a non-filepath import string using the command line or build tool (in particular you may map something out of code root path), but these too ultimately become a namespace struct

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

#136

Post by joshring2 »

baranul wrote: post #133
kelnos wrote: post #84

Earlier quoted context omitted.

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.

Have to disagree. Some type of solid metric has to be used, beyond claims by fans or language creators bombarding multiple social media sites. First, "future prospect", is a claim almost any language can try to make. Unless it is a language created by a well known corporation (Carbon for example) or famous programmer (Jai or Mojo), such claims lack a foundation. A new language can really only make the argument of tru…

Unfortunately those things often come down to a chicken and egg scenario. Popular things get more popular, because they have demand, people write articles and then people visit the repo, write books etc they are strongly linked.

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

#137

Post by inkyoto »

sfpotter wrote: post #16

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 concur RE: «::». For deep levels of nesting, the level of noise that «::» causes becomes excessive.

When Rust was in its infancy, I maintained a local fork for a while where I modified the parser to use the Ada syntax («'», a single apostrophe) for the same purpose. So

  std::collections::hash_map::HashMap::entry
became

  std'collections'hash_map'HashMap'entry
But I am not convinced that using «.» for two distinct purposes – 1) as a name qualifier, and 2) as a method/data element accessor – is a good idea, for maintaining the semantic clarity is important, i.e. is «e» in «a.b.c.d.e»

  1) A method call; or

  2) An accessor for a deeply nested data structure.
It is not easy to say whilst just glancing upon the code.

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

#138

Post by sriram_malhar »

owlstuffing wrote: post #118
sriram_malhar wrote: post #115

Earlier quoted context omitted.

You don't need an ifdef. You just need a CLI option like java's --source, where you specify the source compatibility with different language versions.

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.

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

#139

Post by johnisgood »

lerno wrote: post #128
johnisgood wrote: post #117

Earlier quoted context omitted.

Oh thank you, that cpu_detect.c3 is exactly what I need, the posted single-header library is almost the same in terms of functionality. BTW my last question still stands, however, that if there is a C library that is only a single header file that implements functions through macros, can it be used from C3? In C, for what I posted, you would need to first do "#define CPUDETECT_IMPL" and then include the header file.…

It is possible to use a single-header library as part of C3 libraries or your project. However, it must be noted that this will inhibit the ability to cross compile, as the compilation of the header is outsourced to the natively installed C compiler. For that reason it's not an option for the standard library, but can certainly be useful for programs and libraries. For faults, they are usually defined with `faultdef`…

Thank you!

Is it possible to do something like:

  faultdef {
    FOO, // comment
    BAR, // another comment
    BAZ, // yadda
    // Maybe this would work, too (for docgen if available)
    QUX
  }
or something like that?

Does C3 have a way to generate documentation?

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

#140

Post by saghm »

kelnos wrote: post #83
lerno wrote: 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…

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

If anything, my default way of working in Rust is not to type out imports by hand; I just type what I want, then let rust-analyzer prompt me with what options there are to import it from and select the one I mean, and the import gets added to the to of the file. Occasionally I'll need to edit the imports myself for some reason (like if I have a dependency that's enabled only on platforms other than the one I'm developing on), but for the most part I just don't really think about it at all. I totally agree with you that I'd be way less happy with using wildcard imports, and I often to out of my way to avoid aliasing imports by using the full path in the case of ambiguity because I personally find it easier to read something like `std::io:: Result` than `IoResult` (with a corresponding `use std::io::Result as IoResult;` when I want to have a different `Result` in scope. I don't think it's a problem that being able to alias imports like that is an option, but I just happen not to find it particularly appealing even compared to using full paths.
Post reply on HN