> the developer who should know the application better than the systems administrator
On the other hand, the administrator knows their system better than the developer. There could be certain network connections or file paths that you want to block on one system but not on another.
Well yes, neural networks are very good for pattern recognitions and data categorization tasks. Also for speech synthesis. I wasn't saying that this is a bad application of AI. I was talking about generative AI and LLMs specifically, the kind that takes prompt strings and spits out text/image/audio/whatever.
> autocomplete on steroids
Maybe if we manage to run LLMs locally, we can put one into a keyboard app and finally have a Russian touchscreen keyboard that doesn't make me want to yeet my phone at a wall for repeatedly failing to type the word in the correct grammatical form when I use gesture input. But somehow we aren't there yet. I guess ChatGPT is more important.
I don't think that you violated any guidelines. I think that the downvotes for your parent comment are only an expression of disagreement with what you propose. If I can suggest, don't take it personally.
Turning `'` into `lifetime` would make Rust code that needs explicit lifetimes extremely verbose. That would make code harder to keep on the same line, for no added benefit in expressiveness.
Allowing both `'` and `lifetime` in the syntax would make the language more confusing to anyone who is learning it, and it opens up unproductive debates about syntax in code bases if two authors have conflicting preferences.
Your explanation is appreciated. I naively assumed HN moderation was more meta than that. It boils down to taste, ultimately. I'm really a fan of Rust, and it is sobering to now experience this gatekeeping that the Rust community is often accused of first hand.
Of course, mixing keywords single quotes is confusing, but currently the single quote is also confusing.
Just to illustrate: The keyword could just be called lif, which has the same length as dyn.
I would most certainly not compare Autohotkey to Emacs in that way, as Emacs, powerful as it is, is not really meant to be the same as Autohotkey. However, Autohotkey can do pretty much anything you can think of in terms of GUI OS level local automation (for cli, I'd probably use WSL).
On Linux, I may sometimes have to glue xmodmap + xcape + xbindkeys + xdotool + wmctrl + whatever-else in a bash script that will probably require reading multiple man pages and multiple iterations to get right. Autohotkey would only require accessing a single source of solid documentation, as it can all be done in a single Autohotkey script that doesn't rely on any other tool.
More often than not GPT will give you the entire code that you need on the first or second response. But it only knows Autohotkey version 1.
Or for a more "hackable" experience on Windows, you can do what (I expect) AutoHotKey does, and send window messages to apps to trigger "key press" and "mouse down at X coords".
By analogy it's as is there's a single stable interface to the GUI layers in apps mediated by the OS, instead of poking at X APIs.
The problem is that neither Linus nor the other prominent maintainers will live forever. C was the right choice in 1991 but today the landscape is different enough that its shortcomings, for the younger generations, are painful to ignore.
So saying yes to Rust, or to some other language that is not filled with foot guns and could also work in the kernel space, is not only a matter of kindness but a matter of long-term strategy for the kernel.
>The problem is that neither Linus nor the other prominent maintainers will live forever.
I agree. But likewise, Linux's design is far from the state of the art. Maybe there's value in letting it be what it always has been. It is not realistic to try to migrate millions of LoCs written with poor structure, to properly structured Rust, with barely any support from the pre-existing developers.
At some time, it makes sense to move on to something better. This hypothetical system be written in a different language. It could be Rust, it could be C23, or something else entirely. But what it will definitely be is better structured. It would have clean, versioned APIs. And drivers will no doubt run in user space.
I’ve become convinced that complex things in tech either ossify and get stuff built on top of them, or get Ship of Theseus’d. It’s extremely rare for an outright replacement to replace something overnight. Linux is not going to be suddenly replaced by something incompatible, but I’m concinved it will become more oxidized over time. If not under Linus, then under an initially fully compatible corporate fork which would ultimately become more popular. So there’s some pressure on Linus to move it along .
On the other hand, the administrator knows their system better than the developer. There could be certain network connections or file paths that you want to block on one system but not on another.