Comment by winter_blue | Hacker News Reader

Comment by winter_blue | Hacker News Reader

I think our goal should be to develop even better programming languages that can express high-level concepts succinctly, and that provide even larger sets of compile-time guarantees (e.g. static typing).

I don't see the benefit in writing anything that doesn't need to be super-optimized in assembly language. Compilers are so good at optimizing right now that assembly is only justified for very small pieces of code that for example need to use special new CPU instructions (for e.g. in video decoding), or for particular segments of code that a profiler shows that the compiler can't optimize well enough.

Assembly language is hard to write, read, understand, and reason about. It shares the same memory model as C, with all its flaws. There is nothing impressive about this. It's like someone saying they built a house with their bare hands without using any machines or technology -- machines and modern technology could have helped them build a house faster, and that was of better quality.

Hand-written assembly is still the king when it comes to maximising CPU performance. You can see that most clearly on older machines, but the potential is still there on newer machines too. I'd suggest that there's a chance of a small resurgence in assembly after Moore's Law has truly bitten the dust.

Also, despite being very verbose, it's actually very easy to reason about. That's because you've removed all the layers of abstraction found with higher-level languages that are involved in translating source code to machine code. In assembly, your computer has to run the algorithms in the way you designed them, as it's necessary to spell out in exact detail how the algorithms should run. There's still layers of abstraction available through subroutines and macros, as well as comments for describing what the code does. The issue with assembly isn't with clarity per se, it's with portability and verboseness. Every part of the program has to be written out in painstaking detail, and the work involved in porting to a different architecture is much more than with languages like C.

> assembly is only justified for very small pieces of code

It's also justified if you're doing a side project mostly for fun and you like writing assembly.

If you were a manager or executive and you found out your employee had implemented a new project in assembly language, it really might be reasonable for you to be dismayed at that choice. But that's not the situation here. At all.

Actually Assembly usually does what I mean, instead of the UB pulllig rug under my feet tricks of C optimizers.

Even outside of UB and just in terms of implicit actions, I've also been bitten by destructors/finalizers. They can especially cause mysterious problems if they invoke any synchronization magic (join a thread, exchange state through a pipe/FIFO, acquire locks, etc.).

Your hardware might still pull the rug from under you with caches, prefetching, NUMA, out-of-order execution, speculative execution and other stuff.

True, but those things are usually easier to track down, than having them and C's UB on top.

These will only make the program run slower, they wont make it produce wrong results, create heisenbugs or even prohibit from running it.

The ability to tradeoff productivity for more control over the program is valuable in certain situations. The only problem I see with programming directly in assembly is that it's not compatible with different architectures. Perhaps someone should make a proper highlevel assembler similar to LLVM IR but with a stable instruction set that runs on several architectures.

Reply on news.ycombinator.com