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

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

361–370 of 382 posts

Re: C’s Biggest Mistake (2009)

#361

Post by tonyarkles »

the_hoser wrote: post #235
raverbashing wrote: post #225

Earlier quoted context omitted.

By number of new projects using it (without counting legacy code) Nobody would do a project in C today with Go/Rust/C++ etc unless it's for a very specific situation

Careful with generalizations like that. You're forgetting the most important reason anyone uses a language: It's the one they know. A C programmer isn't automatically going to switch to Rust for new projects that they would use C for, unless their goal is to use Rust.

Lol C programmer since 1994 here... just started a Rust project with the specific goal of learning Rust. The project itself is just to scratch my own itch. I’d honestly probably write it in Python if I didn’t want to see what Rust was all about :)

Re: C’s Biggest Mistake (2009)

#362

Post by Reelin »

jschwartzi wrote: post #198
Reelin wrote: post #84

Earlier quoted context omitted.

Isn't much of the undefined behavior in C that people love to complain about intentionally left in the standard for the purpose of optimization? Similarly, bounds checks are necessary in insecure contexts (ie most places) but you probably don't want them slowing down (for example) an MD simulation. Edit: But to be clear, C really ought to have first class arrays. If you truly don't want bounds checks in a specific sc…

UB has nothing to do with optimization. It's about working around the differences between all the platforms that a C program might need to be compiled for. UB covers things like the layout of a signed integer(might be two's compliment, or it might not). It's about letting the platform or compiler dictate what the program does in the rare case where the program does something that might result in different behavior on…

> UB has nothing to do with optimization.

Other commenters already responded to this, but I thought I'd link an article I came across a while back that gives a concrete and easy to understand example of how UB can be leveraged for optimization by modern compilers. (https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...)

Re: C’s Biggest Mistake (2009)

#363

Post by jkoudys »

johnisgood wrote: post #181
jkoudys wrote: post #174

Earlier quoted context omitted.

One way rust's just a different tool for a different job, is it really doesn't optimize for knowing everything that's happening inside someone else's code. It's a great example of the difference in procedural vs functional programming, where in rust you mostly just care what your function args are and what it returns. Nothing wrong with learning multiple languages, of course. C was my first professional language, and…

Sure. I code in C, Go, OCaml, Ada/SPARK, Factor (Forth-like, Lisp-y), Common Lisp (rarely), and Erlang (moving to Elixir). But I was responding to "C code is being replaced by Rust fast.".

Ah. If anything, the whole "rust as better than C for everything" thing is starting to hurt its reputation, regardless of veracity. People get so focused on its use in perf-critical applications they ignore its other strengths. eg I've never replaced C code with it, but we redid our whole PHP backend as a rust app.

Re: C’s Biggest Mistake (2009)

#364

Post by jkoudys »

johnisgood wrote: post #181
jkoudys wrote: post #174

Earlier quoted context omitted.

One way rust's just a different tool for a different job, is it really doesn't optimize for knowing everything that's happening inside someone else's code. It's a great example of the difference in procedural vs functional programming, where in rust you mostly just care what your function args are and what it returns. Nothing wrong with learning multiple languages, of course. C was my first professional language, and…

Sure. I code in C, Go, OCaml, Ada/SPARK, Factor (Forth-like, Lisp-y), Common Lisp (rarely), and Erlang (moving to Elixir). But I was responding to "C code is being replaced by Rust fast.".

Ah. If anything, the whole "rust as better than C for everything" thing is starting to hurt its reputation, regardless of veracity. People get so focused on its use in perf-critical applications they ignore its other strengths. eg I've never replaced C code with it, but we redid our whole PHP backend as a rust app, because it's great for rigidly defined business rules too.

Re: C’s Biggest Mistake (2009)

#365

Post by YeGoblynQueenne »

hanche wrote: post #343
YeGoblynQueenne wrote: post #332

Earlier quoted context omitted.

Many apologies - I was not being sarcastic and I'm sorry that this is how my comment came across. As chongli says I'm a native speaker of Greek and I really didn't know how "eso" is pronounced by native English speakers. I've lived for 15 years in the UK and I'm still surprised to hear how people pronounce the more obscure words in their language (some of which come from Greek).

Oops, sorry, I apologise for the mistake. I have seen too much bad behaviour on the 'net, so naturally I assumed the worst. It's a valuable lesson at the modest cost of a few karma points. (I guess I violated HN guidelines too, there. Good thing I don't have the power to downvote yet. I might have done so, and never discovered my mistake.)

Hey, it's OK, no need to apologise. Sorry I caused you to be downvoted.

Re: C’s Biggest Mistake (2009)

#366

Post by ncmncm »

carlmr wrote: post #88
ncmncm wrote: post #42

Earlier quoted context omitted.

It does, however, have integer overflow, in release mode. So if you do code a conversion, you can end up with a value different from the source.

But that's because Rust designs for zero cost abstractions in release mode. Overflow checking is not zero cost, so it's only enabled in debug mode, which is the maximum safety possible here while keeping it zero cost at (release) runtime. Without dependent types or something similar I don't know if it would be possible to check bounds.

Yes, there are reasons for it.

Re: C’s Biggest Mistake (2009)

#367

Post by 59nadir »

pjmlp wrote: post #309
IshKebab wrote: post #259

Earlier quoted context omitted.

Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

Cyclone, ATS, Checked C, Ada/SPARK.

Footnote: With Ada/SPARK being much more battle-tested and ATS being a much more flexible & complete solution. Though I wouldn't exactly recommend ATS in terms of learning curve.

Re: C’s Biggest Mistake (2009)

#368

Post by harry8 »

EdSchouten wrote: post #302
harry8 wrote: post #293

typedef struct fat_ptr_t { size_t size; void * start; } fat_ptr_t; extern void foo(fat_ptr_t a); if it's a good idea to use a fat pointer, why do we need new syntax to sell it? What am I missing here?

> What am I missing here? - A concise syntax for declaring, accessing and mutating them. Dealing with lists is such a common thing in programming languages, that it's simply crazy to not have a proper syntax for them. - Generics/templating, so that you can use concrete types instead of 'void *'. Having that prevents mistakes and also tends to make code self-documenting. "If it's such a good idea to use a safety belt…

There are lots of places you can make C's syntax more concise. What do you get for changing the syntax here? Why is it worth it?

void* was merely for example. Yes make it typed when you use it in your C code. Also used accessor functions to wrap array index so you can switch on & off a macro for bounds checking, absolutely do that. Does new syntax change anything if you do these things?

Don't much care for the seatbelt analogy there, remove your working, properly fitted seatbelts with our red ones because they're easier to see? These kinds of analogies always break down. Especially car analogies for programming and yes, I use them too.

Re: C’s Biggest Mistake (2009)

#369

Post by boomlinde »

WalterBright wrote: post #15

Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.

> C is finished if it doesn't address the buffer overflow problem

Assuming that it is so: when? It seems that C—despite all its shortcomings—remains a very popular language in some problem domains. For some platforms it seems like it's really the only performant HLL option.

Re: C’s Biggest Mistake (2009)

#370

Post by hanche »

YeGoblynQueenne wrote: post #365
hanche wrote: post #343

Earlier quoted context omitted.

Oops, sorry, I apologise for the mistake. I have seen too much bad behaviour on the 'net, so naturally I assumed the worst. It's a valuable lesson at the modest cost of a few karma points. (I guess I violated HN guidelines too, there. Good thing I don't have the power to downvote yet. I might have done so, and never discovered my mistake.)

Hey, it's OK, no need to apologise. Sorry I caused you to be downvoted.

You didn't cause the downvote. Really. But in any case, there are more important things in the world than HN karma. And keep up your Greek lessons. That's one language I'd love to learn, if only I had the time. But I understand it is fiendishly difficult for non-native speakers. (Source: Greek to Me: Adventures of the Comma Queen by Mary Norris.)
Post reply on HN