Remix.run Logo
mbrumlow 11 hours ago

Rust is better. It just is. Go is not bad. But as a long time go advocate, the hurdle for my teams using rust is gone, and thus everything is now rust.

simonw 11 hours ago | parent | next [-]

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.

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

Personally, Rust or Typescript both happen to be better than Go for me. TypeScript has better type-safety and tooling for user-facing apps, and Rust has better type-safety and tooling for algorithmic stuff or stuff that needs to run fast.

rsyring 11 hours ago | parent | prev | next [-]

I guess the difference in compile times doesn't matter enough?

ramoz 11 hours ago | parent | prev | next [-]

idk. In my experience the build/compile experience has been far worse esp for fast iterating. Even concurrency models did not seem as intuitive as Go's. Im no systems expert - have deployed practical and performant distributed systems though.

jhawk28 11 hours ago | parent | prev | next [-]

Zig seems to have more closely aligned with what Go devs prefer.

jdw64 11 hours ago | parent [-]

Go doesn't have memory safety issues because of its GC, while Zig has UB problems. Zig might have slightly better performance, but I don't think choosing a language without memory safety is a good idea

OutOfHere 8 hours ago | parent [-]

What is UB?

colwont 8 hours ago | parent [-]

undefined behaviour

amazingamazing 11 hours ago | parent | prev | next [-]

Ignoring performance for the moment (because most situations are bottlenecked on something else), why is rust better?

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

I agree, but this doesn't justify anything. Saying rust is better because it "just is" won't convince anyone. I'd like to know why you think it's better.

nchmy 11 hours ago | parent | prev | next [-]

can you elaborate?

greenavocado 11 hours ago | parent [-]

Rust compiler is a tyrant. Type system is strict. Borrow checker is relentless. LLMs can't slop too much without being beaten up by the compiler.

vorticalbox 11 hours ago | parent | next [-]

True but if the reviewer doesn’t have an intimate understanding of rust then the fact it can’t “slop” is no different than unreadable slop.

Go is simple, no “magic” marcos or meta programming even with just a little programming in any language it’s not hard to understand what the go code is doing.

greenavocado 7 hours ago | parent [-]

That's simply not true. I wrote a piece of software in Rust that is non-trivial, robust, 50k lines of code, and 100% LLM generated, used by four people productively with only one or two minor bugs in the past two man-months

vorticalbox 6 hours ago | parent [-]

question did you review the code or did you test it was working? these are different things. and if you did review it, could an engineer without deep Rust experience have reviewed it just as effectively?

I have no doubt that you can get a LLM to write working bug free code in any language but that is not the topic of the article or my comment.

threethirtytwo 11 hours ago | parent | prev [-]

This is true. I'd like metrics on this though. It could be that LLMs find go easier so they end up writing better code and rarely hitting static errors like a human would in rust. IT could be through scientific measurements that the benefits of static checking could be negligible for LLMs.

No way to know until someone does the science on this. Until then it's just people saying that more static checking is better. But I do think, anecdotally, python is horrible for LLMs.

greenavocado 11 hours ago | parent [-]

Until we can measure slop accurately it's all guesswork

iberator 11 hours ago | parent | prev [-]

except Rust is HARD while GO is super easy.

tibbon 10 hours ago | parent | next [-]

Rust makes you solve many of your problems upfront, which is a nice feedback loop for using with an LLM. Go does much of this too, but I feel Rust is more experessive and takes the frontloading a bit further.

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

It's not that hard.

11 hours ago | parent | prev [-]
[deleted]