Live data from Hacker News

C2 Lang design (2014) [pdf]

c2lang.org

21–23 of 23 posts

Re: C2 Lang design (2014) [pdf]

#21
post #15
post #9

Thoughts as I read: 1. "uninitialized var usage is error": unfortunately impossible without at least one of the following compromises: Automatically initialize variables (wastes CPU); False alarms (see Java); Built-in formal proof system; or, Require compilers to solve the halting problem. 2. Removed keyword "static": kills one of my favorite tricks, "self-init'ing functions". 3. New keyword "as": A good invention in…

1. Works perfectly in Java. Note that in Java vars are both initialised to known empty values and not initialising a var explicitly in a local scope is an error. If the compiler can't prove your code is correct, then it's not obviously correct, which means I have to sit down and carefully think about if it's correct or not. Just write simple code. Though I concede that pointers make things very hard. Let's say you ha…

> This is more a problem of C's strings being naked pointers to chars.

A C string is a sequence of characters, not a pointer. C strings are manipulated using `char*` pointers.

Re: C2 Lang design (2014) [pdf]

#22
post #6

Is there an advantage to this over say a more modern and safe language like Rust? It seems to be just reducing the complexity of the language, but doesn't look like it will reduce memory related bugs.

Since you have to rewrite everything, you might as well switch to another language (we switched to OCaml). If there was an incremental path or a safe subset of C or something like that, that would be more interesting.

We have pretty good C interop, so you don't have to re-write everything, you can do it in chunks. Firefox isn't suddenly going to be reimplemented in Rust, for example, it will be library by library, bit by bit.

Of course, you can do that with some other languages too, but our lack of runtime and no-overhead makes it significantly better, in my opinion.

Re: C2 Lang design (2014) [pdf]

#23
post #5
post #3

Earlier quoted context omitted.

The main site makes it look like the language is about a year old. I have no doubt that they can make the parsing stage faster, as they won't be parsing the same headers over and over again. This is often a bottleneck in C++, but much less often in C. (I've seen 10+MB C++ files after preprocessing).

If people used precompiled headers (which have been available for about 20 years) that problem wouldn't be there... However I'm not sure that the parsing is such a bottleneck these days; I think all the complex constructs are a lot more of a time sink (templates etc). That and linking! Takes an hour to link the webkit library with the regular linker :-)

It's been a while since I tried precompiled headers, but the last time I tried it, the experience was unpleasant and error-prone.
Post reply on HN