That's pretty much true of HTMX too (which is what GP mentions using). I mention Hotwire Native (different from plain Hotwire) because it makes it easy to wrap a web app as a mobile app. Then you can replace performance critical parts with native views, but keep everything else working through the web app portion. This is easier to maintain, albeit with the downside that everything requires network round trips. Depending on you use case, that may be an acceptable tradeoff.
Can't vouch for it's effectiveness, but Hotwire Native might meet the needs for mobile paired with plain HTML. Despite the name, it doesn't seem that using Hotwire for the web UI is necessary to use Hotwire Native. I could be wrong about that though.
There was a hidden benefit in the old way: it avoided people making effort for things that weren't important. It took effort to make signal cut through noise. When it was low effort, it was obvious it was just noise and could easily be ignored.
Now low effort noise can masquerade as high effort signal, drowning out the signal for things that actually matter.
Direct relationships of trust matter more than ever now. You can't just trust that if something looks high effort that it actually is. You need to know the person producing it and know how they approach work and how they treat you personally. Do they cut corners all the time or only for reasons they clearly communicate? Do they value high quality work? Do they respect your time?
I haven't had to deal with this in open source, but I have had to deal with coworkers posting slop for code reviews where I am the assigned reviewer.
I've noticed that slop code has certain tell tale markers (such as import statements being moved for no discernible reason). No sane human does things like this. I call this "the sixth finger of code." It's important to look for these signs as soon as possible.
Once one is spotted, you can generally stop reading; you are wasting your time since the code will be confusing and the code "creator" doesn't understand the code any better than you do. Any comments you post to correct the code will just be fed into an LLM to generate another round of slop.
In these situations, effort has not been saved by using an LLM; it has at best been shifted. Most likely it has been both shifted and inflated, and you bear the increased cost as the reviewer.
Although I'm not wild about the new `io` parameter popping up everywhere, I love the fact that it allows multiple implementations (thread based, fiber based, etc.) and avoids forcing the user to know and/or care about the implementation, much like the Allocator interface.
Overall, I think it's a win. Especially if there is a stdlib implementation that is a no overhead, bogstock, synchronous, blocking io implementation. It follows the "don't pay for things you don't use" attitude of the rest of zig.
> Our Hosting provider, Hetzner, has recently started charging for public IPv4 addresses - as they should! Those numbers started getting expensive. This prompted me to try and set up a new server cluster using IPv6 exclusively...
I think what OP went thru is what will make the transition happen. Market forces are ultimately going to be the thing that drives wider adoption: IPv4 addresses getting so expensive that it drives people to try IPv6, and when that fails they complain in posts like this and directly to their service providers. The fact that OP names names of services failing to offer IPv6 is a good thing. Ideally it will start creating pressure on those services/corporations to fully support IPv6. If complaining doesn't work to motivate them, users moving away from their services to providers who do offer IPv6 support will motivate them.
https://rubydoc.info/gems/async_futures
https://rubydoc.info/gems/async_futures/index