Live data from Hacker News

The highest quality codebase

gricha.dev

351–360 of 409 posts

Re: The highest quality codebase

#351

Earlier quoted context omitted.

> 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 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.

Re: The highest quality codebase

#352

Earlier quoted context omitted.

there are other ways: being scammed by lazy devs using AI to produce what devs normally do and not saving any money for the customer. i mentioned it in another thread, i heard first hand people say "i will never report how much time savings i get from gemini, at best i'll say 1 day a month"

If you produce the same product, then you get to ask for the same pay. That's not a scam. If enough people can make the product faster, then competition will drive the price down. But the ability to charge less is not at all an obligation to charge less.

it's paradoxical, the llm is not helping consumers, it's not helping the experienced engineer, it's helping a new class of devs that just want the easy way out. and ultimately this wave will make the price go down to the point the skilled dev won't be able to sustain long term growth because learning more and more advanced will not be valued by the economy.. just a thought but i don't see a nice path ahead now

Re: The highest quality codebase

#353
post #173
post #54

Earlier quoted context omitted.

I think we have different opinions on what's fun and what's boring!

You've really hit the crux of the problem and why so many people have differing opinions about AI coding. I also find coding more fun with AI. The reason is that my main goal is to solve a problem, or someone else's problem, in a way that is satisfying. I don't much care about the code itself anymore. I care about the thing that it does when it's done. Having said that I used to be deep into coding and back then I am…

I feel the same way when writing code for work. It's pretty neat to have an AI bot working on the grunt work for me while I review and write high level algorithms. It's quicker and I get less burnt out.

But I still love getting my hands dirty and writing code as a mental puzzle. And the best puzzles tend to happen outside of a work environment anyways. So I continue to work through advent of code problems (for example) as a way of exercising that muscle.

Re: The highest quality codebase

#354

Earlier quoted context omitted.

He means that it is heavily biased to write code, not remove, condense, refactor, etc. It wants to generate more stuff, not less.

Because there are not a lot of high quality examples of code edition on the training corpora other than maybe version control diffs. Because editing/removing code requires that the model output tokens for tools calls to be intercepted by the coding agent. Responses like the example below are not emergent behavior, they REQUIRE fine-tuning. Period. I need to fix this null pointer issue in the auth module. {"id": "call…

I'm not disagreeing with any of this. Feels kind of hostile.

Re: The highest quality codebase

#355

Earlier quoted context omitted.

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…

>> 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.

Re: The highest quality codebase

#356

Claude is really good at specific analysis, but really terrible at open-ended problems. "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. "Hey claude, anything I could do to improve Y?", and it'll struggle beyond the basics that a linter might suggest. It suggested enthusiastically a library for and it was all " Recommended " about it, but when I pointed out that the…

>> "Hey claude, I get this error message: ", and it'll often find the root cause quicker than I could. Back in the day, we would just do this with a search engine.

It's not the same. Recently Opus 4.5 diagnosed and fixed a bug in the F# compiler for me, for example (https://github.com/dotnet/fsharp/pull/19123). The root cause is pretty subtle and very non-obvious, and of course the critical snippet of the stack trace `at FSharp.Compiler.Symbols.FSharpExprConvert.GetWitnessArgs` has no hits on Google other than my own bug report. I would have been completely lost fixing it.

Re: The highest quality codebase

#357

Earlier quoted context omitted.

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…

>> 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…

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.

Re: The highest quality codebase

#358
post #319

Earlier quoted context omitted.

> The problem solving is in figuring out what to prompt, which includes correctly defining the problem, identifying a potential solution, designing an architecture, decomposing it into smaller tasks, and so on Coding is just a formal specification, one that is suited to be automatically executed by a dumb machine. The nice trick is that the basic semantics units from a programming language are versatile enough to giv…

I think you would be surprised by how much these AIs can "fill in the blanks" based on the surrounding code and high-level context! Here is an example I posted a few months ago (which is coincidentally, related to the reply I just gave the sibling comment): https://news.ycombinator.com/item?id=44892576 Look at the length of my prompt and the length of the code. And that's not even including the tests I had it generat…

I’m not surprised. It would be like being suprised by the favt that computers can generate a human portrait (which has been been a thing before LLMs), but people are still using 3d software because while it takes more time, they have more control over the final result.

Re: The highest quality codebase

#360

Earlier quoted context omitted.

>> 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…

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 rewri…

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.

Post reply on HN