I wonder how much potential optimisation there is if we entirely drop pointer nonsense.

▲ aw1621107 10 hours ago | parent | next [-]

Are you talking about dropping pointers as a programmer-facing programming language concept (in which case you might find Hylo and similar languages interesting), or dropping pointers from everything - programming languages, their implementations, compilers, etc. (in which case I'm not sure that's even possible)?

▲

artemonster 10 hours ago | parent [-]

Only the first one. Ofc under the hood they will stay, but I think its time to ditch random access model and pull fetching and concept of time closer to programmer

▲

uecker 5 hours ago | parent [-]

This is basically what many functional programming languages do. This always came with plausibly sounding claims that this allows so much better optimizations that this soon will surpass imperative programs in performance, but this never materialized (it still did not - even though Rust fans now adopted this claim, it still isn't quite true). Also control over explicit memory layout is still more important.

▲

aw1621107 3 hours ago | parent [-]

Gah, can't believe I forgot about functional programming languages here :(

> even though Rust fans now adopted this claim

Did they? Rust's references seem pretty pointer-like to me on the scale of "has pointers" to "pointers have been entirely removed from the language".

(Obviously Rust has actual pointers as well, but since usefully using them requires unsafe I assume they're out of scope here)

	▲	uecker 3 hours ago \| parent [-]
		What I meant is that Rust has stricter aliasing rules which make some optimization possible without extra annotations, but this is balanced out by many other issues.

▲ newpavlov 7 hours ago | parent | prev [-]

For a system programming language the right solution is to properly track aliasing information in the type system as done in Rust.

Aliasing issues is just yet another instance of C/C++ inferiority holding the industry back. C could've learnt from Fortran, but we ended up with the language we have...

▲ cv5005 an hour ago | parent [-]

For systems programming the correct way is to have explicit annotations so you can tell the compiler things like:

    void foo(void *a, void *b, int n) {
        assume_aligned(a, 16);
        assume_stride(a, 16);
        assume_distinct(a, b);
        ... go and vectorize!
    }

	▲	newpavlov an hour ago \| parent [-]
		LOL, nope. Those annotations must be part of the type system (e.g. `&mut T` in Rust) and must be checked by the compiler (the borrow checker). The language can provide escape hatches like `unsafe`, but they should be rarely used. Without it you get a fragile footgunny mess. Just look at the utter failure of `restrict`. It was so rarely used in C that it took several years of constant nagging from Rust developers to iron out various bugs in compilers caused by it.