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

Switching to C over 'Modern' Programming Languages

devtails.xyz

Post reply on HN
Print view View original

151–160 of 170 posts

Re: Switching to C over 'Modern' Programming Languages

#151

Post by flohofwoe »

Barrin92 wrote: post #50

Using a memory unsafe language in a situation where it's not strictly necessary is in my opinion not justifiable at all. It's the leading cause for security issues by some measures[1], incredibly hard to reason about and hard to debug. Honestly unless you have a really, really, good reason not to, use a managed language. If that isn't good enough and you want to be fancy use Rust and only if you've exhausted everythi…

The opposite it also true though: Using a memory safe language where it's not strictly necessary is not justifiable (e.g. Rust is essential for implementing a sandbox - for instance a WASM VM, but not for code running inside that sandbox - because the whole point of a sandbox is that it can run untrusted, unsafe code safely).

Re: Switching to C over 'Modern' Programming Languages

#152

Post by pjmlp »

flohofwoe wrote: post #145
xigoi wrote: post #133

Earlier quoted context omitted.

Okay, so you write your own string library. Now you'd like to do the same thing for resizable arrays, so you write a resizable array li… oops, you can't, because C doesn't have parametric types.

Preprocessor macros are an entirely valid tool in the C language toolbox, even if demonized by C++ coders.

Even Macro Assemblers from the MS-DOS and Amiga days are better than C pre-processor macros.

Re: Switching to C over 'Modern' Programming Languages

#153

Post by pjmlp »

flohofwoe wrote: post #147
kaba0 wrote: post #89

Earlier quoted context omitted.

What exactly is a problem with C++’s strings, or especially Rust’s? Everything you mentioned can be controlled as explicitly as you want. The only problem is C is simply not expressive enough to have proper abstractions like that.

I don't even know where to start with C++ stdlib string problems, but being mutable and doing a unique heap allocation (above a certain length - a behaviour which however isn't even standardized) are definitely at the top of the list. std::string_view would have been a good thing if it hadn't added another memory corruption foot gun. A universal string type is one of those things where you can either have convenience…

They are still better than str...() and mem...() all over the place, and all relevant C++ compilers have options to turn bounds checking on.

Re: Switching to C over 'Modern' Programming Languages

#154

Post by pjmlp »

flohofwoe wrote: post #83
jacquesm wrote: post #74

Earlier quoted context omitted.

Sure, but none of those were for systems programming which is squarely the domain that C was aimed at, case in point: the first thing that C was used to write was UNIX (before then it was BCPL and this was iirc before C even had structs which made that a very tricky job, once structs were in place it got a lot easier). Probably Don Hopkins has more knowledge about this.

> before C even had structs which made that a very tricky job... ...interesting that you mention that, I think that functions and structs are the essential 'core abstraction tools' that get you to at least 80% of any higher level abstractions that were invented since then, and this is exactly the reason why C is still quite popular. Its feature set is just enough to be considered a high level language which enables a…

C23 has lots of stuff into it, except improved safety.

Re: Switching to C over 'Modern' Programming Languages

#155

Post by lionkor »

oconnor663 wrote: post #127
lionkor wrote: post #30

Earlier quoted context omitted.

While I agree, I also have to say that Rust does a lot more than just solve some specific C and C++ issues. It doesnt solve all of them (e.g. logic errors, so if thats 90% of your issues you wont benefit too much), it repeats some design issues of C++ (massive complexity from the start, many ways to do the same thing), and implements a C-like unsafe{} language anyways. If Rust was just C but with strong typing, a bor…

> just C but with strong typing, a borrow checker and what would basically be super strong static analysis of pairing malloc() and free() Most of Rust's features interact in ways that aren't obvious. For example to get the basic memory safety guarantees that the borrow checker provides, you also need: - the "no mutable aliasing" rule - destructive move semantics and the Copy trait - generic containers like Mutex and…

It doesnt matter what The Book teaches - for example a majority of Rusts web-facing ecosystem uses some async, which means

1) tokio, which uses unsafe{}, and/or

2) async functions requiring all calling functions to also be async

So, really, you can't avoid it. The ecosystem is built on the idea of NIH, which is fine, if it wasnt for so many rust features you can abuse so heavily (e.g. macros to make your own language that I then have to learn).

There are a lot of issues with the complexity Rust brings.

Re: Switching to C over 'Modern' Programming Languages

#156

Post by maccard »

xedrac wrote: post #142
maccard wrote: post #34

Earlier quoted context omitted.

Disagree on c++. Even if you forego the significant improvements in the last decade then: RAII and templates make it worth not using C anymore. Having to use shoddy macros for a resizeable array is just unreasonable.

C++ is a monstrosity, but RAII is greatly missed when using C. I'm much more inclined to use Rust these days.

Agreed that it's a monstrosity, but the reality is that much of that monstrosity is hiding subtle background issues that exist in C that people don't talk about. look at the implementation of std::vector, and compare that against most of the home rolled macros that (dangerously) wrap calls to realloc, and tell me which one is the monstrosity! Personally, I'm glad someone else wrote vector and that I don't need to handle that.

Re: Switching to C over 'Modern' Programming Languages

#157

Post by xedrac »

maccard wrote: post #156
xedrac wrote: post #142

Earlier quoted context omitted.

C++ is a monstrosity, but RAII is greatly missed when using C. I'm much more inclined to use Rust these days.

Agreed that it's a monstrosity, but the reality is that much of that monstrosity is hiding subtle background issues that exist in C that people don't talk about. look at the implementation of std::vector, and compare that against most of the home rolled macros that (dangerously) wrap calls to realloc, and tell me which one is the monstrosity! Personally, I'm glad someone else wrote vector and that I don't need to han…

I agree. C is absolutely terrible to use for anything that's not trivial. It may have a simple spec, but you pay dearly for it in code complexity. Its abstraction capabilities are only marginally better than writing straight assembly.

Re: Switching to C over 'Modern' Programming Languages

#158

Post by cozzyd »

pjmlp wrote: post #141
cozzyd wrote: post #137

Earlier quoted context omitted.

right, but that was pre C++ niceties like the STL :).

C++ compilers shipped their own collections, for Borland compilers it was BIDS. The first version used preprocessor macro tricks for generatic code, basically what Go folks re-discovered with //go:generate, we already had it in 1992. BIDS 2.0 already used templates. It was exactly because even C++ for MS-DOS provided safer library than C, that I was never that into C. It wasn't better than TP in features and safety,…

That's fair! Perhaps I should amend to say that "current" idiomatic (almost got autocorrected to idiotic on my phone) c++ code is allocation heavy. Probably there exist suitable libraries I don't know about that basically implement the STL using predefined arenas for storage.

Re: Switching to C over 'Modern' Programming Languages

#159

Post by camgunz »

oconnor663 wrote: post #121
camgunz wrote: post #90

Earlier quoted context omitted.

> It feels a bit like a speed run of C++ I've felt that way too, and it's been enough to push me away even as I've tried to build things in Rust in earnest. Along the same lines, I've found it hard to say exactly why I like C and super dislike C++. I guess I have to say it's simplicity--like I won't argue C is by itself simple (integer promotion by itself is not simple) but it's definitely simpler than C++, and the s…

> everything is a number I don't think C consistently lives up to this principle: - In the memory model, even simple integers can hold "poison" values. - Pointers usually behave like integer addresses, but in the memory model they have "provenance" (edit: spelling), and they also have to follow "strict aliasing" rules. - Signed integer overflow is UB. We could ignore integer promotion rules most of the time, if not f…

Oh that's what I was nodding at with my "I wouldn't call C a simple language" comment. You are 100% correct. I assume--maybe wrongly but I don't think so--that the natural progression of the C programmer is:

- whoa cool everything is a number! Make that light blink, wipe that SDRAM chip, whiz bang!

- What the fuck is a torn read (insert any C gotcha in here)?! Everything is garbage!

- I know, I'll encapsulate "The right way to do things" in a library/new language.

- Never mind, I've decided to build websites (insert popular tech job here) for a living, but be super grouchy about it

The corollary to "I think Rust's complexity makes it impossible to delight me" is "I think C's brittleness makes it impossible to delight me." It has notes of innocence lost, nostalgia, a "simpler time", etc. Are those days gone forever, as the Dan say? Dunno.

Re: Switching to C over 'Modern' Programming Languages

#160

Post by camgunz »

flohofwoe wrote: post #144
oconnor663 wrote: post #121

Earlier quoted context omitted.

> everything is a number I don't think C consistently lives up to this principle: - In the memory model, even simple integers can hold "poison" values. - Pointers usually behave like integer addresses, but in the memory model they have "provenance" (edit: spelling), and they also have to follow "strict aliasing" rules. - Signed integer overflow is UB. We could ignore integer promotion rules most of the time, if not f…

We're very aware and try to shield ourselves somewhat with compiler options (eg. max warning level already goes a long way), sanitizers and analyzers (thankfully availability of such tools has improved dramatically with clang's ASAN, UBSAN, TSAN and the clang static analyzer). (and actually: yes, some rules are benign if the major compilers agree on the same non-standard behaviour, so far I have never seen unions use…

Yeah it is bonkers to me that people don't turn all the stuff on. There's a lot of help out there that is basically free. It's worth taking an hour or so to go through all the checks--if nothing else it'll probably make you wise to some new footguns.
Post reply on HN