Safety. Without pointer arithmetic it's possible to create a language that can never derive an illegal address that succeeds incorrectly. Compiler and hardware technology have advanced to the point where a loop using array indices can be as efficient as a loop using pointer arithmetic. Also, the lack of pointer arithmetic can simplify the implementation of the garbage collector.
<3
I literally refactored some code from index arithmetic to pointer arithmetic and bought a 10% increase in performance for an (admittedly silly) numerical performance contest on Friday, so I'm not convinced either LLVM or the "jit compiler that reorders operations inside the x86 chip" are that smart yet.
That said I would not doubt that most modern languages convert iterables that look like index arithmetic into pointer arithmetic, but if they do so I would suspect it's at an IR level above the general compiler backend.
In Rust iterators are actually the fastest way to safely iterate over arrays, because they will elide bounds checks. If you use `array[index]` you will get a mandatory bounds check (branch) on each access. Using pointer arithmetic would avoid that, but is unsafe in Rust for obvious reasons.
In C I would assume indexes and pointer arithmetic to have exactly the same performance, since the `array[i]` is the same as `*(array + i)` and there are no mandatry bounds checks. Might be interesting to move your code in godbolt and see what actually changes here.
That is unsurprising
> They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
To paraphrase Stroustrup:
There are two kinds of languages: the simple ones (Scheme, Smalltalk, early Python and JS), and the ones everyone uses.
OCaml is not on the languages referred by Rob Pike.
What he was saying from the previous bit is that they wanted their new language we now know as Go to be familiar to those who have learned Java, C, C++, etc.
This is opposed to it being derived from, say, Haskell, that, while brilliant, few have familiarity with.
It’s not ironic that Go is similar Java, especially in its earlier days. Those similarities are stated as an intent of Go’s design.
So that over-engineered library that actually solves the problem is the only real productivity benefit we can achieve, since languages don’t beat each other in productivity to any significant degree (see Brooks).
So while one may not want to go into macro-magic with a semi-junior team, no abstraction will just as much kill a project because LOC will explode, it will have tremendous amounts of buggy copy-pasted/multiple times implemented code, etc. And the few empirical facts we know about programming is that bug count correlates linearly with LOC.