But Go culture promulgates this practice of repeating boilerplate. In fact this is one of the biggest confusion points of new gophers. "I want to do a thing that seems common enough, what library are you all using to do X?". Everyone scoffs, pushes up their glasses and says, "well actually, you should just use the standard library, it's always worked just fine for me". And the new gopher is confused because they really believe that reinventing the wheel is an acceptable practice. This is what leads to using LLMs to write all that code (admittedly, it's a fine use of an LLM).
I've used this as a chance to turn things back around on the recruiters. "That's a great question and I noticed you didn't mention a salary range on the posting". Allow for an uncomfortable silence as now they're either forced to give a range, or try to say something like, "it's flexible for the right candidate". The latter is my opportunity to agree, "Of course, let's concentrate on that question then, I'd sure like if we could get to the bottom of this 'right candidate' question".
No, don't let them get off the hook with "it's flexible for the right candidate", especially if you are talking to a recruiter (either internal or external).
That "flexibility" will suddenly disappear if your expectations are higher than they are looking to pay for the role, even if your expectations are completely warranted.
We can see this effect from Mitchell's own release of his terminal emulator (Ghostty). It was invite-only. The in-crowd on YouTube/Twitter lorded it over others as a status symbol. None of it was based on actual engineering prowess. It was more like, "hey, you speak at conferences and people follow you on social media... you must be amazing".
I think I can get on board with this view. In the earlier LLM days, I was working on a project that had me building models of different CSV's we'd receive from clients. I needed to build classes that represented all the fields. I asked AI to do it for me and I was very pleased with the results. It saved me an hour-long slog of copying the header rows, pasting into a class, ensuring that everything was camel-cased, etc. But the key thing here is that that work was never going to be the "hard part". That was the slog. The real dopamine hit was from solving the actual problem at hand - parsing many different variants of a file, and unifying the output in a homogenous way.
Now, if I had just said, "Dear Claude, make it so I can read files from any client and figure out how to represent the results in the same way, no matter what the input is". I can agree, I _might_ be stepping into "you're not gonna understand the software"-land. That's where responsibility comes into play. Reading the code that's produced is vital. I however, am still not at the point where I'm giivng feature work to LLMs. I make a plan for what I want to do, and give the mundane stuff to the AI.
Yup, agents LOVE Tailwind+ShadCN. Even when I've explicitly told them not to use it, it still creeps in. There's a lot of prior art out on GitHub and LLMs can't help themselves. FWIW, the result does tend to look nice enough. For a POC I can't complain. If I'm really going to roll up my sleeves and get into the code though? I don't think I'd enjoy all of it.
They hype-train on all of this stuff is unreal. React+NextJS+Tailwind+ShadCN is just a mess. It's complexity piled on deeper complexity - for little gain! But suggest any of that in many circles and you'll get the standard, "skill issu bro" comebacks. Say what you want about Remix/ReactRouter 7 (there are plenty of issues to talk about there) but at least those guys _tried_ to stay closer to existing web standards. I could go on and on about the disaster of NextJS caching. I could point out RSCs being one way to solve a problem that could already be solved by loaders in other frameworks....
Tailwind was my moment of saying, "Nope, I'm gonna sit this one out". I have a few trusted friends that assure me I'm missing out. I've told them to come back to me after they've done their first major refactor. If they tell me it was a pleasant experience, I'll have another look.
AirBnB doesn't use this config and you probably shouldn't either. Much of this was based on Jordan Harband's opinions in 2016. He's likely changed his mind since then. Perhaps not. But I bet he'd tell you to do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter.
> do your own profiling and consider your own targets before blindly accepting a one-size-fits-all configuration for your linter
Too bad ESLint has been recommending airbnb as the style until 2024. You can't expect everyone to start with nothing and hand pick every rule themselves. Doable for a large organization, not possible for a personal project.
This was added to the language 10 years ago. So while it's "newer" than a plain old for-loop, it's definitely not "new". It was designed to work with Symbol.iterator. This is the mechanism whereby one can iterate anything that implements the Symbol.iterator interface.
As far as why folks won't just do simple for-loops, it's the same reasining every language tends to implement a "foreach", because there are annoying off-by-one errors lurking in the < vs <=. Of course one could argue that developers should be smart enough to handle this. But that's an argument even older than for-loops.
These barely if ever happen for simple iterations, it's an idee fixe. Off-by-one sneak in when trying to do something special, and then a for-on loop is useless anyway.
> Symbol.iterator interface
I get it, but it's unnecessary abstraction to overgeneralize a vanilla array to an iterable.
anyway, for..of is not an issue, it's alright. I think if there's one main point i'm trying to make, is that devs will write objectively worse code base on gut wants (in this case, obsession to use higer level abstractions to iterate over an array).
I can give an anecdote if that's helpful. Imagine you're wanting to download an object from S3. You start to type out the command in your CLI. You hit enter, only to realize, see that the object is not found. You have a typo somewhere... but where? The bucket is huge so, you resort to listing the contents and passing the results through grep. Then you copy the object to the clipboard so that you can edit your original command.
I see one of the other comments mentions K9s. The exact same use cases manifest with that tool. YES, if it's just a one-shot, nothing beats the CLI. Many things where you need to investigate the resources a bit more, lend themselves to a TUI (or GUI if that's your thing).
I come from an era where folks could fly through tasks on dumb terminals. (AS/400 apps). The moment we gave them "better" gui tools, they slowed way down. No matter how many times we told them, "you can still use your TAB and ENTER keys!" TUIs were just a sweet spot.
reply