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.
I bring up raw milk because it is minimally processed (I don't even consume it personally). I used it as an example because it shows how much plastic is embedded in the food chain and ecosystem by looking at one of the least processed items on the list.
The most disturbing is "Raw Cow Milk from Farm in Glass". It still is loaded with plastic, even though it is one of the least processed things on the list.
My only question is was the cow milked by hand or by machine? The tubing in a milking machine almost certainly contains plastic.
I use it on my own docs to remove extraneous details. I often write too many words in early drafts and LLMs summarize my writing faster than I can (although I don't know if they do it better than I would/could).
Then the next version of my doc becomes the summarization, and I only flesh out details where the summarization went too far and removed critical details.
And that increase in LLM usage has resulted in an enormous increase of code duplications and code churn in said open source projects. Any benefit from new features implemented by LLMs is being offset by the tech debt caused by duplication and the maintenance burden of constantly reverting bad code (i.e. churn).
I mostly like Vim because it is available everywhere and in the terminal. In its default configuration it isn't the most powerful IDE, but it is vastly more powerful that any other default experience in any other text editor (IMO). It also makes it trivially easy to shell out to external tools for modifying the text, so even for a set up that isn't heavily riced you can still do a ton.
Even when I'm forced to use another IDE for work, I try to find Vim keybindings ASAP. I like that I can learn Vim motions and actions once and use them in nearly every IDE.
My understanding is that TIOBE is primarily based on number of search engine results. Other results like number of active (a commit within the last 6-12 months) open source repos or number of new repos in a given language are other metrics worth considering. The project you linked seems to be one like this.
A high search rate doesn't necessarily mean high rate of real world usage. Correlating across multiple metrics would be a better way to measure popularity.
Although popularity itself may still be a weak signal depending on your purposes.
I had one job at a pinball company where my coworkers and I didn't get paid for a couple months. I quickly found work elsewhere. Thankfulfully my backpay did eventually come, but I wasn't going to stick around to see if they would be good to their word again the next time funds dried up. I heard this was a recurring problem even before I was hired on.
Later some of my coworkers sent an article to me mentioning that the owner was under investigation by the SEC for (allegedly) embezzling funds from investors. I think I figured out where everyone's paychecks were going.
I tried AI code completion via Amazon Q. I quickly turned it off; half the suggestions were noise that took more time to review than actually writing it myself.
The one good use I have found is using it to tighten up my writing in design documents. I tend to use too many words to describe things. I use an LLM as a type of prose compressor on my documents. I need to re-read it afterward and make minor corrections, but it still saves me time since summarising my own writing takes much more time and energy.
That is the only net win I've had with LLMs so far.
I tried graveyards and swing shifts in my twenties. I only did it for a year, but it wrecked my sleep schedule for years afterward; I struggled with insomnia because of it. Not sure there is any age where this works.
Some people can handle it better than others. I'll never do it again though.
https://rubydoc.info/gems/async_futures
https://rubydoc.info/gems/async_futures/index