C-for-all: Extending C with modern safety and productivity features • Hacker News Board

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

#121

Post by meed » Wed, Dec 04, 2019, 5:07 PM UTC

YAFUATMCWCIN

Yet Another Fucked Up Attempt To Make C What C Is Not

C is not “unsafe” as in “flawed”: it’s designed to fill certain gaps. Its syntactic stability through the decades - as well as its “minimalism” (for a lack of better word) - are among its most important features.

Personally I have been having an hard time trying to figure out why there’s some part of the industry that desperately tries to change what C is in a way or the other.

...but probably I’m just an old Valley fart. Apologies for the rant.

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

#122

Post by 0xdead » Wed, Dec 04, 2019, 5:28 PM UTC

quotemstr wrote: post #85

C with modern safety and productivity features is called "C++" and has been around for decades. I'm amazed at how much effort people will expend just to avoid the C++ boogeyman. No, writing C++ does not automatically make your code bloated. No, using C does not guarantee lean design. Plain C ought to be considered a legacy language and not used for new code. There is zero reason to prefer it over whatever style of C+…

> writing C++ does not automatically make your code bloated

Sorry, but it does.

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

#123

Post by 0xdead » Wed, Dec 04, 2019, 5:38 PM UTC

kyeb wrote: post #4

Could someone expand on why Rust "isn't a systems language"?

The language itself is pretty good for systems programming. It's the lack of tooling (as compared to C) that renders it unsuitable for any real world systems programming projects.

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

#124

Post by coldtea » Wed, Dec 04, 2019, 6:11 PM UTC

microcolonel wrote: post #84

coldtea wrote: post #72

Earlier quoted context omitted.

In which case you shouldn't paint one as the exceptional evil for doing the same thing, as is usually the case.

The CCP is exceptionally evil, they are conducting themselves like Nazi Germany.

China was actually a victim of the Axis powers, with a huge death toll, so this more than a little disrespectful...

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

#125

Post by noobermin » Wed, Dec 04, 2019, 6:31 PM UTC

The one thing I like in c for all seems to be (not sure) but generally every valid c program is a valid c-for-all program. People mentioning C2 seem to ignore that C2 is incompatible with C. Or perhaps I'm wrong on that.

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

#126

Post by microcolonel » Wed, Dec 04, 2019, 7:22 PM UTC

coldtea wrote: post #124

microcolonel wrote: post #84

Earlier quoted context omitted.

The CCP is exceptionally evil, they are conducting themselves like Nazi Germany.

China was actually a victim of the Axis powers, with a huge death toll, so this more than a little disrespectful...

Nothing about having the imperial Japanese rape, torture, and conduct live medical experiments of unspeakable horror on your people makes you immune from becoming like them. If anything, it is a great excuse for doing so.

And the victimization you're speaking of was conducted against the the people of Republic of China. The CCP is an abomination, and they make China everything the Chinese have any right to hate about the Japanese.

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

#127

Post by dnautics » Wed, Dec 04, 2019, 7:27 PM UTC

jacquesm wrote: post #110

dnautics wrote: post #49

Earlier quoted context omitted.

if that combination is interesting to you, this is what I'm working on (on the side from my main job): https://github.com/ityonemo/zigler

Oh, nice, I will definitely try that. Nifs in C are an eyesore and a risk, having more language options there is good and a clean integration like this is even better.

Just FYI I recommend waiting till I 0.1 it, which will definitely happen before end of January, when I'm giving a talk. I haven't tested that it works as a library yet, much less with elixir releases (it works self contained).

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

#128

Post by ilovecaching » Wed, Dec 04, 2019, 8:43 PM UTC

I would like to see C with just the borrow checker - nothing else. I assume someone has probably already done this, and I just don't know about it.

The primary advantage of C is that, and this just parphrasing a Linus Torvald's quote - it was developed at a time when computers weren't that powerful and so it's very close to assembly such that a proficient C programmer knows exactly what's going on under the hood.

I can't say the same for Rust or C++ which both spit out an enormous amount of code thanks to monomorphisation and all the other "zero cost" abstractions they employ.

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

#129

Post by juped » Wed, Dec 04, 2019, 8:55 PM UTC

Some interesting ideas here. However, C is being improved in an evolutionary fashion; the latest revision was C18 in 2018. I like languages like this (my favorite is D), but the only C successor language I use is C11 (this is what clang targets; C18 is an incremental minor update to C11 that only fixes errata).

    x = t.1; // extract 2nd tuple element (zero origin)

Zero-based indexing in a programming language is not necessarily a dealbreaker but is always a worrying sign about how hard the designer thought their design through. (This does not apply to the design of C, which does not have zero-based indexing; arrays are indexed by offset rather than "from zero".) These are structs with fewer names and less ceremony involved. Why would the first field be "field 0"?

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

#130

Post by kbenson » Wed, Dec 04, 2019, 8:56 PM UTC

coldtea wrote: post #73

kbenson wrote: post #26

Earlier quoted context omitted.

Just because the west also can't necessarily be trusted not to try to sneak exploits into sponsored projects (or through other means, such as a snail mail MITM) doesn't mean we shouldn't ask the question of other countries as well. Whataboutism is never the correct answer to a valid concern (in general. I'm not sure if there's much to worry about in this specific case or not).

> Whataboutism is never the correct answer to a valid concern I'd say it is. I puts the concern in perspective, and stops people from using it to paint the "enemy" (anybody that's not them/their government) as particularly evil for doing the same thing the other side does.

That doesn't make it the answer though, just something else that might be beneficial to mention.

As an answer it obscures whether the original question had merit and leaves it unanswered. As something that's included alongside an answer it is superior to an answer alone and to itself alone.

I agree whataboutism can be useful in causing people to reassess their perspective on a topic, but when used haphazardly it can obscure more than clarify (and has been used this way extensively in the past for this purpose).