Live data from Hacker News

A “Better C” Benchmark

zserge.com

151–160 of 192 posts

Re: A “Better C” Benchmark

#151
>They often complain the syntax is unclear and requires paying attention to details.

Attention to detail comes with the territory for programming roles. People who can't or don't want to pay attention to details are not fit to be programmers. We are working with precise binary digital machines, FFS. I sometimes find this attitude among students of my training courses - the misconception "computer, do what I mean, not what I say". Obviously such students don't do well in my course or in their career.

Re: A “Better C” Benchmark

#154
post #126

Earlier quoted context omitted.

Within a single compilation unit, and only in this most trivial case.

Here's an example of a much more complex case that is detected: https://issues.dlang.org/show_bug.cgi?id=21745

Yes, sorry if my comment isn't clear. D is very capable in this regard. While gcc with C/C++ code will spot a few trivial cases... including the one in the example above.

Re: A “Better C” Benchmark

#155
post #101

Earlier quoted context omitted.

I originally wrote a slide titled "D as Better C", and since I was in München at the time, it suddenly morphed into "Das Better C" and so the pun was born. In my head it is always said with a German accent.

If I was the marketing manager of D I would turned this "pun" into Super Hype. And yes this got me interested in D. I always knew of its existence but for some reason I never really looked into it.

Try it out, I’m thoroughly enjoying learning it at the moment and it really does feel like “better C”. The only thing I dislike is that the official docs are so thorough that they’re not very approachable to a novice (but much appreciated once you grok D’s features). I’ve found this book to be a better programmer’s introduction with lots of useful examples https://www.packtpub.com/product/d-cookbook/9781783287215

Re: A “Better C” Benchmark

#156
post #65

Earlier quoted context omitted.

Unsophisticated engineering solutions are not always the best. Modern CPUs are monstrously complex, for example. Modern airliners are incredibly complex. Simple solutions would be woefully uncompetitive. In the domain of programming languages, minimalistic low-level languages like assembly, C, and Forth, tend to be unsafe. They enable categories of serious bugs that never occur in safe languages. Modern garbage colle…

> Modern CPUs are monstrously complex, for example. But not all of that complexity is good. For example, things like branch-prediction vulnerabilities exist as a result of that complexity, which makes it extremely difficult to reason about the entire system and predict which interacting systems might lead to security issues. And it looks as if some of the complexity of the x86_64 instruction set is a liability with r…

> And it looks as if some of the complexity of the x86_64 instruction set is a liability with respect to performance compared to "simpler" instruction sets like ARM.

I don't think any of the issues with Intel's x86-64 chips are due to the instruction-set, they're due to the chips' internal architectures. ARM CPUs are by no means 'safe by nature'.

> the more that I write, the more that I wonder if some of that complexity is due to unsolved design problems in the core of the language

> Rust sometimes feels like a language which is missing that one key piece which would keep all of this complexity under control.

I'm reminded of a quote [0] from Bjarne Stroustrup, creator of C++:

> Within C++, there is a much smaller and cleaner language struggling to get out.

[0] https://en.wikiquote.org/wiki/Bjarne_Stroustrup

Re: A “Better C” Benchmark

#157
I am really surprised that D's --betterC subset (or just D proper) wasn't even tested, considering that's exactly what it is called and would likely outrank a good bit of everything else on the list.

Re: A “Better C” Benchmark

#158
post #10

I threw together a D Programming language glob-grep based off of the Zig version the author posted, if anyone is curious: https://gist.github.com/aruthane/005c6c48f0deb9c4bfc83bc75e0...

Great work! Really hope the author decides to run and see the performance in comparison.
Post reply on HN