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

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

131–140 of 388 posts

Re: The case against a C alternative

#131

Post by jimbob45 »

jiggawatts wrote: post #60
woodruffw wrote: post #40

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

What did you mean when you said C hashtables can’t be generic? Is the (void*) not an adequate solution?

Re: The case against a C alternative

#132

Post by 1vuio0pswjnm7 »

Hypothetical: I need a small, fast systems language to use for writing small, portable programs.^1 Using the language the system is written in would be ideal.

1. In other words, the size of a "hello world" program matters, as does the storage space and time I need for the compiler toolchain and libraries.

What language should I use. I am not interested in writing large, complex programs.

Re: The case against a C alternative

#133

Post by pkrumins »

didip wrote: post #117
pkrumins wrote: post #92

I will never use any other language for server apps than C. C is a language for getting things done. It's finished and final. It will not change. There will be no new surprises, no new operators, and no unpublished packages. There are just source files. Write, compile, ship, repeat. You used it in 1990 to ship, you used it in 2000 to ship, you used it in 2010 to ship, you used in 2020 to ship, and you will use it in…

Wait… really? Not even considering C++ Boost, Go, or Rust?

No. I like when nothing changes. C is perfect. All my code from 2000 still works.

Re: The case against a C alternative

#134

Post by woodruffw »

jimbob45 wrote: post #131
jiggawatts wrote: post #60

Earlier quoted context omitted.

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

What did you mean when you said C hashtables can’t be generic? Is the (void*) not an adequate solution?

It depends on what you're trying to do. In general, marshaling everything through void pointers is possible, but it'll cost you in terms of both bug surface (it's much easier to make mistakes when you've opted out of C's weak types) and performance (you now have at least one mandatory pointer indirection, which is especially egregious when your underlying value type is something simple like an integer).

Anything you can do in C++, you can do in C. But C++ compilers will generally optimize semantically equivalent code better than C compilers will, because C++ gives the compiler more freedom.

Re: The case against a C alternative

#135

Post by defen »

cmeacham98 wrote: post #110
defen wrote: post #79

Earlier quoted context omitted.

> But don't use "my current circumstances prevent me from using Rust" as an argument as an argument against Rust in general - which is what you're doing. First of all I'm just summarizing the article, I'm in no way arguing against people using Rust. The article itself argues against C alternatives, and explicitly describes Rust as a C++ alternative. So the article is not even arguing against Rust! If we can't agree o…

This is just trolling, you obviously were previously engaging in this thread under the premise that Rust is a C alternative.

Can you quote where I did that? Because I have no idea what you're talking about.

Re: The case against a C alternative

#136

Post by Asraelite »

cmeacham98 wrote: post #67
jiggawatts wrote: post #60

Earlier quoted context omitted.

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads?

Today, it's debatable, but if we're talking about programming languages for the future then the future is what's relevant. I don't think it will be long before 50+ thread CPUs are common. Multithreading won't be a nice-to-have feature, it will be a necessity.

Re: The case against a C alternative

#137

Post by AgentME »

bee_rider wrote: post #24
clysm wrote: post #13

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable. And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language ? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level…

You are the security engineer, so you certainly know better than me, but aren't those runtime mitigations aimed at malicious programs? Which is to say, even if a better-C was written that didn't allow people to write a program that would bump into those mitigations, the bad guys could still write their programs in assembly or C or whatever, right?

Sandboxing techniques can also be used for dealing with malicious programs, but most of those things listed are for programs to use to protect themselves, not to stop them from intentionally doing bad things.

Re: The case against a C alternative

#138

Post by lisper »

jsnell wrote: post #95
lisper wrote: post #72

Earlier quoted context omitted.

First, not all language safety features have to manifest themselves as run-time checks. A properly designed language will allow many safety checks to be done at compile-time. And second, would you really rather deal with security holes on an on-going basis? The problem with C is not that you can write unsafe code in it, it is that the design of the language -- and pointer aliasing in particular -- makes it impossible…

Bad example. There's nothing[0] you could put in the ellipsis to make that code valid, and both gcc and clang will warn about it (clang on defaults, gcc with -Wall). [0] Ok, I guess you could #define x something, but that's not interesting from a static analysis perspective.

Once upon a time you could do this:

int z[20];

x = z;

because arrays were formally equivalent to int*'s.

But apparently things have changed since the last time I looked.

Re: The case against a C alternative

#139

Post by lisper »

II2II wrote: post #129
lisper wrote: post #72

Earlier quoted context omitted.

First, not all language safety features have to manifest themselves as run-time checks. A properly designed language will allow many safety checks to be done at compile-time. And second, would you really rather deal with security holes on an on-going basis? The problem with C is not that you can write unsafe code in it, it is that the design of the language -- and pointer aliasing in particular -- makes it impossible…

I'm not here to defend C, but to point out a problem that many advocates make when they cherry pick examples of how their language is both safer and more performant than C. Simply put, that example is irrelevant when the size of the array is not known at compile time. The moment that you have a dynamically allocated array, you are either dropping safety (e.g. expecting the developer to perform bounds checks when nece…

> The moment that you have a dynamically allocated array, you are either dropping safety (e.g. expecting the developer to perform bounds checks when necessary) or performance (e.g. the compiler inserts bounds checks at runtime).

Yes, that's true. So? The original claim is that it is self-evident that this tradeoff should be resolved in favor of performance in the design of the language, and it just isn't (self-evident). If anything, it is self-evident to me that the tradeoff should be resolved in favor of safety in today's world.

Re: The case against a C alternative

#140

Post by cogman10 »

User23 wrote: post #130
cogman10 wrote: post #90

Earlier quoted context omitted.

> i might add the blind praise of garbage collection raised an eyebrow for me. Like it or not, a problem C has is that it's pretty much impossible to determine why a piece of memory is currently being retained. Tools like valgrind and jemalloc can give you good starting points but really can't point to issues where "This memory is being retained because of this linked list over here" Languages with GCs can, at any po…

You’re not wrong that aliasing presents serious practical problems for building an efficient object graph. The thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime[1]. The way I look at it, every C program has a bespoke garbage collector of variable quality. It’s fair to say the median is pretty dismal sure, but tooling does exist to tame that beast. I think there’s a wide open…

> he thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime

Agreed. And with my critique of the toolchain, I didn't mean to imply that C isn't a reasonable choice in many situations. But rather, holding up the C toolchain as a reason to pick C over an alternative isn't reasonable in my opinion.

In particular, because a lot of C alternatives piggy back on the C ecosystem by using LLVM as a backend. So you end up with a superset of tools. The C alternative ecosystem and the C ecosystem.

Pick C if it's all that's available. Pick it if you plan on distributing your app/lib onto that IBM RPG server. Pick it if your software is already written in C. Pick it if your software is a simple app that runs for 1 second then shuts down (and it isn't really mission critical). Pick it if memory safety isn't really a problem. Pick it if that ultra thin runtime is an absolute necessity. Pick it if you have a bunch of C devs that don't want to learn a new language.

But don't pick it because you are afraid new languages won't have something as good as valgrind or gdb. Any semi-popular language born in the last 20 years (that wasn't written yesterday) will almost certainly have better tooling than C.

Post reply on HN