Is it just me, but seeing the general layout of the site, I feel a powerful sense of nostalgia - as if its something straight out of the mid 2000s to early 10s era of internet.

>is there actually a programming language that makes race conditions impossible

It'd be very hard to make something that offers that guarantee in the real world. One of the most common, IRL exploitable race conditions are ones that involve multiple services/databases, and even if your programming language would have such a feature, your production system would not.

I think one of the fundamental differences in the SOTA C++ approach to memory safety (eg. extending unique/shared_ptr) and Rust is that C++ doesn't try to enforce having a single mutable reference to a variable and it still relies on strict aliasing heuristics, and so cannot claim to be fully deterministic. Still, use after free, and memory leaks should be impossible.

It'll still let you do a bunch of stuff Rust doesn't, which is up to the programmer to decide whether this is good or not.

> Still, use after free, and memory leaks should be impossible.

Use-after-free is still possible in modern C++ via std::span/std::string_view/etc. outliving the backing object.

I used to think so too, but I do have to complain about Microsoft doing the Microsoft thing - they have a brilliant idea (and execution), but they bury it in so much boilerplate that 99% of people who would use it are put off by it.

The amount of stuff you have to wade through here compared to something like comptime in Zig (Roslyn API, setting up the project, having VS recognize it and inject it in the compiler, debugging etc) makes usage of these an absolute pain.

While this looks cool, I don't see any code generation capability in the examples or the tests, only compile time evaluation.

This is more like constrexpr than a macro system.

The Linux kernel is also a monolith yet has worked forever without a rewrite.

I think there is a reasonably agreed on set of things that can be removed from X, like server-side drawing primitives, and GLX

The Linux kernel was not born obsolete on arrival like the X Window System was. At least, not fully obsolete.

It will be obsolete someday, anyways.

In what way was X11 obsolete in 1987?

“Obsolete” means that a replacement exists which is as good as, or better than, the thing it aims to replace, in every significant way.

X11 is far from obsolete.

Isn't accessibility outside of the scope of Wayland, whose purpose is to composite application buffers, and deliver input events?

Something like a screen reader needs to talk to an app and query the toolkit for the contents of a window in a semantic way - that's a toolkit feature not a compositor one.

What does this matter for blind people who want to use Linux? All that matters to them is that it's super complicated and nobody wants to work with the tech to make screen readers work on Wayland.

To my knowledge, X11 didn't offer a comprehensive accessibility API either - there's no Linux equivalent of stuff like MS Active Accessibility or MSUIA on Linux.

Even back then Qt, GTK and everyone else offered their own API and screen readers needed to integrate with every single one - this didn't really change under Wayland, only the sandboxing makes certain operations harder, but the accessibility story on Linux is not great, and never was.

The standard was Extended Window Manager Hints [0].

Above X11, implemented by GTK and everyone else. Right.

However... Wayland makes it impossible to implement EWMH. Which means the enrire EMWH standard needs to be tossed, and everyone needs to make something new.

You can't even get the title of a window, under Wayland. That's private to that process tree.

Wayland requires accessibility be implemented at the application level, not the window manager. And thats guaranteed to make it always broken for a majority of use cases.

[0] https://specifications.freedesktop.org/wm/latest/

>You can do per-display DPI just fine on X11 (through xrandr), it's just the major toolkits don't support it. GTK, for example, reads a single global DPI value from XSETTINGS; there's no reason why it has to be that way.

I remember people complaining about the GTK file picker not having a preview for more than a decade, and at some point it sort of became a meme.

When it finally got added, the PR was like a 2-300 lines.

And was added after they rewrote everything for the new GTK version when there're functional patches adding thumbnails to previous versions. (Which were rejected/ignored because they didn't feel good.) A situational very in parallel to Xorg/Wayland if consider: https://news.ycombinator.com/item?id=46382940.

Does it really have to be said that a PR is built upon previous work. It was not a 400 line delta for the whole feature.

Tech is full of examples of 'successor' technologies, that were aiming to provide a clean rewrite without legacy, which then got bogged down with supporting a bunch of corner cases and accumulated their own share of cruft and could be no longer be considered a cleaner alternative. All the while the majority of the userbase being stuck on the old platform because the new one is buggy and doesn't offer anything tangibly better.

Vulkan, various node replacements come to mind.

Wayland at this point has existed almost as long as X11, longer if you only count the Linux years, yet its still not quite there.

Wayland and its various implementations like KDE plasma are 90% ready. Now they just need the other 90% to move from alpha to product. I expect it'll take another decade or two.

Afaik Xorg is 'only' like ~500k lines of code, which is not huge by the standards of large porjects. In fact, one of the major counter arguments against Wayland, is that the compositor + a few core libs, like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code (which has a ton of unused cruft).

> like wlroots necessary to provide a similar set of functionalities, is already larger that the equivalent X11 code

I absolutely don't buy this.