The highest quality codebase

Maybe I'm weird but I enjoy "actually writing the code."

Me writing code is me spending 3/4 of my time wading through documentation and google searches. It's absolutely hell on my ADD. My ability to memorize is absolutely garbage. Throughout my career I've worked in like 10 different languages, and in any given project I'm usually working in at least 3 or 4. There's a lot of "now what is a map operation in this stupid fucking language called again?!"

Claude writing code gets the same output if not better in about 1/10 of the time.

That's where you realize that the writing code bits are just one small part of the overall picture. One that I realize I could do without.

May be a domain issue? If you're largely coding within a JS framework (which most software devs are tbf) then that makes total sense. If you're working in something like fintech or games, perhaps less so.

In my case, I enjoy writing code too, but it's helpful to have an assistant I can ask to handle small tasks so I can focus on a specific part that requires attention to detail

“I want my AI to do laundry and dishes so I can code, not for my AI to code so I can do laundry and dishes”

My last job was a mix of Ruby, Python, Bash, SQL, and Javascript (and CSS and HTML). One or two jobs before that it was all those plus a smattering of C. A few jobs before that it was C# and Perl.

Soon you'll realize you're the "AI". We've lost control.

How do you end up with 3 to 4 languages in one project?

Yeah, I sometimes use AI for questions like "is it possible to do [x] using library [y] and if so, how?" and have received mostly solid answers.

Typescript on the frontend, Python on the backend, SQL for the database, bash for CI. This isn't even counting HTML/CSS or the YAML config.

Claude is very good at unfun-but-necessary coding tasks such as writing docstrings and type hints, which is a prominent instance of "laundry and dishes" for a dev.

HTML, CSS, Javascript?

Just be careful if functionality varies between library y version 2 and library y version 3, or if there is a similarly named library y2 that isn't the same.

You may get possibilities, but not for what you asked for.

In my case, it really depends what. I enjoy designing systems and domain-specific languages or writing libraries that work the way I think they should work.

On the other hand, if e.g. I need a web interface to do something, the only way I can enjoy myself is by designing my own web framework, which is pretty time-consuming, and then I still need to figure out how to make collapsible sections in CSS and blerghhh. Claude can do that in a few seconds. It's a delightful moment of "oh, thank god, I don't have to do this crap anymore."

There are many coding tasks that are just tedium, including 99% of frontend development and over half of backend development. I think it's fine to throw that stuff to AI. It still leaves a lot of fun on the table.

Or “can you prototype doing A via approaches X, Y, and Z, and show me what each looks like?”

I love to prototype various approaches. Sometimes I just want to see which one feels like the most natural fit. The LLM can do this in a tenth of the time I can, and I just need to get a general idea of how each approach would feel in practice.

Oh my sweet summer child...

> Yeah, I sometimes use AI for questions like "is it possible to do [x] using library [y] and if so, how?" and have received mostly solid answers.

In my experience most LLMs are going to answer this with some form of "Absolutely!" and then propose a square-peg-into-a-round-hole way to do it that is likely suboptimal vs using a different library that is far more suited to your problem if you didn't guess the right fit library to begin with.

The sycophancy problem is still very real even when the topic is entirely technical.

Gemini is (in my experience) the least likely to lead you astray in these situations but its still a significant problem even there.

If you run to the point where you can execute each idea and examine its outputs, problems like that surface pretty quickly

> Sometimes I just want to see which one feels like the most natural fit.

This sentence alone is a huge red flag in my books. Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain.

There's a reason the field is called Software Engineering and not Software Art. Words like "feels" does not belongs. It would be like saying which bridge design feels like the most natural fit for the load. Or which material feels like the most natural fit for a break system.

I sometimes think of it as a sculptor analogy.

Some famous sculptors had an atelier full of students that helped them with mundane tasks, like carving out a basic shape from a block of stone.

When the basic shape was done, the master came and did the rest. You may want to have the physical exercise of doing the work yourself, but maybe someone sometimes likes to do the fine work and leave the crude one to the AI.

I would say notetaking would be a much bigger help than Claude at this point. There's a lot of methods to organize information that I believe would help you, better than an hallucination machine.

Recently I've been experimenting with using multiple languages in some projects where certain components have a far better ecosystem in one language but the majority of the project is easier to write in a different one.

For example, I often find Python has very mature and comprehensive packages for a specific need I have, but it is a poor language for the larger project (I also just hate writing Python). So I'll often put the component behind a http server and communicate that way. Or in other cases I've used Rust for working with WASAPI and win32 which has some good crates for it, but the ecosystem is a lot less mature elsewhere.

I used to prefer reinventing the wheel in the primary project language, but I wasted so much time doing that. The tradeoff is the project structure gets a lot more complicated, but it's also a lot faster to iterate.

Plus your usual html/css/js on the frontend and something else on the backend, plus SQL.

“Sorry, the autogenerated api documentation was wrong because the ai hallucinated the docstring”

I wouldn't call html, yaml or css languages.

Same for sql, do you really context switch between sql and other code that frequently?

Everyone should stop using bash, especially if you have a scripting language you can use already.

Notetaking with ADHD is another sort of hell to be honest.

I absolutely can attest to what parent is saying, I have been developing software in Python for nearly a decade now and I still routinely look up the /basics/.

LLM's have been a complete gamechanger to me, being able to reduce the friction of "ok let me google what I need in a very roundabout way my memory spit it out" to a fast and often inline llm lookup.

> There's a reason the field is called Software Engineering and not Software Art. Words like "feels" does not belongs.

Software development is nowhere near advanced enough for this to be true. Even basic questions like "should this project be built in Go, Python, or Rust?" or "should this project be modeled using OOP and domain-driven design, event-sourcing, or purely functional programming?" are decided largely by the personal preferences of whoever the first developer is.

Of course, by that time i could have read the docs for library y the version I'm using...

This sums up my feelings almost exactly.

I don't want LLMs, AI, and eventually Robots to take over the fun stuff. I want them to do the mundane, physical tasks like laundry and dishes, leave me to the fun creative stuff.

But as we progress right now, the hype machine is pushing AI to take over art, photography, video, coding, etc. All the stuff I would rather be doing. Where's my house cleaning robot?

Dude have you even written any hardcore SQL? plpgSQL is very much a turing-complete language

There are many roads to Rome...

>writing docstrings and type hints

Disagree. Claude makes the same garbage worthless comments as a Freshman CS student. Things like:

// Frobbing the bazz

res = util.frob(bazz);

Or

// If bif is True here then blorg

if (bif){ blorg; }

Like wow, so insightful

And it will ceaselessly try to auto complete your comments with utter nonsense that is mostly grammatically correct.

The most success I have had is using claude to help with Spring Boot annotations and config processing (Because documentation is just not direct enough IMO) and to rubber duck debug with, where claude just barely edges out the rubber duck.

For example sometimes you're faced with choosing between high-quality libraries to adopt and it's not particularly clear whether you picked the wrong one until after you've tried integrating them. I've found it can be pretty helpful to let the LLM try them all and see where the issues ultimately are.

I intentionally said docstrings instead of comments. Comments by default can be verbose on agents but a line in the AGENTS.md does indeed wrangle modern agents to only comment on high signal code blocks that are not tautological.

Well it would be funnier if dishwashers, washing machines and dryers didn't automate that ages ago. It's literally one of the first things robots started doing for us.

3 or 4 can very easily accumulate. For example: HTML, CSS as must know, plus some JS/TS (actually that's 2 langs!) for sprinkles of interactivity, backend in any proper backend language. Oh wait, there is a fifth language, SQL, because we need to access the database. Ah and those few shell scripts we need? Someone's gotta write those too. They may not always be full programming languages, but languages they are, and one needs to know them.

Looking up documentation is normal. If not, we wouldn't have the manual pages in Unix and such an emphasis on documentation in ecosystems like Lisp, Go, Python, Perl,... We even have cheatsheets and syntax references books because it's just so easy to forget the /basics/.

I said notetaking, but it's more about building your own index. In $WORK projects, I mostly use the browser bookmarks, the ticket system, the PR description and commits to contextually note things. In personal projects, I have an org-mode file (or a basic text file) and a lot of TODO comments.

I would like to go even further and say: Those things, art, photography, video, coding ... They are forms of craft, human expression, creativity. They are part of what makes life interesting. So we are in the process of eliminating the interesting and creative parts, in the name of profit and productivity maxing (if any!). Maybe we can create the 100th online platform for the same thing soon 10x faster! Wow!

Of course this is a bit too black&white. There can still be a creative human being introducing nuance and differences, trying to get the automated tools to do things different in the details or some aspects. Question is, losing all those creative jobs (in absolute numbers of people doing them), what will we as society, or we as humanity become? What's the ETA on UBI, so that we can reap the benefits of what we automated away, instead of filling the pockets of a few?

Such questions may be decided by personal preferences, but their impact can easily be demonstrated. Such impacts are what F. Brooks calls accidental complexity and we generally called technical debt. It's just that, unlike other engineering fields, there are not a lot of physical constraints and the decision space have much more dimensions.

> sometimes you're faced with choosing between high-quality libraries to adopt and it's not particularly clear whether you picked the wrong one until after you've tried integrating them.

Maybe I'm lucky, but I've never encountered this situation. It has been mostly about what tradeoffs I'm willing to make. Libraries are more line of codes added to the project, thus they are liabilities. Including one is always a bad decision, so I only do so because the alternative is worse. Having to choose between two is more like between Scylla and Charybdis (known tradeoffs) than deciding to go left or right in a maze (mystery outcome).

> Such questions may be decided by personal preferences, but their impact can easily be demonstrated.

I really don't think this is true. What was the demonstrated impact of writing Terraform in Go rather than Rust? Would writing Terraform in Rust have resulted in a better product? Would rewriting it now result in a better product? Even among engineers with 15 years experience you're going to get differing answers on this.

Sorry for being pedantic, but what does the "L" stand for in HTML, YAML, SQL? They may not be "programming languages" or, in the case of SQL, a "general purpose programming language", but they are indeed languages.

The impact is that now, if you want to modify the project in some way, you will need to learn Go. It's like all the codebases in COBOL. Maybe COBOL at that time was the best language for the product, but now, it's not that easy to find someone with the knowledge to maintain the system. As soon as you make a choice, you accept that further down the line, there will be some X cost to keep going in that direction and some Y cost to revert. As a technical lead, more often you need to ensure that X or/and Y don't grow to be enormous.

It probably depends on what you're working on. For the most part relying on a high-quality library/module that already implements a solution is less code to maintain. Any problems with the shared code can be fixed upstream with more eyeballs and more coverage than anything I build locally. I prefer to keep my eyeballs on things most related to my domain and not maintain stuff that's both ultimately not terribly important and replaceable (if push comes to shove).

Generally, you are correct that having multiple libraries to choose among is concerning, but it really depends. Mostly it's stylistic choices and it can be hard to tell how it integrates before trying.

> The impact is that now, if you want to modify the project in some way, you will need to learn Go.

That's tautologically true, yes, but your claim was

> Either you know the problem domain and can argue about which solution is better and why. Or you don't and what you're doing are experiment to learn the domain.

So, assuming the domain of infrastructure-at-code is mostly known now which is a fair statement -- which is a better choice, Go or Rust, and why? Remember, this is objective fact, not art, so no personal preferences are allowed.

IME this has been significantly reduced in newer models like 4.5 Opus and to a lesser extent Sonnet, but agree it's still sort of bad- mainly because the question you're posing is bad.

if you ask a human this the answer can also often be "yes [if we torture the library]", because software development is magic and magic is the realm of imagination.

much better prompt: "is this library designed to solve this problem" or "how can we solve this problem? i am considering using this library to do so, is that realistic?"

i find it's pretty rare to have a project that only consists of one or two languages, over a certain complexity/feature threshold

You really get enjoyment writing a full CRUD HTTP API five times, one for each endpoint?

I don't :) Before I had IDE templates and Intellisense. Now I can just get any agentic AI to do it for me in 60 seconds and I can get to the actual work.

This is the thing. I _know_ what the correct solution looks like.

But figuring out what is the correct way in this particular language is the issue.

Now I can get the assistant to do it, look at it and go "yep, that's how you iterate over an array of strings".

Go for the backend, something javascripty for the front end. You're already at two. Depending if you count HTML, CSS or SQL as "languages", you're up to a half dozen pretty quick.

You can't read?

Please don't say you commit AI-generated stuff without checking it first?

Do you develop software? Software unlike any physical engineering field. The complexity of any project beyond the most trivial is beyond human ability to work with. You have to switch from analytic tools to more probabilistic tools. That where "feels", "smells", or "looks" come in. Software testing is not a solved problem, unlike bridge testing.

So many FOSS software are made and maintained by a single person. Much more are developer by a very small teams. Probabilistic aren’t needed anywhere.

And all that take rote mechanical work. Which can quickly lead to fractured focus and now suddenly I'm pulled out of my flow.

Or I can farm that stuff to an LLM, stay in my flow, and iterate at a speed that feels good.

Neither. Because the solution for IaC is not Go or Rust, just like the solution for composing music is not a piano or a violin.

A solution may be Terraform, another is Ansible,… To implement that solution, you need a programming language, but by then you’re solving accidental complexity, not the essential one attached to the domain. You may be solving, implementation speed, hiring costs, code safety,… but you’re not solving IaC.

It is very hard to explain the extent of it to a person who did not experience it, really.

I have over a decade of experience, I do this stuff daily, I don't think I can write a 10 line bash/python/js script without looking up the docs at least a couple times.

I understand exactly what I need to write, but exact form eludes my brain, so this Levenshtein-distance-on-drugs machine that can parse my rambling + surrounding context into valid syntax for what I need right at that time is invaluable and I would even go as far as saying life changing.

I understand and hold high level concepts alright, I know where stuff is in my codebase, I understand how it all works down to very low levels, but the minutea of development is very hard due to how my memory works (and has always worked).

> So, assuming the domain of infrastructure-as-code is mostly known now which is a fair statement -- which is a better choice, Go or Rust, and why? Remember, this is objective fact, not art, so no personal preferences are allowed.

I think it’s possible to engage with questions like these head on and try to find an answer.

The problem is that if you want the answer to be close to accurate, you might need both a lot of input data about the situation (including who’d be working with and maintaining the software, what are their skills and weaknesses; alongside the business concerns that impact the timeline, the scale at which you’re working with and a 1000 other things), as well as the output of concrete suggestions might be a flowchart so big it’d make people question their sanity.

It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation.

But to humor the question: as an example, if you have a small to mid size team with run of the mill devs that have some traditional OOP experience and have a small to mid infrastructure size and complexity, but also have relatively strict deadlines, limited budget and only average requirements in regards to long term maintainability and correctness (nobody will die if the software doesn’t work correctly every single time), then Go will be closer to an optimal choice.

I know that because I built an environment management solution in Go, trying to do that in Rust in the same set of circumstances wouldn’t have been successful, objectively speaking. I just straight up wouldn’t have iterated fast enough to ship. Of course, I can only give such a concrete answer for that very specific set of example circumstances after the fact. But even initially those factors pushed me towards Go.

If you pull any number of levers in a different direction (higher correctness requirements, higher performance requirements, different team composition), then all of those can influence the outcome towards Rust. Obviously every detail about what a specific system must do also influences that.

What I'm saying is that is normal. Unless you've worked everyday with the same language and a very small set of functions, you're bound to forget signature and syntax. What I'm advocating is a faster retrieval of the correct information.

Why do you need a full crud http api for? Just loading the data straight from the database? Usually I've already implemented that before and I just copy paste the implementation and doing some VIM magic. And in Frameworks like Rails or Laravel, it may be less than 10 lines of code. More involved business logic? Then I'm spending more time getting a good spec for those than implementing the spec.

>Unless you've worked everyday with the same language

...I did.

> Neither.

> A solution may be Terraform

They're asking about what language you use to write Terraform.

It's not accidental complexity, it's what the question is about.

> It’s not impossible, just impractical with a high likelihood of being wrong due to bad or insufficient data or interpretation.

If it's impractical to know, why is using personal preference and intuition a "huge red flag"?

That's the core idea being disagreed with, not the idea that you could theoretically with enough resources get an objective answer.

It might be because depending on one's sensitivity to various factors and how much work they put into discovering the domain, things might feel okay, and yet be the completely wrong choice.

For example, how to many people MongoDB felt like a really good option during its hype cycle before it became clear how there are workloads out there, where you will get burnt badly if you pick anything other than a traditional RDBMS with ACID.

Similarly, there are cases where people cargo cult really hard or just become opinionated over time - someone who has worked primarily in Java for 20 years will probably pick that for a wide variety of projects, though this preference might make them blind to the fact that others aren't as good with it on a given team and that they might not iterate fast enough to ship, when compared with, let's say Django or Ruby on Rails or even Laravel.

Feelings can be dangerous, informed choices will generally be better, though I guess with the way we use language, those two kinda blend together. If those feelings are based on good enough data and experience, then those might be pretty valuable too - someone who has been writing code for 20 years will probably be more accurate than someone who has been programming for 2 years, yet if someone has 10x2 years of experience (doing the same thing, not learning, not exploring), then it's a toss up, worse yet if people think that still means seniority.

I kinda get why someone might react to the word "feels" in seemingly deterministic development context, but my own reaction wouldn't be so strong and with certain people, I'd trust their feelings. At the same time I've seen plenty of people who write what they believe to be a good code that is a bit of a mess in my eyes.

It’s very much accidental complexity. As the sibling comment to my previous comment said, the choice of a language does not depend on Terraform design, but on contextual information like the team skill, business requirements like time delivery and implementation correctness. None of which really impacts the design of Terraform as a solution. Just like SMTP or Posix tools does not care about the language.

If you're talking about the topic, it's not accidental, it's mandatory, because you have to write Terraform in something.

The topic is not how you use Terraform or at a high level design its features, it's how you implement Terraform with code.

> the choice of a language does not depend on Terraform design, but on contextual information like the team skill, business requirements like time delivery and implementation correctness

That doesn't make it accidental to the topic. It may be accidental to a different topic (the design of Terraform?) that nobody was discussing, but it's not accidental to this topic (language choice).

That list of factors is how you get closer to making the decision.

>> So, assuming the domain of infrastructure-at-code is mostly known now which is a fair statement -- which is a better choice, Go or Rust, and why?

This was the question. And my answer was that Go or Rust have no relevancy in the IaC domain. Ansible is relevant, but Python is not. Chef is relevant, Ruby is not. And I’m pretty sure there are in-house stuff that are just Perl scripts.

The goal is solving some problem in IaC, by the time, you are considering language choice, you’ve already left the domain and are looking at implementation problems where each choice is balancing tradeoffs.

Context. That wasn't the original question. That's a short restatement of the real question which is up in an earlier post:

>> Such questions may be decided by personal preferences, but their impact can easily be demonstrated.

> I really don't think this is true. What was the demonstrated impact of writing Terraform in Go rather than Rust? Would writing Terraform in Rust have resulted in a better product? Would rewriting it now result in a better product? Even among engineers with 15 years experience you're going to get differing answers on this.

And I’ve already answered that question. One of the main impact is that if you want a contributor to the codebase, the person have to learn Go. Even if they have good knowledge of the domain and are proficient in Rust. There would be some cost associated to training that person in Go (it may be small).

Rewriting from Go to another language wouldn’t solve the problem better. Because Go is an implementation choice, not a design choice. There’s nothing in Go that make Terraform better. It could be in C and a lot of people wouldn’t notice.

> And I’ve already answered that question.

You somewhat answered it in a way that doesn't really get to why they asked it (you can't make every decision based on "demonstrated impact").

But you did that in a different comment than the one I replied to. The one I replied to was just answering the wrong question entirely. Which is why I replied.

> Rewriting from Go to another language wouldn’t solve the problem better. Because Go is an implementation choice, not a design choice. There’s nothing in Go that make Terraform better. It could be in C and a lot of people wouldn’t notice.

I'm sorry, are you arguing that using feel to decide how to structure a piece of code is a "huge red flag", but the choice of entire programming language is unimportant?

> I'm sorry, are you arguing that using feel to decide how to structure a piece of code is a "huge red flag", but the choice of entire programming language is unimportant?

From my first reply, I've been arguing that using feels to decide things is very much dangerous. There are usually a less ambiguous way to frame the reasons behind a decision. Methodologies like the five why's can help.

And choosing a programming language is orthogonal to designing a solution to a problem. Everything get turned to opcodes and binary at some point.