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

141–150 of 170 posts

Re: Switching to C over 'Modern' Programming Languages

#141

Post by pjmlp »

cozzyd wrote: post #137
pjmlp wrote: post #128

Earlier quoted context omitted.

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

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, only in portability, and that I could get from C++ anyway.

Re: Switching to C over 'Modern' Programming Languages

#142

Post by xedrac »

maccard wrote: post #34
spoiler wrote: post #28

Earlier quoted context omitted.

> 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? It sounds to me like they keep learning languages with the same illusions and failing to take any lessons between their language exploration escapades. All programming languages suck. It's just about finding the one that sucks the least for you (or your project/business). They m…

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.

Re: Switching to C over 'Modern' Programming Languages

#143

Post by xedrac »

flohofwoe wrote: post #63
weinzierl wrote: post #44

Earlier quoted context omitted.

"Rust forces me to think a little bit more [..]" My reaction to that has always been that it forces us to think about the things we would have had to think anyways if we wanted to create reasonably reliable and secure software. So in the end if saves work, even if it doesn't appear like that at first.

The other side of the medal (especially for game development), is that in the higher level parts of game code you need quick turnaround times for experimentation and tweaking, and most of that code won't even make it into the final product (so all the upfront time you spent thinking about proper architecture and ownership details is wasted up there). The traditional solution is to have different languages for differe…

I really like Rust, but it feels a bit rigid for game programming. I'd probably still use it, because Bevy, but I'd definitely push a lot of logic into a scripting language.

Re: Switching to C over 'Modern' Programming Languages

#144

Post by flohofwoe »

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…

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 used for type punning break in C++ for instance - it's good that C++ now offers a 'proper' alternative though).

It's pretty much an illusion that any non-trivial C or C++ program can be entirely standard compliant, it always depends on the specific compilers it has been tested with - which is still a better situation than Rust, which only has a single implementation (so far).

Re: Switching to C over 'Modern' Programming Languages

#145

Post by flohofwoe »

xigoi wrote: post #133
coldtea wrote: post #73

Earlier quoted context omitted.

> The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change it to a longer string. But then how do I store the buffer size? As a C programmer shouldn't you have a library ab…

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.

Re: Switching to C over 'Modern' Programming Languages

#146

Post by [deleted] »

SAI_Peregrinus wrote: post #130
flohofwoe wrote: post #85

Earlier quoted context omitted.

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 li…

[deleted]

Re: Switching to C over 'Modern' Programming Languages

#147

Post by flohofwoe »

kaba0 wrote: post #89
coldtea wrote: post #86

Earlier quoted context omitted.

> It's funny how both C and LISP programmers seem to suffer from NIH to the point that they'll roll their own just for the heck of it rather than to first see if there is a library that they can use. Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regar…

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 or performance, but never both.

Re: Switching to C over 'Modern' Programming Languages

#148

Post by flohofwoe »

shrimp_emoji wrote: post #113
tialaramex wrote: post #104

Earlier quoted context omitted.

Linux isn't written in standard C. Not only does it not accept C's aliasing rules (hence the kernel is compiled with them disabled, which the standard doesn't offer), it doesn't even accept the memory model, because it had its own memory model first and it likes that one better. As a result to some extent GCC and Clang are also compilers for some sort of "Linux C" which is strongly reminiscent of the ISO standard lan…

I'll just leave this here: https://lkml.org/lkml/2018/6/5/769 ;p And maybe this: https://dl.acm.org/doi/10.1145/3477113.3487274

Unions for type punning is actually entirely valid in C, it's only UB in C++.

(I agree though that the C standard isn't actually relevant in the real world, most C compilers treat it more or less as a 'suggestion', unless enforced with options like '-pedantic')

Re: Switching to C over 'Modern' Programming Languages

#149

Post by flohofwoe »

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…

IMHO a 'rusty C' wouldn't need to cover the entire memory safety feature set that Rust provides, it just needs to be 'close enough' and otherwise warn in areas where the compiler isn't entirely sure. It can also do some checks at runtime at the cost of a slight performance hit (but again, in old C tradition this should be controllable by compile options).

Re: Switching to C over 'Modern' Programming Languages

#150

Post by flohofwoe »

schemescape wrote: post #135
weinzierl wrote: post #116

Earlier quoted context omitted.

I wish there was a language that is to JavaScript/TypeScript/Python/Lua what Rust is to C++/C/Java.

Do you mean like a scripting language that is brand new and doesn’t have a ton of historical warts?

I guess AssemblyScript would fit that requirement. It's essentially TypeScript without the historical Javascript compatibility warts:

https://www.assemblyscript.org/introduction.html

Post reply on HN