The difference is exactly the speed. Slowly transitioning from one thing to another gives the opportunity to contributors to get involved in the process.
Just because some set of hypothetical contributors want a slow-moving target and the maintainers want to be on Rust now, I'm supposed to be mad at the maintainers? Why?
The two(2) H450s are in that unit cost range. The others and the Heron variants range to $40 million. A not insignificant number of Iranian aircraft(such as the US-produced F-5s and C-130s acquired before 1979's Revolution) are low unit costs comparably to the UAVs("drones") lost here.
Attrition compared to US materiel(not material - although that too greatly burdens cost to the US) depletion such as the aforementioned Patriot does not favor the US for sustained operations in theater(let alone should a second theater contingency operation occur).
thank you for calling this out. Tern does implement
the Svix/Standard Webhooks format internally the svix-style payload
({id}.{timestamp}.{body}) and header conventions are handled as a first-class
config in the SignatureConfig type, so yes, any Standard Webhooks compatible
provider works out of the box. there is custom config in which you can choose algorithm, signature header, signature format... covering all types of svix style webhooks
Will make sure this is more visible in the docs. Thanks for the tip
These are two sides of the same coin. Go has its quirks because they put things in the standard library so they can't iterate (in breaking manners), while Rust can iterate and improve ideas much faster as it's driven by the ecosystem.
Edit: changed "perfect" to "improve", as I meant "perfect" as "betterment" not in terms of absolute perfection.
There is a moral hazard here. By accepting that APIs are forever, you tend to be more cautious and move toward getting it right the first time.
Slower is better... And also faster in the long run, as things compose.
Personally, I do believe that there is one best way to do things quite often, but time constraints make people settle.
At least it is my experience building some systems.
Not sure it is always a good calculus to defer the hard thinking to later.
The golang.org/x/ namespace is the other half of the standard library in all but name. That gets iterated often.
For stuff in the standard library proper, the versioning system is working well for it. For example, the json library is now at v2. Code relying on the original json API can still be compiled.
The cost of "perfecting" an idea here is ruining the broader ecosystem. It is much much better for an API to be kinda crappy (but stable) for historical reasons than dealing with the constant churn and fragmentation caused by, for example, the fifth revision of that URL routing library that everyone uses because everyone uses it. It only gets worse by the orthogonal but comorbid attitude of radically minimizing the scope of dependencies.
Which has been working great for go, right. They shipped "log" and "flag" stdlib packages, so everyone uses... well, not those. I think "logrus" and "zap" are probably the most popular, but there's a ton of fragmentation in Go because of the crappy log package, including Go itself now shipping two logging packages in the stdlib ('log/slog').
Rust on the other hand has "log" as a clear winner, and significantly less overall fragmentation there.
> It is much much better for an API to be kinda crappy (but stable) for historical reasons
But this does more than just add a maintenance burden. If the API can't be removed, architectural constraints it imposes also can't be removed.
e.g. A hypothetical API that guarantees a callback during a specific phase of an operation means that you couldn't change to a new or better algorithm that doesn't have that phase.
Realize the "log" api is bad? Make "log/slog". Realize the "rand" api is bad? Make "rand/v2". Realize the "image/draw" api is bad? Make "golang.org/x/image/draw". Realize the "ioutil" package is bad? Move all the functions into "io".
Te stdlib already has at least 3 different patterns for duplicating API functionality with minor backwards-incompatible changes, and you can just do that and mark the old things as deprecated, but support it forever. Easy enough.
> mark the old things as deprecated, but support it forever
Is that 'supported'? A library that uses a callback that exists in 'log' but not in 'slog'; it'll compile forever, but it'll never work.
'Compiles but doesn't work' does not count as stable in my book. It's honestly worse than removing the API: both break, but one of them is noticed when the break happens.
I think “the fifth revision of that URL routing library that everyone uses” is a much less common case than “crate tried to explore a problem space, five years later a new crate thinks it can improve upon the solution”, which is what Rust’s conservatism really helps prevent. When you bake a particular crate into std, competitor crates now have a lot of inertia to overcome; when they're all third-party, the decision is not “add a crate?” but “replace a crate?” which is more palatable.
Letting an API evolve in a third-party crate also provides more accurate data on its utility; you get a lot of eyes on the problem space and can try different (potentially breaking) solutions before landing on consensus. Feedback during a Rust RFC is solicited from a much smaller group of people with less real-world usage.
Is there that much to explore in a given problem space. I believe a lot of people will take the good enough, but stable API over the unstable one that is striving for an unknown state of perfection. The customer of a library are programmers, they can patch over stuff for their own use case. A v2 can be released once enough pain points have been identified, but there should be a commitment to support v1 for a while.
Not the whole codebase, only the window manager (compositor is the Wayland equivalent). Other components are written in C and will remain so for the foreseeable future. Those components gained Wayland support in the last couple of years, you can try Xfce in a labwc session, there are of course several things to improve, but the compositor is the last big piece missing.
I spent a month or so in 2024 attempting to refactor xfwm4 so it could serve dual purpose as both an X11 window manager and Wayland compositor, and ended up abandoning the idea. It was just getting ugly and hard to read and understand, and I wasn't confident that I could continue to make changes without introducing bugs (crashers, even). We want X11 users to be unaffected by this, and introducing bugs in xfwm4 wouldn't achieve that goal.
Note that we don't have to rewrite all of Xfce: xfce4-session, xfce4-panel, xfdesktop, etc. will all run on Wayland just fine (there are some rough edges that need to be ironed out for full Wayland support, but they're already fairly usable on wlroots-based compositors). This is just (heh, "just") building a compositor and porting xfwm4's WM behavior and UI elements over to it. Not a small task, to be sure, but much smaller than "rewriting all of Xfce".
Pixels are pretty weak hardware wise in the areas people care about (heavy, relatively slow charging, big, etc.); I'd probably recommend people buy Samsungs which also get long term software updates nowadays.
reply