Live data from Hacker News

Cello – High Level C

libcello.org

21–30 of 83 posts

Re: Cello – High Level C

#21
post #5

Earlier quoted context omitted.

Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

I have to say, I'm really exhausted with the way every single C/C++/Go discussion on HN ends up having someone chime in to say, "Why not just use ~Rust~?". I'm a huge fan of Rust, as I'm sure many of us are, but it isn't some cure-all. It can't just be dropped into any arbitrary use-case where performance happens to be somewhere on the radar, and magically surpass all other options.

Re: Cello – High Level C

#22
post #14

Just my opinion, don't mean to be inflammatory, but if the user has to know and manually manage stack vs heap objects, then I wouldn't call it "High Level" language.

That raises a question, would you call C# a "High Level" language?

In C# it's more relevant to understand semantics (ref/value type) than allocation details (unless you actually care about low level details for performance/interop)

Re: Cello – High Level C

#23
post #5

Earlier quoted context omitted.

Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

> Rust is actually more optimized than C....

I think what you mean is that current Rust _implementations_ optimize better than current C _implementations_. There's no reason a C99 compiler can't do those optimizations.

Re: Cello – High Level C

#24

Earlier quoted context omitted.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

> Rust is actually more optimized than C.... I think what you mean is that current Rust _implementations_ optimize better than current C _implementations_. There's no reason a C99 compiler can't do those optimizations.

>There's no reason a C99 compiler can't do those optimizations.

No, there actually is, the C standard says structs have to be laid out in memory in the same order they're written and C has much weaker aliasing rules.

Re: Cello – High Level C

#25
post #5

Earlier quoted context omitted.

Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

> and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints,

I think that's temporarily turned off because emitting noalias attributes so much exposed some llvm bug. See: https://github.com/rust-lang/rust/issues/54878

In the long run though, yeah that is an inherent optimizability advantage of Rust vs. C.

Re: Cello – High Level C

#26
post #14

Just my opinion, don't mean to be inflammatory, but if the user has to know and manually manage stack vs heap objects, then I wouldn't call it "High Level" language.

That raises a question, would you call C# a "High Level" language?

I'd say the fact that structs are stack-allocated, and you can slip right through years of development without even knowing that fact... yeah, it's pretty high-level. C# doesn't have `malloc`. .Net apps are managed, so all of those low-level things one has to/gets to do are abstracted away.

Re: Cello – High Level C

#27
post #5

Earlier quoted context omitted.

Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. As the creator says, it’s not for production use. If I’m doing a side project, I’d give this a serious look.

> Speaking for myself, I’ve never found C++’s complexity appealing, and it only seems to be getting worse over the last 20 years. True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing perf…

'just use rust' is like some 2010s advice everyone's moved on to ATS now

Re: Cello – High Level C

#29

Seen this posted here years ago. Now as then, my gut feeling is that anyone doing serious work in C would never use something like this-- I feel like the fine grained low level control is exactly the reason they chose C in the first place, and they're not looking to escape from it or they would just choose a different language.

Not only that, but last I looked into this library's code there was a lot of undefined behavior and general sloppiness that goes against good C practices, eg. ignoring errors, casting all types to void * literally all the time or treating char VLAs as structs without regard for alignment.

My sympathy and respect to the author, but they did not appear learn C well before trying to "fix" it. It is kind of irresponsible, I think, to say it "aims to be production ready" and write it up as something other C neophytes may be interested in with some of these issues.

Re: Cello – High Level C

#30
This isn't a library, it's a sort-of-a-modification of C, it seems.

Well, for a non-C language with high-level abstractions that lets me use C code relatively seamlessly - I'm content with C++. Many complain about its complexity, but you can actually avoid a lot of that complexity in _your_ code using facilities with complex implementation but relatively easy use.

Post reply on HN