OpenD added almost-full (you can't catch exceptions or spawn threads, so not really full, but the GC and such work fine) wasm support with like .... i think it was less than one day of work. wasm sucks though, what a miserable platform.
No such thing happened. D has always been built on the same codebase, and the labels "D1" and "D2" are just arbitrary points on a mostly linear evolution (in fact, the tags D 1.0 and D 2.0 came only 6 months apart; 1.0 was just meant to be a long term support branch, not a different language. It was the addition of `const` that broke most code around release 2.6 but if you update those, old and new compilers generally work.
I'd say where D failed was its insistence on chasing every half-baked trend that someone comments on Hacker News. Seriously, look at this very thread, Walter is replying to thing after thing saying "D has this too!!" nevermind if it actually is valuable irl or not.
that actually wasn't its intended use; that's a side effect. The original intended use came from Effective C++ by Scott Meyers: "Prefer non-member non-friend functions to member functions.". It was meant to make that as syntactically appealing as the members.
The D parts of the compiler were released under the GPL from almost the beginning, since 2002. By 2004, a full open source compiler - what we now call gdc, officially part of gcc - was released using this GPL code. D was pretty popular in these years.
Just a personal anecdote, Walter Bright's Digital Mars C++ compiler also had the contracts (D started life almost literally as recycled code from Mr. Bright's other compilers - he wrote a native Java compiler, a Javascript 1.3 stdlib, and a C++ compiler with a bunch of extensions.... smash those together and you have the early D releases!).
Anyway, I used the DM C++ compiler originally because it was the only one I could download to the high school computers without filling out a form, and pimply-face youth me saw "DESIGN BY CONTRACT" at the top of the website and got kinda excited thinking it was a way to make some easy money coding online.
Imagine my disappointment when I saw it was just in/out/invariant/assert features. (I'm pretty sure D had just come out when I saw that, but I saw `import` instead of `#include` and dismissed it as a weenie language. Came back a couple years later and cursed my younger self for being a fool! lol)
Use the ascii bell character "\a" and turn off the "visual bell" or whatever options in the terminal (I hate those things) so you can actually hear it beep and find joy.
so does modern. so the same author who hates the term modern uses neo - synonomous with modern for all practical purposes - vim and mutt. why is that? might those reasons also apply to other "modern" things?
What I find offensive about this post is using "neo"vim and neomutt. what, was original AgentSmithMutt and TrinityVim not good enough? ...Is it because they're old?
Well anyway, I mostly agree with this post. Another similar thing I hate to see is things like "Really? In 2024?" and im just like that's the laziest critique of something ever.
> In years of doing this not a single person has ever complained
I've never used your website, but if I did and the side arrow changed things, I'd immediately close it and never come back. You wouldn't get a complaint from me; you'd just lose me instantly and permanently.
It drives me absolutely nuts when sites do this, it is so disorienting.
> Now that they're detaching from Serenity they can start reaping the benefits of the existing work in the FOSS ecosystem, which should enable a faster pace of development.
If you're including TCP ACKs as part of the "chatty"/"required round trips" of a higher level protocol, that's bad new for a lot of things. (Which, granted, is why they made those QUIC protocols etc., but still, it seems unreasonable to single out X's protocol for this, especially since RDP and VNC are commonly used over TCP as well).
But:
> This is why things like RDP, PCoIP, etc could do full frame rate HD video 15 years ago and you still can't with X protocol over the network.
Compression is going to have a much bigger impact over a large motion than most anything else; you can stream video over HTTP 1.1 / TCP thanks to video codecs, but X (sadly i think, seems like such an easy thing that should have been in an extension, but even png or jpeg never made it in) doesn't support any of that.
> It's almost all using Xshm for anything non-trivial.
Xshm is not available over a network link and it is common for client applications to detect this and gracefully degrade.
> All the rendering happens server side, and bitmaps are sent over the wire. It's basically a crappy VNC.
Even if this were true (which it isn't), there's a lot more to a GUI than the G. A lot of nice interoperability is provided too, like clipboard integration, dragging and dropping, mixed windows on the same taskbar, etc. Far more pleasant to use than awkwardly going to a full screen thing to get a window out.
> This is fun and all, but if you lose your connection, your windows will go away and your program will usually exit.
Interestingly, that is xlib's behavior moreso than inherent in the protocol. xlib assumes connection lost is a fatal event, but if you're doing your own socket, you can choose to do this differently. (or, even with xlib, you can throw an exception from the connection lost callback and regain control before letting it abort)
Some server state is lost, but it is possible, with some care, to recreate that from your client upon reconnecting. You can even connect to a different server and somewhat seamlessly migrate windows over.
> So it being the "age of Terabyte HDDs" does not matter, for packages expected to be installed on a normal desktop system.
But neither does the "size on disk" because the ACTUAL size on disk might be reduced by gzip/bzip2/xz/zstd/whatever is invented later. Even if the program using the package doesn't support compression, it supports filesystems and filesystems often support some kind of transparent compression. It isn't a hard problem to solve.