/prog/s opinion on Go

You know, the google thing.  Personally I'm a bit excited for a compiled python-like C language.  It's going to take for fucking ever for it to become useful, though, especially with google's slow and steady attitude.  I could see it catching on though kind of like python did.

>>68
Go does have this. It's called slices. It's a built-in language feature
Which was the entire point of the text you quoted.

Total bullshit. Under the hood, slices are probably implemented as
I love how you call bullshit, and immediately confess to not knowing a goddamn thing about what you're discussing. That's a masterful trolling technique you have.

And this is insignificant compared to the size of the array itself!
And yet, the pointer to the current position in the array will still take 4 (8 for 64-bit) bytes of cache, versus the 12 (or 24) required to hold either a start/current/end pointers or an array/index/length triple. When you're optimizing for speed, keeping your L1 cache clean is hugely important, and even on the most modern CPUs, you only have a few hundred bytes to work with. You'll never match the speed of a very tight pointer-based function if you keep invalidating cache lines with "safe" array training wheels. The size of your array is irrelevant.