> 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.
> 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.
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.
> 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.
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.
> 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.
> 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.
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.
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’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.
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.
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.
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.
> 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).
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.
A lot of patterns only make sense in languages like C# or Java, which are inflexible by design. You have two hierarchical trees (inheritance and namespaces) that you have to work around. With something simpler like C, Go, JavaScript, you don’t have those obstacles and a solution can be way simpler to implement.
Some patterns in the GoF book only apply to C++/Java as they were in 1994, but I don't see any reason why other languages would have no useful patterns. The Linux kernel (C) is full of patterns for example.
Funny thing, Peter Norvig also has this position, that patterns only apply to languages like Java, but his book on Lisp and the Python course he had on Udemy (?) are super-pattern-y.
I went from Java to Go for my last job. I think there is a reduction in pattern stuff but there are still many (at least in my project).
Java is kind of "begging" for patterns IMO, with all its static package protected final stuff and beliefs around encapsulation. Go is plainer, which is to its benefit.
How do optional inheritance and namespaces (which you can ignore to use a single global namespace) make a language inflexible? If anything, these traits make your language more powerful, not less.
Is it archaic? A lisp program is a dynamic image. A collection of symbol is very aptly named a package. And third party module can be named as a system (collection of packages).
Agreed, and I think package as used by Common Lisp and Java is more common than “namespace” which the parent commenter believes is the modern word for that!
Pretty much the same. And it's not even about improving the code (which I did), but mostly about removing dead code and duplicated code. Or worse, half redesigns of some subsystem which led to very bizarre code.
When people say coding is slow, that usually means they're working on some atrocious code (often of their own making), while using none of the tools for fast feedback (Tests, Linters,...).
> but you'll have to sit and read those docs, potentially for hours (cost of task switching and all).
That is one of the assumptions that pro-AI people always bring. You don't read the new docs to learn the domain. As you've said, you've already learn it. You read it for the gotchas. Because most (good) libraries will provide examples that you can just copy-paste and be done with it. But we all know that things can vary between implementations.
> Even as a skeptic of the general AI productivity narrative, I can see how that could squeeze a week's worth of "ever postponed" tasks inside a day.
You could squeeze a week inside a day the normal way to. Just YOLO it, by copy pasting from GitHub, StackOverflow and the whole internet.
> I frequently work with Copilot and Claude Sonnet, and it can be useful, but trusting it to write code for anything moderately complicated is a bad idea
This sentence and the rest of the post reads like an horoscope advice. Like "It can be good if you use it well, it may be bad if you don't". It's pretty much the same as saying a coin may land on head or on tail.
I taught myself programming, drawing, and 3d modeling on the internet. But it was on platforms like SiteDuZero and various forums. Even today, if you go on something like https://bbs.archlinux.org , it's very hard to land on something like the cesspool the homepage of YouTube and X can be.
well i’m sorry some kids (and adults) are idiots who enjoy brain rot, but i would have been pissed as a kid if the adults came for my intellectual communities because some kids are morons
When people talk about IDEs, there’s almost always an hidden assumption that they are referring to something like Visual Studio or IDEA (VS Code is a lesser version of these). But no comparison has ever been made to Smalltalk, or REPL development like Slime. There’s not even a mention of programmable editors like VIM and Emacs which can leverage the Unix OS environment.
Ultimately, LLMs are a text focused technology (actually tokens). And if you take something like Smalltalk, Acme, Unix Shell (with Vi and other editors), Emacs (as a lisp machine), they are all interfaces that focus on text manipulation. And they all provide the most important capability, defining custom commands on the fly. Some IDEs allows you to define custom tools, but none make it as convenient as the above.
If we take Unix, you could have something in `~/ai/bulletify` which start with:
#!/usr/bin/env llm-cli
[prompt text]
And quickly execute it with `:!bulletify` in Vi (with the needed motion). Pretty much the same in emacs, and you can either bind it to have a faster way to invoke it. Most IDEs is about having commonly useful utilities and features bound to the concept of a project. They don't do really well in a very dynamic environment.
And Editors like VS Code and Sublime is very much a basic version of the IDE. They're familiar, but they're not that fluid.
Oh? I've had great luck with LLMs and homemade ILs. It has become my favourite trick to get LLMs to do complex things without overly complicating my side of the equation (i.e. parsing, sandboxing, etc. that is much harder to deal with if you have it hand you the code of a general purpose language meant for humans to read).
There is probably some point where you can go so wild and crazy with ideas never seen before that it starts to break down, but if it remains within the realm of what the LLM can deal with in most common languages, my experience says it is able to pick up and apply the same ideas in the IL quite well.
People are still confusing AI putting together scraps of text it has seen that correlates with its understanding of the input, with the idea that AI understands causation, and provides actual answers.
And people are also still clearly confusing "isn't human or conscious" with "can't possibly create new logical thoughts or come to new logical conclusions i.e. do intellectual labor" when there is a plethora of evidence at this point that the latter is, in fact, the truth
I'm not sure if you mean that as a dig, or not, but if you are referring to me then I have these data points to discuss.
1. I have encountered a problem where AI will suggest 4 different "solutions" and when I point out a problem with one, it cycles on to the next, and stays in that loop, repeating over and over that set of 4, with no recollection of the previous refutation of the soltuion (this is a mix of context retention, and the fact that the solution selection is limited to that which has already been fully explored on the web - I had a 5th idea in mind which the AI failed to understand, but worked well)
2. Yesterday I was discussing with AI the fact that I had three options for action, and it misunderstood that as 4 actions, a trivial arithmetic failure.
This demonstrates (clearly) that the AI didn't "understand" the points discussed, and was instead staying with the correlation of text with other text.
I really like where AI is at the moment and use it a lot - it's very helpful for debugging, for example, but as every vibe coder out there will attest, AI fails hard at standalone coding, and I submit that this is a symptom of its inability to understand what its doing.
It's still correlation is not causation, and it demonstrates why correlation is so attractive, you can get quite far knowing that there is a correlation between ice cream sales and shark attacks, but it takes work to understand that there is no causative link (FTR I suspect that it's because ice cream sales go up in hot weather, more people are in the ocean during those hot weather periods, therefore there's more opportunity for people to interact with sharks)
Edit: Note how I use the word "suspect" when I talk about the cause of the correlation - it's VERY tempting to say that the weather is the cause, but that's still a correlation, and the fact is, as humans have discovered, actual research is required to verify whether that is, indeed, the cause, or not - something AI might miss.
Another data point has just arisen - I have a function (in Go) that accepts an unpacked slice of `interface{}` (some people will now call that an unpacked slice of `any`)
I was calling that function with an unpacked slice of string - eg
The AI I was using (Claude for the purposes of this discussion) incorrectly told me that I first needed to convert the slice of string to a slice of interface before calling the function
It argued with me when I said that I didn't and demanded I TIAS to prove its point, and report the compile time errors
Of course, I did, and there were no errors
The issue was that the AI (Claude) did not understand that `interface{}` or `any` means that any type can be used there.
Claude is doing a fantastic job, but this is an example of it not actually understanding what's happening.
It is trained on WASM btw, but if we invented one specific for it, it could easily be trained up on it or refined with it. I've already had some success just handing it a language guide and it runs with it.
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.
reply