While that might be true, the more one equips LLMs for building the less one will be capable of keeping LLMs “on a shorter leash with focused goals” in the long run
I used to think that there's a a room for better C -> Some unrelated complains about Rust and Go -> C has footguns, but they don't matter that much because I choose to not write my code myself anymore -> Therefore there's no room for better C.
Quit about a month ago after working at my last place for two years. It was a decent job before the agent psychosis became widespread, from that moment everyone in the company went insane and the pressure to use "advanced agentic engineering" became unbearable. Also, most engineers in the company supported and were enthusiastic about that trend, so I was in a minority.
I don't have much savings on me, but I'd rather go frugal and downshift than be producing slop for a living.
An online product that was brought into existence by processing all the open source software in the world and makes money by selling the resulting knowledge base, should be accessible free of charge by the producers of that open source software.
I was very excited about Rust prior to the LLM-era. I never managed to dive deep into it due to the lack of time, but was really planning to.
Nowadays when everyone and their dog are either vibe-coding with Rust or constantly shouting about it's superiority, I've lost any interest in the language. I'm learning Zig.
Feel the same way about the intersection of Rust evangelists and vibe coders. The amount of undeserved arrogance by some hardcore believers is toxic to their culture. I am learning Rust, because there is merit to the language itself, and there are some useful and quality codebases written in it. But it's imperfect in various ways, most of all the evangelists attacking other languages as inferior and unsafe, and the increasingly common massive vibe-coded monstrosities. It's not that I'm against the use of LLMs, I'm against bad engineering practices and unmaintainable code.
Zig, on the other hand, is a breath of fresh air. There's so much to love about it, including language design that values clarity and simplicity, and the cross-compiler which is how I got started on it, by using Zig as a better build system for C projects. Their move away from GitHub and vibe-coded contributions is also commendable, it's more reason I trust their sensible judgement.
Interesting choice when LLMs remove one of the biggest barriers to entry for Rust which is you have to know almost all the rules to reliably make valid changes to Rust programs (which also helps LLMs at inference time when they make mistakes).
It's not about if the entire community is weird. But that a few vocal people doing something becomes the first impression of the ecosystem. Which is turning people off from exploring further, as you can see in this thread.
You can make the case that if something like this turns you off from diving deeper into the language you probably weren't that motivated to begin with. But it is a noticable effect. This post isn't the first time I see it either. Rust has become a meme amongst my colleagues because things keep popping up with "Build with Rust" before mentioning anything of substance of the project. The phrase "Did you know Rust is memory safe?" is also a running joke in my IRL dev surroundings now.
I mean, yeah... but I bet if Zig gets really popular, it will attract similarly toxic weirdoes.
Also if we're only judging whole communities by their toxic minorities, then... I'm so sorry Americans reading this, I've got some bad news for you, lol
What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
> What I'm trying to say is, it's best to try <a thing> for yourself, and see if it fits your preferences, rather than letting others stop you from exploring.
Yes, that is the rational thing to do. I don't think anybody disagrees with that. But that's not how a lot of people go throughout their day. There are a gazillion languages to pick up nowadays, and I think many experienced devs only have a casual interest in picking up a new one. If you've been interested in picking up a system language, I can easily see why you would steer away from Rust towards Zig.
And just to clarify here. You shouldn't judge an entire community based on their toxic minority. But as a community, you can't also ignore your toxic minority. Like it or not, they do represent you. And they do scare away potential newcomers who aren't already sold on the language.
I have seen developers and managers having an attitude of arrogance just because they happen to code in a specific language. They also look down upon other developers just because they happen to code in some other language. Evangelism combined with arrogance is toxic.
Reminds me of a colleague who rewrote the entire standard template library from scratch to demonstrate his uber-templating knowledge. He was the only one who could debug problems in that. The rest of us were ordinary c++ coders.
I've always found juniors to be the most prone to being "clever". Writing complex things for the sake of it. And it's one of the things I think you need to get over if you want to be considered medior/senior. A senior that loves being clever in an actual product is dangerous. Keep that stuff for hobby projects.
At a web agency I used to work at this was definitely a thing we had to teach the juniors. Whatever you built now is going to end up in maintenance with a support team that doesn't have as deep of an understanding of the project. Being overly clever now is going to be a pain in the ass later.
"Keep It Simple, Stupid" is an important skill for a professional.
Defined structure does not constitute quality. A commit message can be loosely structured, but be very insightful and good at communicating the nature of the change. On the flip side, one can make a very structured but confusing or non-informative commit message.
I generally tend to agree with the author, conventional commits do not solve the core issue of the poor commit messages problem.
Conventional commits made it easier to generate changelogs and automate semantic version bumps. I suppose LLMs can usually do that the right way with looser structure, but in the before times it made a lot more sense, and even now is much less ambiguous
They're hand-waved away by saying the changelogs are bad and the semver isn't always accurate. While I mostly agree with, that doesn't mean they don't provide _some_ value. You get categorized changelogs (even if the messages are technical) and semver that's generally correct. The alternative of good changelogs and perfect semver isn't free.
It’s the linting argument all over again. I don’t give a shit what the style is. I give a shit that it’s consistent. Form whatever opinion you want about how you want to format your code, structure commit messages etc. I don’t really care, if you want to start every commit with “poop(fix): pooper my commit message”, as long as you’re consistent about it and enforce it programmatically you have my emphatic support
This comment assumes you are picking between a conventional commit message or something better. But the reality is you are almost always picking between a conventional commit and Nothing.
That is only true of semantically equivalent things.
Tabs vs spaces don't matter they are equivalent.
But consistency is only better when it is an improvement.
It is fundamentally important that convential commit is better for adopting it to be an improvement.
After all in your example wasting the first four characters of your commits with poop would objectively reduce the quality of your commit history, whether or not it was consistent.
> It is fundamentally important that convential commit is better for adopting it to be an improvement.
Absolutely! Which means we can also agree that conventional commit is objectively better than No System For Their Commits At All, which is what 99.9% of people are actually choosing between when evaluating conventional commit. They aren’t looking at conventional commit vs Some Better Way, they are looking at “we have no standardization of commit messages” vs “we have standardization of commit messages”.
For the 0.1% people for whom that’s not good enough, one hundred percent agree that these people should be pursuing better solutions.
> Tabs vs spaces don't matter they are equivalent.
Just to nitpick (because what else is this thread about? :))
They aren't equivalent! Tabs carry more semantic information than spaces. 1 Tab character == 1 Level of nesting
Space-based systems _can_ provide the equivalent semantic information if they are 100% consistent.
...but part of the argument in favor of spaces is that they allow an escape hatch of the strict indentation in order to allow pleasing visual alignments.
why is "solving" the issue somehow the bar? software engineering has more practices rooted in psychology than engineering, its a moving and ambiguous target. Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.
In what context does wasting your first characters on fix vs feat matter?
PRs are going to have an explanation that has way more detail than necessary to figure that out quickly.
One lines tend to be (for me) in a situation where the difference is immaterial. If I am rapid firing through history I need to know what you did not why you did it.
Again I am not claiming that these are bad or even that they aren't good.
I am specifically disagreeing that any change is automatically good, that isn't true.
> Using conventional commits gives you a framework and mechanism that undoubtedly improves contribution semantics.
I do not want to contribute to a project using conventional commits. I have consistently found, that I am unable to decide what the "type" of a commit even is and I feel unnaturally caged in into how I would split up commits, by having them be restricted to types (it doesn't help that the conventional commits I've seen appear to decide the type by fair dice roll).
Discouraging contributions does not "undoubtedly improve contribution semantics".
- Make systems as observable as possible. Stuff will break, the easier it is to identify the cause, the better. Logging things at different program flow points helps immensely.
- Question every decision in the codebase you are working on, but thoroughly weigh any refactoring attempts
- Don’t fall in love with own code
- Prefer readability over performance (in most cases)
- Don’t follow trends blindly. More than likely your boring stack is the best way to go
- Allow room to recover from a malformed system state
- Don’t abstract prematurely. If you struggle with designing your abstractions, you are probably good with concrete case(s) for now
I transitioned to being a software engineer after 8 years in investment banking. Some people mention capitalizing on existing skillset and trying to find opportunities on your skills intersection. While this is certainly an attractive strategy, imo this only works if you still love at least some parts of your existing career.
In my case, I absolutely hated investment banking and this career and my Finance degree were wrong choices that I just didn’t want to admit to myself.
I started thinking what I used to enjoy doing before university and I realized that I always loved computers and even programmed a good amount of Visual Basic and Pascal back in days.
As for the transitioning process, I took the radical approach. I first combined learning to code (again) with my job but it was very difficult. So I saved 6 month living expenses, quit my job and locked myself in my apartment for studying. Ran out of funds before getting enough knowledge to land an actual job. Took side hustles from my previous career for about 2 years to continue learning. Eventually managed to land a job paying 25% of my past salary. But once I got into the industry, I grew rather quickly because of how motivated I was compared to my previous career.
The moral of the story is, if you feel like there’s something that is much better suited to your personality, it’s okay to start from scratch. It will be painful for sure, but the pain is temporary compared to a lifelong feeling of being miserable on a wrong path.
