I feel Your pain. And I have a advice: take a deep breath and leave. Because burn-out is real, because there is nothing that can compensate damages of Your mental health.
You are still a human. You are intelligent. Yes - you are, this is demonstrated by the ability to think critically and independence of your views. So - You are capable to adapt into new environment and into new tech. Search for anything and switch job. Don't wait for a toxic environment to destroy your confidence.
Blind spot that comes from incompetence and arrogance. See https://lwn.net/Articles/553415/ for example and remember famous words of Daniel Stone that brought the need for remote work to - merely - launch xeyes.
Thus, that particular comment (https://lwn.net/Articles/555124/) was prophetic:
"With that sort of attitude, I have no confidence that remote Wayland will ever work properly. Clearly Daniel just has a laptop and does all his work on it, and damn everyone who uses more than one machine for anything."
I come to Python around version 1.5, painfully tired by debugging CGI scripts, created by wannabe perl-golfers. Unfortunately, I feel like Python is losing more and more of the zen that once tempted me...
Lazy loading looks like a last nail in the coffin, where my love to Python was buried, although it was a long, tiresome process.
Zig strives to avoid numerous pitfalls, and I admire that.
Let's take a look at some of them:
1. Project control – if a LARGE company implements thousands of lines created by LLMs day after day – who is ultimately responsible for the project's progress? "You accept hundreds of PRs, so why not this one?"
And one more thing: will you be able to change the code yourself, or will you be forced to use LLMs? What if one of the "AI companies" implements a strict policy preventing "other tools that XXX" from editing the codebase?
2. Ownership. If most of the code was taken by an external company from their LLM, what about ownership of the code? The authors of Zig, the company, the authors of the original code, stolen by LLMs?
3. Liability. In the near future, a court may rule that LLMs are unethical and should not recombine code without the owners' prior consent. Who is responsible for damages and for removing the "stolen" code? The owners of Zig, the company that creates pull requests, or the authors of LLM programs?
4a. Vision. Creating and maintaining a large code base is very difficult – because without a broad perspective, vision, and the ability to predict and shape the future – code can devolve into an ugly mess of ad hoc fixes. We see this repeatedly when developers conclude, "This is unsustainable; the current code base prevents us from implementing the correct way to do things."
LLM programs cannot meet these requirements.
4b. There's another aspect – programming languages particularly suffer from a lack of vision or discipline. There are many factors that must be planned with appropriate capacity, vision, and rigor: the language itself should be modeled in a way that doesn't prevent correct implementation of behaviors. The standard library must be fast, concise, and stable. The compiler itself must be able to create code quickly and repeatably.
Users hate changes in a language – so if a language changes frequently, it is met with harsh criticism. Users hate incompatibility. Users hate technical debt and forced compatibility. Yes, there are conflicting requirements. The author of Zig understood this perfectly, having already gone through it himself (see, for example, "I/O Redesign").
This balance, in all aspects, is the pillar of human creativity.
To be honest, I'm not a huge fan of Zig because I dislike the tight syntax: too many periods and curly braces, which is why I prefer Odin. But I have a lot of affection and respect for Zig and its authors.
So - in that way - LLM will be Your mentor, it will shape Your way of thinking according to algorithms and datasets stuffed into by corporate creators.
Do You really want it?
There is also a second face of that: people are lazy. They wouldn't develop their own skills but rather they would off-load tasks to LLM-s, so their communicative abilities will be fade away.
Looks like a LLM hallucination - there is no thing like "RHEL 14.3", although referenced kernel signature (6.12.0-124.45.1.el10_1) contains reference to real RHEL release, i.e. 10.1.
I prefer ~/bin/ for my scripts, links to specific commands, etc.
~/.local/bin is tedious to write, when I want to see directory content and - most important - I treat whole ~/.local/ as managed automatically by other services and volatile.
"And it's just plain better at writing code than 60% of my graduating class was back in the day".
Only because it has access to vast amount of sample code to draw a re-combine parts. Did You ever considered emerging technologies, like new languages or frameworks that may be a much better suited for You area but they are new, thus there is no codebase for LLM to draw from?
I'm starting to think about a risk of technological stagnation in many areas.
First, we've fallen into a nomenclature trap, as so-called "AI" has nothing to do with "intelligence." Even its creators admit this, hence the name "AGI," since the appropriate acronym has already been used.
But, when we use "AI" acronym, our brains still recognize "intelligence" attribute and tend to perceive LLMs as more powerful than they actually are.
Current models are like trained parrots that can draw colored blocks and insert them into the appropriate slots. Sure, much faster and with incomparably more data. But they're still parrots.
This story and the discussions remind me of reports and articles about the first computers. People were so impressed by the speed of their mathematical calculations that they called them "electronic brains" and considered, even feared, "robot intelligence."
Now we're so impressed by the speed of pattern matching that we called them "artificial intelligence," and we're back to where we are.
But they were in different domains. Here, we have a strong clash because Rust is positioning itself as secure system and internet language and computer and internet standard are already defined by RFC-s. So, it may be not uncommon, when someone would tell about Rust mechanisms, defined by particular RFC in context of handling particular protocol, defined by... well... RFC too. But not by rust-one.
Not so smart, when we realize, that one of aspects of secure and reliable system is elimination of ambiguities.
As side note. Maybe someone knows, why rust devs chose an already used name for language changes proposal? "RFC" was already taken and well-established and I simply refuse to accept that someone wasn't aware about Request For Comments - and if it was true and clash was created deliberately, then it was rude and arrogant.
Every, ...king time, when I read something like "RFC 2789 introduced a sparse HTTP protocol." my brain suffers from a short-circuit. BTW: RFC 2789 is a "Mail Monitoring MIB".
A note from someone who specializes in long-term system maintenance:
There is also one, very important aspect, that is - (un)suprisingly - rarely mentioned in comments: a lack of dependence between sloppy work and personal comfort of particular person, responsible for problematic changes.
What I mean? A badly installed or configured system would be a problem in next three, maybe five years: to time of major OS upgrade, HW replacement or refresh, framework deprecation and so, and so... In current, corporate culture, there is almost impossible to being bite by own laziness - almost no one is working in particular company or for particular project so long. Especially, when installation is conducted by external party in model "grab the money and run!"
So, very basic motivation for good work, that comes from awareness, that today technological debt would lead to personal, painful experience in future, doesn't exists at all in modern, corporate environment. The things are even worse - there are multiple relations about negative career consequences resulting from concern for the quality of work: "because we want that product fast a we don't like troublemakers and defensive thinkers".
Nowadays NetBSD offers something similar to "context depended filesystem", i.e. a special form of symbolic links that can points to different locations, according to wide range set of attributes: from domainname via machine_arch to gid.
It won because it was in place (Outlook) and almost nobody cares.
Official version is: "because there is a whole history of correspondence and it is convenient to forward it to new participants".
In reality? It doesn't matter. Almost no-one reads, neither top- or bottom-posted mails. But there is a drawback in top-posting and I mean a "my comments inside original post, in color/bold/with indent/randomly inserted between two phrases". There is no standard of citing in top-posting - thus sometimes original mail gone. Edited, re-edited and commented in various, inconsistent and often unreadable ways.
Yes-and-no, I think. Limited usability of assembly language comes from limited resources (registers, operations) available to programmer, that leads to (so) many simple steps for more complicated tasks.
But, high-level language can offer a very interesting possibilities, even if it was not created for such kind of programming. For example, some time ago I made another attempt to emulate family of 65xxx. Previous versions were written in typical manner, like work of every other programmer on Earth.
A new approach, when a code was written in more regular way (see link below), like mentioned tabular-one, gave me excellent results. I was able to fully understood a program and processor logic and finally I was able to re-create a most magical command for 65xx: SBC/ADC with BCD support in very straightforward and clear way (especially for a cpu-like logic).
I'm sorry to say that but this article is not entirely true - an illustration "how does traditional raid 4/5/6 do it?" shows ONLY RAID 4. There is a big difference between RAID 4 and RAID 5/6 and former was abandoned a years (decades?) ago in favor of RAID 5 and - later - 6.
Of course, it gives "better publicity" for RAID-Z, but it is rather an marketing trick not engineering.
Not at all. Things like CFEengine (1993) and even Puppet predates a spread of "devops" term. Not mentioning tools for automated system installations, embedded in distributions like RedHat or Debian.
Creating a tools, that allows us doing a simple, repeatable and - usually - automated tasks, always was an important part of sysadm role. Of course, there were ones that did everything manually and wasn't able to write own code: we called them "operators".
From my point of view: "devop is that hasty one, that doesn't care about long-term support of underlying infrastructure".
Too often "DevOps" emerged as a way to walk around system administrators and their "blabling" about security, resource management, upgrades and long-term maintainability.
I'm always upset when I see a installations that are created with pattern: "we need it to run and we doesn't care where system will be in next two years" (in trashcan, usually - or it will act as a jumphost for another scam/DDoS). And I see such systems everyday. And that dramas, when I ask a simple question like: "how it will be upgraded"? "What is your plan about dealing with manually-installed python modules that overwrites files from system-installed ones when system upgrade will be performed?" and so on, and so on...
Fortunately a separate "devops" team that really cares about infrastructure reliability usually evolves into a normal sysadmins in no-time and their priorities are usually different that rest of "dev-teams".
BTW: there is another obstacle aside from typing issues: readability problems and similarities between operators and ordinary characters with computer fonts.
In case of manually written math equations (or LaTeX-ones) operators are easy distinguishable from arguments. They have a different sizes too.
For example, "result = axe" and "result = a×e" in many cases looks the same and, even in my browser, with font larger, than ones usually used by my colleagues, they are very hard to distinguish. Difference between "result a÷n" and "result a-b" can be spot easier, but it depends on two one-pixel dots.
Ok that was only a mumbling of malcontent - in fact we all know that we all have a sharp, young eyes and we never will be tired or distracted, I'm pretty sure of that. ;)
You are still a human. You are intelligent. Yes - you are, this is demonstrated by the ability to think critically and independence of your views. So - You are capable to adapt into new environment and into new tech. Search for anything and switch job. Don't wait for a toxic environment to destroy your confidence.