Hacker News Reader

Comment by watermelon0 | Hacker News Reader

According to TechEmpower benchmark, C# and Java perform better in some tasks than C/C++ [1]

Even in categories where C/C++ are more performant, other languages are not that far behind.

If at all possible, we should not use memory unsafe languages for anything, especially something exposed as a server. No mater how careful you are, and with all the tooling available, majority of exploits in popular software happen due to memory unsafe languages.

[1] https://www.techempower.com/benchmarks/#section=data-r20&hw=...

View on HN

Benchmarks are useless if you don't understand what it is you're measuring. A contrived "Hello world" benchmark tells you nothing because your bottleneck is in the system calls, which has nothing to do with what framework you use. If you run a web service that requires a compute or memory intensive task, like a game server physics engine, or multimedia streaming, or anything that requires large-scale postprocessing, you're going to heavily rely on C or C++ based libraries to do the heavy lifting.

People like you pointed to benchmarks in the past and said the exact opposite. It is sad that any kind of reasoning stops at some benchmarks

Memory safety issues are exaggerated. It's definitely harder to keep big, complex software memory sanitised, but it's not something completely insurmountable.

You use C judiciously on the most performance demanding tasks, while trying to bring the overall task itself closer to some simple algorithm, on which you can later throw heavy verification, like formal verification, valgrind it to death, fuzzing etc.

The current wave of "new age" computer languages like Koltin, Go, Rust have a very noisy activist userbase which tend to extol some very simple, obvious things as ultimate virtues.

Memory safety issues are bugs. Do you know any programmer that does not occasionally create bugs? Don't forget tight schedules, low budgets, ...

Also rust is just what you propose that - a programming language integrated with heavy verification of safeness built-in. Because occasionally someone writes c code without using all available tools to verify the code it is better to have it built in.

> Do you know any programmer that does not occasionally create bugs? Don't forget tight schedules, low budgets, ...

Do not run programming in C on tight schedules, and low budgets. It needs tact, and understanding.

“Have you simply considered not having bugs” isn’t a useful strategy though.

Memory safety is not an issue if you actually learn to take advantage of the C toolchain. I've caught memory leaks and buffer overflows to great effect just by using Valgrind and ASAN. And for most applications, you can limit the attack surface by only writing C for the performance-sensitive areas and using FFI to call into those routines. As a bonus, it becomes much easier to unit test for logical corner cases.

This just isn’t true in practice. Can you point to a popular c project that’s accomplished this? I bet there are a few tiny ones that make such claims but haven’t received scrutiny.

IIUC, it needs extensive code coverage and it's even difficult for library (the lws case).

It helps 40 years of wasted advocacy how good programmers never do errors with C.

I can´t wait for governments to make security exploits liable, then lets see how much software will still be written in C, or derived languages.

Reply on news.ycombinator.com