Aliasing
Key topics
Ditching pointers as a programmer-facing concept sparked a lively debate, with some commenters pointing to functional programming languages as a precedent for this approach, while others argued that a type system like Rust's is the way to go for system programming languages. The discussion was prompted by a series on aliasing, which one commenter praised as "excellent" for teaching them about assembly. As the conversation unfolded, it became clear that aliasing remains a thorn in the side of performance-intensive codebases, with some even preferring Fortran due to its handling of the issue. Interestingly, a Fortran developer chimed in to note that aliasing can still be a problem in that language, highlighting the complexity of the issue.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
27
Day 7
Avg / period
8.8
Based on 35 loaded comments
Key moments
- 01Story posted
Dec 16, 2025 at 5:13 AM EST
26 days ago
Step 01 - 02First comment
Dec 22, 2025 at 1:54 AM EST
6d after posting
Step 02 - 03Peak activity
27 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 24, 2025 at 9:00 PM EST
17 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> 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)
Now that I think about it some more, perhaps gfortran might be a differentiating factor? Not familiar enough with Fortran to guess as to how much it would exercise aliasing-related optimizations, though.
While it is possible to remove most aliasing performance issues in a C or C++ codebase, it is a pain to do it properly.
Decades ago I was a Fortran developer and encountered a very odd bug in which the wrong values were being calculated. After a lot of investigation I tracked it down to a subroutine call in which a hard-coded zero was being passed as an argument. It turned out that in the body of that subroutine the value 4 was being assigned to that parameter for some reason. The side effect was that the value of zero because 4 for the rest of the program execution because Fortran aliases all parameters since it passes by descriptor (or at least DEC FORTRAN IV did so on RSX/11). As you can imagine, hilarity ensued.
"Passing constants to a subprogram" https://www.ibiblio.org/pub/languages/fortran/ch1-8.html
https://godbolt.org/z/jva4shbjs
Yes. That is the main solution and it is not a good one.
1- `restrict` need to be used carefully. Putting it everywhere in large codebase can lead to pretty tricky bugs if aliasing does occurs under the hood.
1- Restrict is not an official keyword in C++. C++ always has refused to standardize it because it plays terribly with almost any object model.
For C++, yes, I agree.
I also wrote about this a while ago: https://forwardscattering.org/post/51