Hacker News Reader

Comment by m0th87 | Hacker News Reader

> Difficulty is relative. If you don't study modern C idioms your C code will be crap. Same goes for Rust.

That's not a valid argument for why better tooling can't help alleviate some of the difficulty.

> Honestly using higher-level languages is the same mentality as taking a pill to magically lose weight. It's quick, but detrimental (to programmers ability) in long term.

If that were true, the most effective programmers would only code on assembly.

> Programming becomes easy but in the long term most people forget how algorithms and data structures work, in addition to cache mechanisms and other optimizations.

Why would higher level languages obviate knowledge of any of these things? If anything, I think it would help by reducing "noise" from incidental complexity; e.g. ownership in C vs Rust.

View on HN

>If that were true, the most effective programmers would only code on assembly.

No, because C is as fast as hand-coded assembly in most of the cases. The same can't be said of any high level language in comparison to C (save for C++ and Fortran).

> The same can't be said of any high level language

Rust is basically a metal level systems language. Just like C. It has a nicer type system but it compiles to more or less the same thing in the end. Unless you make an error such as using freed memory, in which case it doesn't compile while the equivalent C code would often compile to a very high performance foot-gun. The Rust safety is paid for, for the most part, at compile time unlike the usual high level languages like java/C#/python/... which pay for it at runtime.

> No, because C is as fast as hand-coded assembly in most of the cases.

Most hand-coded assembly is pretty slow. C isn't any pinnacle of performance either.

C programs are compiled to some non-existent abstract machine that ignores the real variations in memory architecture and CPU implementations. The compiled binary can't adapt at runtime.

I don't know of any C implementations that take advantage of runtime information for optimization purposes. So you end up with generated code with a lot of redundant computation, tests, branches and pointer dereferences (such as function pointer dereference that always refers to same address), just because they might be necessary with some input -- input that wasn't the case this time.

A single mispredicted branch is expensive. Say branch mispredict takes 15 cycles. That's enough to do up to 480 (32*15) 32-bit floating point operations on a single core. Ignoring runtime information takes us pretty far from anything you can call optimal code.

The current crop of compilers are also pretty bad at vectorizing anything complicated. Those cases it can be pretty trivial to beat the compiler by 2-10x, in some cases even 40x+ if your vectorization can also eliminate a lot of unpredictable branches.

Reply on news.ycombinator.com