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

121–130 of 170 posts

Re: Switching to C over 'Modern' Programming Languages

#121

Post by oconnor663 »

camgunz wrote: post #90
flohofwoe wrote: post #32

Earlier quoted context omitted.

I'm a programmer since the early 90's, but I have seen this problem only ever with Rust so far (where people are eager to learn something new, pick Rust, and then quickly get jaded - case in point, that's also me - I learned enough Rust to write a home computer emulator but in the process realised that it is not the right language for me, even though it should be from its feature set). It feels a bit like a speed run…

> 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 for this restriction.

- Even simple integer assignment isn't simple when an integer is shared between threads. Atomic orderings are hilariously complicated.

I worry that a lot of people who find delight in C just...aren't aware of these rules? Or maybe aren't consistently aware? Or maybe are aware but think that some violations are benign?

Re: Switching to C over 'Modern' Programming Languages

#122

Post by nayuki »

> The first language I properly learned was C in first year of my engineering degree. [...] My experience in the class solidified my belief that programming was what I wanted to do and forged a bond with the C language that I didn’t realize until now.

I am highly skeptical that the author understands the full ramifications of undefined behavior, dangling pointers, platform-dependent integer sizes, and the myriad sharp edges of the C programming language.

I don't disagree that, for example, Rust has a heavy syntax. But those exist for a reason. Those are the result of hard-earned lessons from phenomena like double-free (see ownership) and duck-typed templates in C++ (see traits).

Re: Switching to C over 'Modern' Programming Languages

#123

Post by agalunar »

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…

Small typo correction for anyone trying to search or learn more about the term: it's "provenance", not "providence".

Re: Switching to C over 'Modern' Programming Languages

#124

Post by oconnor663 »

agalunar wrote: post #123
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…

Small typo correction for anyone trying to search or learn more about the term: it's "provenance", not "providence".

Ha woops. My mind is in Rhode Island :)

Re: Switching to C over 'Modern' Programming Languages

#125

Post by nayuki »

Brian_K_White wrote: post #106
chongli wrote: post #66

Earlier quoted context omitted.

If you’re trying to understand the behaviour of the computer then all of the layers of abstraction matter, right down to the logic gates. Spectre and Meltdown proved that software developers can’t just “trust the CPU to do the right thing.” Besides the issue of security, performance is also a thing. If you’re trying to squeeze every last cycle out of your program then you need to understand CPU cache hierarchies at t…

Child, assemler mnemonic representations of opcodes are not hiding anything. You could make the same, useless, argument about the raw binary. If you looked at an executable you are still actually only looking at a transcoded representation in ascii in an editor. The cpu doesn't actually know what 0A is, those are glyphs for numbers and letters in a human language. Assembler mnemonics are not materially different, and…

> assemler mnemonic representations of opcodes are not hiding anything

They do hide things. There are often multiple ways to encode a line of assembly into machine code. For example on x86, JMP can take an 8-, 16-, or 32-bit displacement, and the assembler will usually select the shortest encodable variant. Some instructions have a shorter variant for certain registers, like ADD $1, %eax. You add useless REX prefixes.

Re: Switching to C over 'Modern' Programming Languages

#126

Post by pjmlp »

jacquesm wrote: post #74
flohofwoe wrote: post #59

Earlier quoted context omitted.

> when everyone was coding assembly.. This was before my time, but I think it's a common misconception (only true for operating system development). When C was created, there was already Lisp, Cobol, Fortran, Algol, Simula, BASIC... and SmallTalk and Prolog were just around the corner - and most of those are much higher level than C).

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.

There were enough languages for systems programming outside Bell Labs, all the way back to 1958.

It is a urban myth that C was the first one, usually pushed by naturally UNIX folks.

JOVIAL, ESPOL, NEWP, PL/I, PL/S, PL.8, PL/M, Bliss, Mesa, Modula-2, VMS Basic, VMS Pascal,...

Re: Switching to C over 'Modern' Programming Languages

#127

Post by oconnor663 »

lionkor wrote: post #30
hnarn wrote: post #16

Is this becoming a thing now (or maybe it was always a thing), where a language, like Rust, has become popular enough that instead of everyone talking about learning it, they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist? Rust exists for a reason, and it solves specific problems. That’s the “magic”, just like any abstraction in any…

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 (probably?) generic enums like Option and Result

- thread safety traits like Send and Sync

- closures, and closure traits like FnOnce

Of course yes, you can have "safe C" without async, and Rust 1.0 shipped without async. But I think it's notable that The Book doesn't teach async. Most of the things The Book teaches are actually necessary for memory safety to work.

Re: Switching to C over 'Modern' Programming Languages

#128

Post by pjmlp »

cozzyd wrote: post #112
kaba0 wrote: post #107

Earlier quoted context omitted.

So your answer is “because they are not C”…? What does language complexity has to do with anything? It will get compiled down to machine code, and both can be and are used for embedded. They occupy the exact same low-level niche as C, hell, they may be even more level as they can also do things like SIMD. Linux kernel is C because Linus doesn’t like C++, it’s that easy. And usually no, why would you use multiple lang…

It is quite difficult to write idiomatic C++ without memory allocation, for one, which is often a requirement for embedded code or any high-availability code that is not allowed to have memory fragmentation. Sure, it's possible (you can write C in C++, for the most part, and to its credit, C++ has placement new). But many of C++'s niceties require memory allocation, making much of its value-add over C questionable.

It super easy, we did it all the time back in the MS-DOS days.

Re: Switching to C over 'Modern' Programming Languages

#129

Post by pjmlp »

uranusjr wrote: post #72
flohofwoe wrote: post #59

Earlier quoted context omitted.

> when everyone was coding assembly.. This was before my time, but I think it's a common misconception (only true for operating system development). When C was created, there was already Lisp, Cobol, Fortran, Algol, Simula, BASIC... and SmallTalk and Prolog were just around the corner - and most of those are much higher level than C).

I think parent knows. A more accurate description would be everyone of the intended audience was writing assembly. Yes there are other languages of higher levels, but C was not invented to help their users. And since they are also not really what Rust targets either, IMO it’s reasonable to shorten it to drop the qualifier in this context.

C was invented in the context of porting UNIX, while the world outside Bell Labs used something else, that is all there is to it.

Re: Switching to C over 'Modern' Programming Languages

#130

Post by SAI_Peregrinus »

flohofwoe wrote: post #85
jacquesm wrote: post #75

Earlier quoted context omitted.

> C gives you enough rope to shoot yourself in the foot. If this was intended to illustrate the unexpected consequences of undefined behavior it succeeded remarkably well!

Undefined Behaviour was a very late 'addition' to C, it only became necessary when C was standardised around 1990. And only after two more decades passed, UB became an actual problem when compiler vendors decided that it's fine to exploit it for optimization tricks.

> UB became an actual problem when compiler vendors decided that it's fine to exploit it for optimization tricks.

Section 4. Conformance says "A strictly conforming program shall only use those features of the language and library specified in this International Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any implementation limit."

Compilers are not allowed to produce output dependent on UB for strictly conforming ISO C programs, they must optimize those statements out. Treating UB as impossible is required for ISO C. It's NOT required for GNU C, or Clang C, or Microsoft Visual C, but they usually do so anyway (even though they're not compiling strictly conforming ISO C programs).

Post reply on HN