3 ms·

This article makes a bunch of invalid (sometimes implicit) assumptions or claims: *A 20 yro language's design decisions don't make sense today because of the h

This article makes a bunch of invalid (sometimes implicit) assumptions or claims: *A 20 yro language's design decisions don't make sense today because of the hardware perf situation change.* 1. Most languages were not designed for optimal utilization of the specific hardware situation during their conception. 2. Even languages designed with performance in mind somehow are still incredibly general and flexible things. 3. The article itself shows that CPU hardware has been changing along a mostly predictable path for decades. Everyone knew Dennard scaling would end, even if you couldn't predict it to within the single year. Everyone saw CPU latency was decreasing much much faster than memory latency, already in the 1980s. -- * The main problem that we have today lies in utilizing the CPUs to their full potential.* This is _a_ main problem, not _the_ main problem: * There are other, specialized processing hardware (like GPUs). * There's computation happening elsewhere on the system, e.g. on disk controllers and NICs. * And actually, if you look at desktop environments and apps: They really don't need to utilize the CPU to its full potential; they're a mess of entanglement of things which get in each other's way and it's difficult to figure out why your system ends up being sluggish despite your brand-new shiny hardware. -- *Another problem with the current programming languages is that they didn’t evolve beyond the C-style type of programming. * * C-style type of programming is just fine for C-style kinds of programming tasks. Every language has strengths and weaknesses. Some pairs of languages have a more obvious "X is an evolved Y" or "X is a better Y" relationship, but not that many. * Most languages do not evolve or change to exploit specific hardware capabilities. Or at least - few language changes are intended to achieve that. -- etc. It's not a junk article though. The data orientation of program design is a useful notion, in many programming languages. It's just that, instead of reading this blog post, which quotes Mike Acton, you can just watch Acton's talk on this principle: https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc

tialaramex 6y ago
Another example: > “Use const and the compiler will optimize that away!” Nobody knows what the compiler will do, if nobody checked what the compiler did. Rust (in the Rustonomicon if nowhere else) specifically promises that const gives you the same results you'd get by calculating and manually inlining the constant itself everywhere. It even spells out all the things you thus can, and can't do in a constant so that your compiler can definitely correctly evaluate the constant from the point of view of the target architecture despite potentially different hardware. e.g. if you tell Rust const BAR :isize = isize::from_be(0x1234); You've conjured a constant BAR whose size and data layout depends on the target architecture, but the language promises that figuring this out incurs no runtime cost, the work will be done at compile time. Indeed Rust will refuse to compile your program if it can't figure out how to do this, explaining what went wrong, e.g. that same above snippet would not have worked years ago, because isize::from_be() was not yet marked as suitable for such endeavours and so the compiler wouldn't attempt it. If you mark a function the compiler can't evaluate as being suitable, the compiler will reject that too, even if you don't use the function, somebody else might and it won't disappoint them.

tialaramex 6y ago

Another example: > “Use const and the compiler will optimize that away!” Nobody knows what the compiler will do, if nobody checked what the compiler did. Rust (in the Rustonomicon if nowhere else) specifically promises that const gives you the same results you'd get by calculating and manually inlining the constant itself everywhere. It even spells out all the things you thus can, and can't do in a constant so that your compiler can definitely correctly evaluate the constant from the point of view of the target architecture despite potentially different hardware. e.g. if you tell Rust const BAR :isize = isize::from_be(0x1234); You've conjured a constant BAR whose size and data layout depends on the target architecture, but the language promises that figuring this out incurs no runtime cost, the work will be done at compile time. Indeed Rust will refuse to compile your program if it can't figure out how to do this, explaining what went wrong, e.g. that same above snippet would not have worked years ago, because isize::from_be() was not yet marked as suitable for such endeavours and so the compiler wouldn't attempt it. If you mark a function the compiler can't evaluate as being suitable, the compiler will reject that too, even if you don't use the function, somebody else might and it won't disappoint them.