I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported natively by databases
Just as with any kind of programming I want to be able to detect as much amount of issues as early as possible. That includes issues like invalid queries (both on syntax and types level) but also stuff like will specific transaction isolation level be just enough (from correctness and performance point) for my specific use case, or will the migration query lock the whole db or take multiple days to execute because I didn't know some niche quirk. To me it is obvious that you will not beable to do that with SQL, one because it is old so it accumulated all the weird quirks, that were done in the name of backward compatibility, two is that by it's nature of being script language you just could not do more complicated cross query static analysis. See also https://www.scattered-thoughts.net/writing/against-sql which nicely describes other issues. See languages like PRQL for better syntax, or https://www.languagesforsyste.ms/MixT/ for static analysis possibilities
I am mostly aligned with the article on what I want from next generation of web development. But I don't think using specific library in a specific language or specific query language is a viable long term solution. Hance the mention of Substrait. The solution that I think is needed, is something like LLVM but for databases.
As for the NoSQL, I think it was the worse thing that happened to databases in the last 20 years, probably more
Well some of their keyboards also hypothetically have open source firmware yet upon introducing a hardware revision they never released the necessary files. I only know this because I actually wanted to purchase one of those keyboards specifically for the open firmware.
They still seem to be the best (approximately only) game in town if you want the ability to flash your own firmware to a standard off the shelf peripheral.
> This repository is currently in its early setup phase.
> At the moment, the repository mainly contains project scaffolding, policy files, and the initial project direction. Firmware sources, board support, build instructions, and flashing guidance are still being prepared.
> That means zgm is early, but it is intentionally early in public. The goal is not to wait until everything is finished before opening the door. The goal is to make the long-term direction visible and let the project grow into a useful open firmware platform in the open.
> That means zgm is early, but it is intentionally early in public.
"Intentionally early" is one of those phrases that means they vibed this README out in an hour with AI, and now hope that they can create firmware for it in the next 6 months.
Larger types are supported, there is A notion of tearing. According to JVM spec even long and double could tear, not sure about practical implications though
I have converged on a workflow that is just what I was doing before, but use LLMs just for boring or tedios parts. General guidelines are: only single agent at a time, small targeted queries, understand what you are building, if something would seem like a fun task, do it yourself. I use LLMs for bug hunting, to trace the flow, to build quick visualizatios (paste csv, ask to generate visualization), to search in the code of the dependencies using github mcp, to write 100 line scripts (deno + ts + zx was a game changer for me). Even "dumber" opensource models are good for this kind workflow, more tokens per second is generally more benefitial than plain intelligence. I would use LLMs more or less, sometimes even full vibecoding if the task is something like quick tooling web app and the flow is just firing of the next LLM query every 30 seconds. But, depending on the type of task or domain that you work in, YMMV
Not sure why people praise Minecraft for this. This is huge feat of Wayland, and was possible because devs took time to consider use cases outside of current norm, and why it took so long to migrate the ecosystem. People liked to bitch about the "Gnome blocking/not implementing essential protocols" part, but even that partially made this possible
a very near example would be immersed vr which is compatible with xorg and does essentially the same thing (2d windows pasted all over a 3d world), although not integrated into minecraft. also since their solution isn't wayland-centric it has ports to osx and windows.
>If you're reading this, you're likely in the same boat as me. You've discovered that Immersed can create virtual monitors for Windows and Mac, but on Linux, this feature is marked as "unsupported" on X11. This means you can't create virtual monitors directly through the Immersed agent. For now, the known workaround is to manually set up virtual monitors. If you use Wayland, now immersed offer support for native virtual displays on the Immersed agent on gnome Wayland. You can access this options in Immersed client menu -> Setting -> Configure virtual displays. Other Wayland DE/Compositors are not supported, but there are ways to create virtual monitors manually as we do on X11, please check the linux-help channel in the Discord server for more info.
Basically immersed vr doesn't support X11 windows, it only supports X11 screens, which means you would have to create a new screen manually for each window.
Wayland is far more minimal API than X11 that mainly cares about surfaces and inputs. So, it's understandable that it can be "easily" translated to a game engine.
X11 has an entire drawing API. It'd probably be easier to run through Xwayland.
I don't actually think this is true. I think the issue is that the CLI is a much better paradigm if you're going to operate with text and text based commands.
LLMs excel at text, text is incredibly powerful in a cli environment.
It's not just that there's no GUI alternative, it's that the GUI itself is a bad affordance.
The only GUIs that even sort of successfully play in this space solve it by having a GUI that basically just embeds a CLI (see - all the vscode editors, antigravity, etc..).
This is the idea I had in mind since initial wasm release but wasm wasn't ready then but now it is. Glad to see somebody is working on this. If executed properly this could be the last windows manager that people will ever need
