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

C-for-all: Extending C with modern safety and productivity features

cforall.uwaterloo.ca

Post reply on HN
Print view View original

111–120 of 143 posts

Re: C-for-all: Extending C with modern safety and productivity features

#111

Post by remix2000 »

saagarjha wrote: post #79
remix2000 wrote: post #67

I’m very surprised that no one here has mentioned the Cyclone language[0] yet. It seems to me that it tried to address the same niche as C-for-all. [0] https://cyclone.thelanguage.org

> Cyclone is no longer supported This might be the reason.

Like I said, it tried to be an answer to similar problems, yet it failed. By the logic of C-for-all creators, Cyclone falls into the “evolutionary approach” group. Why Cyclone did not succeed in spite of “revolutionary” languages with similar aims gaining traction is what I don’t quite understand. I have never had any occasion to try Cyclone though, so I’m only basing my assumptions on what other people were saying about it. Still, its design appeals more to me than, for example, Rust, because ability to include C headers directly is IMO the very essential thing necessary to productively rewrite an old codebase.

Re: C-for-all: Extending C with modern safety and productivity features

#113

Post by parkovski »

ernst_klim wrote: post #59
parkovski wrote: post #50

Earlier quoted context omitted.

It's very confusing, they start off saying C++ is too complicated and then go basically reinventing C++ with (IMO) absolutely awful syntax. I think they're missing the point of why people use C - there's no magic. It's pretty much the wysiwyg of high level -> asm. If you want a systems language with magic there's C++. If you want a safe one there's Rust. Personally if I were going to make C better, I'd add a better m…

> C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

I don't think optimizations count as magic. It'd be entirely unreasonable for a language to not do them and they don't change the meaning of the program, undefined behavior aside.

"No magic" is meant as shorthand for "the minimal amount of magic we can reasonably expect given the history of the language and requirements for backward compatibility, and the least magic of any high level language with more than 3 users." Please don't make me do this again for the number 3.

Re: C-for-all: Extending C with modern safety and productivity features

#114

Post by mamcx »

I dream of "better C" as something that I wish existed. Not a "alternative to C" like Rust or ADA (that is BETTER, but not C). I think:

- A C developer must find as low friction as possible to use it.

- It will look alike C as much as possible.

- Will not bring a big semantic/syntax departure

- Not bring any novel stuff or Gc. BetterC is C as will be written by the BEST of the developers with the BEST practiques applied, and removed (as much as possible) the most obvious mistakes or ill-advised features.

- BetterC must be/have a transpiler. Even if that break for a while perfect behaviors it provide a way to cleanly upgrade things forward. Because BetterC is well writen C, the user will be encouraged to use it with the confidence of be in the ecosystem.

- BetterC must be incorporated (eventually?) as a front-end in a C compiler (like LLVM). So is like have "strict on" available.

- This mean is better if is backed by the community as a long, step-by-step goal of C. This also mean must be done for people that actually love/like C, just want it to be better.

- Must provide a set of blessed libraries like unicode strings, arrays, numbers, dates, etc. If not in-built at least included so most that use C as all-around lang not get out (similar in this case as Rust)

- Must encourage rewrite of critical pieces of code, despite zero-cost of FFI with C.

- Fix stupid syntax issues like dangling else. This is the "easiest" part I think.

- Find the biggest issues of the langs/common libraries and kill them.

- NOT ALLOW STUPID BY DEFAULT. Bring the "unsafe" keyboard here. No excuses!

- Bring sane macros.

- Bring AGTD, pattern matching, for ... in ..., and hopefully, fast fast compile times.

Re: C-for-all: Extending C with modern safety and productivity features

#115

Post by ernst_klim »

madmax96 wrote: post #75
ernst_klim wrote: post #59

Earlier quoted context omitted.

> C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represen…

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks?

You are confusing predictability with performance. OCaml is way more predictable exactly because it generates way more straightforward code.

On the other hand, GCC could do all kind of stuff, generating any sort of assembly. It can even rewrite fairly complex math functions, simplifying them.

Parent was talking about predictable ASM, not about performant ASM.

Re: C-for-all: Extending C with modern safety and productivity features

#116

Post by ernst_klim »

madmax96 wrote: post #98
atilaneves wrote: post #93

Earlier quoted context omitted.

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? Exactly because nobody (except backend writers) can predict what C compiler backends emit, especially when abusing undefined behaviour.

OCaml: https://godbolt.org/z/8bWDXy C: https://godbolt.org/z/WAjsvk I've never actually looked at the output of an OCaml compiler, I have to say I'm surprised by how clean it is. But I wouldn't call it more predictable than that C's output.

>C

You forgot about -O2/3.

Re: C-for-all: Extending C with modern safety and productivity features

#117

Post by ernst_klim »

parkovski wrote: post #113
ernst_klim wrote: post #59

Earlier quoted context omitted.

> C - there's no magic Strict aliasing and weak typing say hello. > wysiwyg of high level -> asm Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

I don't think optimizations count as magic. It'd be entirely unreasonable for a language to not do them and they don't change the meaning of the program, undefined behavior aside. "No magic" is meant as shorthand for "the minimal amount of magic we can reasonably expect given the history of the language and requirements for backward compatibility, and the least magic of any high level language with more than 3 users.…

> don't think optimizations count as magic

It's not about magic, you were talking about

> It's pretty much the wysiwyg of high level -> asm

which is not true until you use some ancient compiler from bell labs era. Modern C compilers emit totally unpredictable asm.

Re: C-for-all: Extending C with modern safety and productivity features

#118

Post by banachtarski »

olodus wrote: post #103
banachtarski wrote: post #52

Earlier quoted context omitted.

Zig is, however, unsuitable for interactive media or scientific computing due to the unfortunate lack of operator overloading (which is touted as a "feature"), rendering it less general purpose than I'd like. Other aspects of its design look good however.

Im not super sure what specific use case you are after but are you sure you can't do this in some ways with comptime generics? I have to be able to do most generic-like stuff with comptime (though I sometimes have to change the implementation a bit). I also really value how clear the lack of overloading makes the language. This way of clearly being able to follow the control flow is one of the things I like that they…

Yes I've tried zig a fair bit and the lack of operator overloading made the use untenable. The "ability to follow control flow" is, IMO, a silly argument. I will concede that `comptime` is a nice feature.

Re: C-for-all: Extending C with modern safety and productivity features

#119

Post by banachtarski »

dunkelheit wrote: post #106
banachtarski wrote: post #52

Earlier quoted context omitted.

Zig is, however, unsuitable for interactive media or scientific computing due to the unfortunate lack of operator overloading (which is touted as a "feature"), rendering it less general purpose than I'd like. Other aspects of its design look good however.

It is obvious how operator overloading makes scientific computing easier but what about interactive media? Can you clarify?

Oh so like, dual quaternion skinning, spherical quanternion interpolation, matrix multiplication, vector sums, etc.

I use a ton of linear algebra, vector algebra, and grassmann/clifford algebra at work and not having operators is like... why would I ever do that to myself. You end up in "parentheses" hell for things that would actually be nicely coded in concise and easy-to-understand expressions.

Re: C-for-all: Extending C with modern safety and productivity features

#120

Post by GlitchMr »

flohofwoe wrote: post #90
GlitchMr wrote: post #60

Wow, this is quite a trainwreck. I think it's possible to improve C while keeping compatibility with C programs, but that's not how you should do it. I think an improved C would be quite useful, but you really should be careful with what you include it, and keep the language simple. A lot of functionality feels like added because it could be added (WTF are nested routines). This way lies worse C++. In particular, I w…

You realize that this is (almost) valid C99? In C99 it looks like this: struct Point { int x; int y; }; struct Point new_point(int x, int y) { return (struct Point) { .x = x, .y = y }; }

Yes. In fact that's intentional.
Post reply on HN