I’m all for an X12.
If you take the time to read through that (very partial) list of cruft and footguns in X11 it probably makes it a little easier to understand why a clean-slate approach was able to attract momentum and why many hands-on involved developers were relatively tired of X11. Critics would of course respond that backwards compatibility is worth the effort and rewrites are often the wrong call, etc. It's the Python 2/3 debate and many others.
For example, in python 2 you could explicitly mark unicode text with u"...". That was actively BLOCKED with python 3.0 which supposedly was about unicode support! The irony was insane, they could of just no-oped the u"". I got totally sick of the "expert" language designers with no real world code shipping responsibilities lecturing me. Every post about this stuff was met by comments from pedantic idiots. So every string had to have a helper function around it. Total and absolute garbage. They still haven't explained to my satisifaction why not support u"..." to allow a transition more easily to 3.
Luckily sanity started prevailing around 3.5 and we started to see a progression - whoever was behind this should be thanked. The clueless unicode everything was walked back and we got % for bytes so you could work with network protocols again (where unicode would be STUPID to force given the installed base). We got u"" back.
By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
It’s always drama and they’re the center of it.
(I’m joking of course, Merry Christmas)
It's definitely not well designed though.
And I agree about recommending it to beginners. Sure, a for-loop and a simple function look very friendly and easy, but good luck explaining to them why they can't import from a file in a different directory...
> [...]
> By 3.6 we got back to reasonable path handling on windows and the 3 benefits started to come without antagonistic approaches / regressions from 2. But that was about 8 years? So that burnt a lot of the initial excitement.
So it's a great analogy. Wayland started out proudly proclaiming that it intentionally didn't support features in the name of "security" but everyone should "upgrade" because this was totally better, and has been very slowly discovering that actually all the stuff it willfully dropped was useful and has mostly evolved back to near feature parity with Xorg.
I remember Usenet.
X11 was built for multi-user terminals a kin to today’s Microsoft VDI garbage.
There’s some good. A lot of bad. And some WTF in there.
Just... without all that mess that turned out to be at best +/-, at worst outright negative causing problems for everyone involved. And near all of the "advantages" are "the server is built from scratch" not "the protocol was the limitation"
Also happy winter solstice.
In addition, you can offload OpenGL compatibility to Zink (again leaning into Vulkan).
> pull in a group of long term maintainers.
"Use new cool language" seems to be a prerequisite for this nowadays ...
At least Zig is very compatible with C.
Just use OpenGL. I don't know when this trend to overcomplicate everything using Vulkan began, but I hate it.
Vulkan has substantial advantages for multi-threaded code, as well as exposing the underlying asynchronous nature of running code on the GPU. The kind of thing you want to be able to control with a desktop compositor where controlling vsync and present timing is very important.