Zig disagree with you: they even made unsigned OV undefined (in unchecked mode)

I guess yet another reason not to bother with Zig.

Or that reasonable people may disagree on when to make signed/unsigned overflow undefined: Zig didn't only make it an UB on unchecked build they also trigger an "abort on overflow" in checked build.

Make it implementation defined, if you must. But undefined is pretty sad.

Nobody forces you to use unchecked build! And some people want maximum performances, I've read that bound checking can hurt SIMDification..

If it's opt-in, it's no so bad.

(In an ideal world, which we sadly don't live in, you would statically prove that the dynamic bound checking would always succeed, and only then remove it.)

> The same goes for its "Code Density" argument: nope, code density is very important.

Sure, but ARM's thumb has shown that you can get a RISC which has the same code density as current CISCs.

Of course, it's because current CISCs are bad due to backward compatibility but..

> Unfortunately that's somewhat expected - regardless of implementation

Yes, that's expected and no not "regardless of implementation": the GC implementation CAN be improved.

See this discussion on reddit: https://old.reddit.com/r/programming/comments/1wf2fei/40ms_g...

Copy/pasted here: >>

I remember a research paper about swap and GC, where the GC cooperated with the OS to avoid this kind of issue. AFAIK it went nowhere, too bad.

[–]andreiross[S] 15 points il y a 21 jours

Are you talking about this one? https://cse.buffalo.edu/\~mhertz/bc-pldi-2005.pdf. If so, yes. Too bad. I don't know the repercusions this paper had in the past, though, in the sense of pros and cons of the bookmark collector. Don't know if anyone tried to actually implement it or design it at some point.

[–]renozyx 9 points il y a 21 jours

Yes, congratulations for finding it. And I don't know either,. Except that they did implement it on Linux (of course) https://plasma.cs.umass.edu/emery/cooperative-memory-managem...

<<

It isn't a toy for sure, but I doubt that it has good scalability stories when using SMP.. I'd love to be wrong given that even phones are multicores, so feel free to correct me.

It does have SMP support but it's unverified and I'm not sure how widely used or well-tested it is.

'data oriented' doesn't mean 'just use SoA' it means use data structures which correspond to your data access pattern. Which is quite difficult to know in complex applications and which can change..

> hands are wrung that communication will become rife with error and misunderstanding because unlike the telegraph, the newfangled telephone leaves no written record!

Well let's not forget that early phone communication quality was ahem not-very-good, so of course errors were an issue.

> If you have a read-only variable and exclusive access to it, then you can rely on immutability as well.

The problem is the "exclusive access to it", most language aren't Rust.. Some Ada-implementation has the problem ( https://news.ycombinator.com/item?id=43001394 )

Why do you say this? The post is quite clear that marking the memory region as NX fix the issue caused by speculative execution.

> the OS _writes_ unused memory pages to the swap file

The OS write unused memory pages to the swap file by default. But the 'constant memory' design is usually done with locking in memory both the executable and memory pages (also pinning the process to CPUs, using realtime priorities etc).

Read about the AF447 Rio-Paris crash. Input stick averaging?? That's a huge design mistake which contributed to the crash and AFAIK is still here..

What’s the alternative? I think averaging with a dual input alert is a pretty good solution. Otherwise you need to find a solution to transition from one stick to the other. You can’t just switch sticks with the press of a button because the input could jump from elevator up directly to elevator down for example.

You give them direct feedback and eliminate the need for this completely