Personally I find Rust a lot harder to read than Go.

If you're going to have an agent write most of your code readability is very important.

▲ _verandaguy 11 hours ago | parent | next [-]

I'll qualify this from my POV (which may be different than GP's).

Go's historic maintainability strong suit has been its simplicity and consistency. The syntax is, relatively speaking, lightweight, the language invites complexity through composition, and information density for any unit of code is typically quite low (which isn't necessarily a bad thing).

In my opinion, though, these are all drawbacks, and Rust addresses all of them. It's syntactically and semantically much heavier, leading to its oft-maligned steep learning curve. It has, uniquely among the major languages, I think, a syntax for expressing variable lifetimes (with its own unintuitive semantics). It stuffs lots of abstraction into a hodgepodge of terse semantics and punctuation.

It sucks to read, until you get really used to it. Then it tends to read really quickly, and, at least for me, it's easier to reason about a conceptually-broad piece of logic if I don't have to jump between different locations in a file, a module, or a package to do it.

With Go, I find it more difficult to get into a flow state, and easier for my eyes to glaze over when looking over large diffs.

It's not lost on me that these are purely subjective arguments, though. My preference remains with Rust, and that goes back to before I used LLMs.

I'm also aware that Go is very prescriptive about how you write it; it's explicitly opinionated, and Rust doesn't have that. It means that most Go code bases will look more alike. I consider this an anti-feature; I believe code should be able to conform to the problem space or product and a good team will find the best way to do that.

▲

orangecat 10 hours ago | parent [-]

Yeah, Go is easy to read in the same sense that English limited to its ten hundred most common words is easy to read (https://xkcd.com/1133/). Whether that nature is helpful or harmful to LLMs is an interesting question.

	▲	ndriscoll 10 hours ago \| parent [-]
		It seems very obviously detrimental to me (in the exact same way it's detrimental to people); e.g. use proper jargon with an LLM and you find it is suddenly an expert. The LLM has no trouble at all perfectly fluently using macros or monads or whatever thing people are afraid of to write simpler, more concise code that directly expresses the business logic in a fully type safe, high performance way that the compiler can introspect for even more information. Go of course lets you do none of those things and can only ever be used for "beginner code" by intentional design.

▲ dralley 11 hours ago | parent | prev | next [-]

For whatever reason, maybe not even logical ones, Go repulses me. I don't know why exactly, I like the idea of Go, but the aesthetics rub me wrong.

I think it's the use of pointers and "if err != nil {}" error handling spam. It reads as a highly compromised imitation of Python and C rather than a solid execution of some other idea.

Rust is not the most beautiful language out there but it doesn't trigger any such reaction for me. The ? operator and "match", which I use constantly, more than compensate for some of the sigil noise which I barely need to look at much less write most of the time. So Rust wins on that comparison for me.

The "func name() -> retval" syntax also grew on me. I like the fact that Python type annotations copied that approach, and C-style declarations look ugly to me now. Same with C-style /* */ comments.

	▲	kev009 10 hours ago \| parent \| next [-]
		Because Go is kind of a Steampunk design. The creators collectively ignored decades of PL developments. What that nets is kind of a C without sharp edges, but can't be used where C can. Rust is definitely jarring to look at, in the same way that decoding some strange C declaration can be, in ye olde days when you had to float all this context in your mind while doing work. But with modern tooling who cares: "explain this lifetime to me"
	▲	odo1242 10 hours ago \| parent \| prev [-]
		For me it's mainly the if err != nil {} stuff and the fact that everything is package scoped (C-style enums and constants). You can pretty clearly see the limitations if you read, for example, the type of code the Protobuf compiler generates when trying to compile Protobuf/gRPC enums or structs into the way-more-limited Golang type system (this is despite the two being designed to work together). And it could really do with algerbraic data types and other modern programming language features. Also the type system does have a couple weird behaviors that seem straight out of JavaScript. Like the difference between struct and interface nil for example: ``` var buf *bytes.Buffer = nil var out io.Writer = buf // now out is nil if out != nil { `// This block will execute because out is not nil out.Write([]byte("crash")) // This line will crash because out is nil` } ``` Many things about the language almost seem to be designed to simplify the implementation of the compiler rather than to benefit the developer experience.

▲ tasn 10 hours ago | parent | prev | next [-]

It's a matter of expressiveness, Rust expresses more.

E.g. make a table that's 3x3 is easier to read (Go), but the equivalent line in Rust would also include material, angles, height, etc. because the type system encodes much more information.

Though I always found Go to be significantly harder to read than Rust. Sure Rust has some crazy syntax at the edges, but Go makes it very hard to know where imports come from (and thus what they do), and the imperative style + lack of clarity about mutability makes code much harder to reason about.

▲ Buttons840 11 hours ago | parent | prev | next [-]

Counterpoint: I find Rust easier to read.

▲ mbrumlow 10 hours ago | parent | prev | next [-]

Might be unpopular, but agents write too much code for humans to read in any meaningful time frame. Using agents to generate code to then require humans to slowly consume it defeats a lot of the speed you gain from AI.

I my self and teams members are slowly reading less code and requiring agents to prove things work the way we want in other ways.

▲ threethirtytwo 11 hours ago | parent | prev [-]

I have an agent read most of the code as well. The agent explains things to me in plain english.

The default sentiment is humans should read code it's more progressive and a leap of faith to start giving that up.

Obviously, I get why you feel humans still reading code is important, but if you look at the progress of AI for the past couple of years, that gap is closing. The trendlines speak of a future where it becomes less and less important.

This was exactly what happened with writing code. Now most people don't write code.

▲

eliasson 11 hours ago | parent | next [-]

> Now most people don't write code.

I use LLM daily to write code for and "with" me, I also write code without LLM. Most people I come across mix it up. A few do it all by hand, and equally few all by LLM I would say. Is that just in my corner of the world?

	▲	threethirtytwo 10 hours ago \| parent [-]
		The trendlines are moving away from this. It's all happening so fast that not every company is on the same page, but from what I see we are quickly converging on not writing anymore code. My entire company for example does not write a line of code. We manage agents and that's it. Many, many, many companies and people are already doing this.

▲

throwitaway222 10 hours ago | parent | prev | next [-]

I have a few utility go codebases that I simply do not read at all - but it's internal tooling so there's literally no point in reading it when the LLM can modify it in seconds to do new things.

▲

simonw 11 hours ago | parent | prev [-]

I don't read all of the code produced by my agents any more, but I like to reserve the ability to do so if I run into a particularly confusing bug, or for any code that's security adjacent.

	▲	threethirtytwo 10 hours ago \| parent [-]
		Same. But usually if I need to read code, I end up telling my agent to summarize it for me.