The problem is, as usual, that some people want that support, but nobody is actually interested in helping out with that support - and that doesn't only include people willing to help out with the code, it includes things like CI. Just how the riscv targets won't be able to reach tier 1 without GH or someone else offering CI support.
Rust's target tiers, while historically not as enforced as they are today, have requirements attached to them that each target has to fulfill; demoting a target or removing support isn't done for fun, but because of what the reality reflects. In Windows 7's case, support from the Tier 1 Windows target was not so much removed as it was acknowledged that the support guaranteees just didn't exist - host tools had long been dead with LLVM having removed support for running on Windows 7, and tier 1 support wasn't guaranteed without any CI to test it on. Thus support was removed, and very soon contributors popped up to maintain the win7 target which is tier 3 and accurately reflects the support gurantees of that target.
(Not a jab at your situation btw, and I wish I could offer you a solution beyond the win7 target - but as it's essentially the preexisting Windows 7 support extracted into a target that matched its reality, it works quite well in practice)
I do wonder how much support is removed because of genuine maintenance or compatibility burden, because I've encountered enough examples where it was done solely because some target was deemed "too old" arbitrarily, even if it would still work without any modifications.
> even if it would still work without any modifications
even in this case, maintenance burden is still real. supporting the old target often prevents you from using features/tools that make maintenance easier
Perhaps the best example I can think of is the whole situation
InstallShield is....massive crapware and actually generated 16 bit installers way way after anyone was using 16bit PCs. Nobody notices until, I think it was W8 or W10 dropped support for running 16bit executables (something about dropping the subsystem that supported them.
Windows 11 drops IA32, and thus (first party) MS-DOS and Windows 3.x support.
Windows actually has some special cased support for (at least some of) the problematic 16 bit InstallShield installers to run a 32 bit version instead on AMD64.
From InstallShield’s perspective, why would they replace working 16-bit code which is still natively compatible with Windows and x86? Because Windows and/or Intel might (or might not) drop support a decade later?
In Rust or in general? Because an arbitrary "too old" moniker is not something I've seen happening, and the only target that was removed instead of demoted in recent times was i586-pc-windows-msvc, aka Windows 10 without SSE, which was...utterly pointless since Windows 10 requires SSE.
If anything, I quite like the way Rust handles it with target tiers and easy switching between targets, because it's an honest approach about how well a target is supported. Having a win7 target that is tier 3 is a reflection of the support it has, and much better than stringing it along in the main Windows target that promises tested support when there isn't even a Windows 7 CI to test on.
In some ways, Windows already does that too - the 32-bit syscall wrappers [switch into a 64-bit code segment](https://aktas.github.io/Heavens-Gate) so the 64-bit ntdll copy can call the 64-bit syscall.
> You're starting to feel it absolutely everywhere
Starting to? 30-50% of the HN front page has been consisting of articles about LLMs for months now, to the point that a user script to hide all AI articles vastly improves the experience.
You're thinking of Amsterdam? I used to live there.
Bikes are used there ONLY because there's no alternative to them. Transit takes too long, and there's no space for cars. And yet still around 20% of commutes in Amsterdam are by car.
> not every country has to be a nightmare for life quality like the US aspires to be.
The US is far, far, far ahead of Europe in urban quality of life that it's not even funny, if you disregard the dense hellscapes of SF and NYC.
This is easily seen in the number of children per capita. In modern societies, two groups of people tend to have more children ("inverted J-curve"):
1. Happy content people.
2. Desperately poor people.
Now look at Europe and the US, and I suggest looking at the US suburbs and not the dense cores.
I've worked in Amsterdam. Used to take my car out to a park and ride station out in "the province" and joined the first standup of the day out of the "long yellow office building" [1], then a short walk to the tall grey one to actually get coding.
In or near Amsterdam I've seen and/or used busses, trains, ferrys, trams, bicycles, cars; and aircraft on approach to Schiphol looked like they almost flew past the window.
I also kind of like New Amsterdam (New York). It's cozy!
Can't argue with taste I guess. %-)
[1] Intercity trains: Long, Yellow, with electricity, free wifi, a place to sit, and you can bring your own Starbucks on board. Do try to avoid rush hour, or you'll be taking "standup" a bit too literally.
So did I. And I had to be at the office at 7:30am. Even when the weather outside was "bracing".
> [1] Intercity trains: Long, Yellow, with electricity, free wifi, a place to sit, and you can bring your own Starbucks on board. Do try to avoid rush hour, or you'll be taking "standup" a bit too literally.
So basically, you wasted around 2 hours a day on the commute?
Total commute time was about 3 hours (90 minutes each way). I do not live in Amsterdam. About an hour of that was wasted because I needed to drive myself. The rest was often spent in useful ways in the back seat of a lovely stretched yellow vehicle with lots of horsepower and a chauffeur.
That would defeat the purpose. The whole point is to reduce costs by getting a cheap junior dev and having them operate AI to produce the same or better result for far less
So the point is to use technological advancements only to increase company profit and not pass any on to the actual workers. If a junior costs 1/4 of a senior, they could easily paid more from the 3/4s saved (since they're also more valuable now), but I guess shareholder millions come first.
Apathy? More like the fact that the majority of people are too lazy, not motivated enough, not willing to take risks, and go out and build something of their own that results in wealth, and prefer to sit safe as someones employee, complaining about 'wealth inequality'
It's interesting to watch you put zero value on work/effort/labor and huge value on risk taking (which is very different for people with different "safety nets").
As the previous commenter said - you don't need a new runtime instance per button, so the comparison doesn't really work (for the smallest binary size, you could provide a native application doing the bare minimum to display the UI too, if the platform has an OS-provided UI framework).
It's still a neat toolkit, since not every website needs a big framework - but comparing runtime sizes is like choosing C over C++ because a `int main() { printf("Hello World\n"); }` binary is smaller.
I think it's relevant in the sense that it shows if you're building a simple app, there's a lot of overhead.
It doesn't claim that you're going to get that overhead for every time you instance a button. I don't see how anyone would think that.
I think the comparison works fairly well. It should be clear to everyone that it compares apples and oranges, since it's two different kind of apps it's comparing. So it makes you think. If they just compared the size of the framework itself, or a single button vs a single button, you may think "oh but as soon as you add any kind of complicated code, there will probably be so much boilerplate with Nue that it'll end up being bigger"..
> There are very limited things you are supposed to do in an APC, but these are poorly documented and need one to think carefully about what is happening when a thread is executing in a stack frame and you interrupt it with this horrorshow.
One must not throw a C++ exception across stack frames that don't participate in C++ stack unwinding, whether it's a Win32 APC, another Win32 callback, a POSIX signal or `qsort` (for the people that believe qsort still has a place in this decade). How the Win32 API is designed is absolutely irrelevant for the bug in this code.
