1. Amount of Rust training data isn’t as much as Go.

2. Golang syntax and style is very verbose yet simple. There’s not as many options nor programming language to domain mapping needed as in Rust. Leads to needing less sophisticated LLM to spit out Golang than Rust successfully and efficiently.

This must really depend on your niche. I assume you do web stuff or something? Good luck finding any golang examples in a lot of other fields. Rust, on the other hand, is taking over the world in systems programming.

Been reading and drinking that kool-aid for some time until I realized it's just an internet bubble mumbo jumbo. Majority of systems are still written in C and C++, and will be for unforeseeable future.

>Good luck finding any golang examples in a lot of other fields.

There are go examples (and full blown programs) for anything, from servers to Kubernetes and Docker.

which is pretty much webdev for the larger industry.

Yes. Maybe I should have said web stack?

Just reporting what I’ve experienced. No need to go with the ad hominem attack. I happen to lead a team with a major Rust infra project and I stand by the experience with usage across all the LLM models.

What ad hominem?

In short, compile times and a more full-featured stdlib

Doesn't Rust have long compile times? Does Go suffer from the same problem?

Go famously has stupidly fast compile times.

One of the design goals of Go was to be fast to compile. And they achieved it.

why,i have same question

I’m heavy into rust and never really use golang, but one big benefit of go over rust is compile times are significantly quicker, which could be more fun if you’re running CI checks 50 billion times

>which could be more fun if you’re running CI checks 50 billion times

Even running them 5 times it's WAY more fun

Because LLMs are better at Go? And because some people understand Go code easier and they might want to look at the code?

why use Rust when you can use Zig?

Why use zig when you can use odin?

So I can test my feature today instead of waiting until it finishes compiling tomorrow.

this is the top reason for a reasonably complex project, but it can be worked around by preplanning crates.

the other reason is if you really want async as is in vogue nowadays, function coloring - but this is rapidly becoming irrelevant, see article.

> but it can be worked around by preplanning crates.

Maybe if you're working alone.