261–270 of 544 posts
This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust. Ultimately, if you have to ask , the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there a…
Earlier quoted context omitted.
For me the main advantage of Go over Rust is compilation speed. Then compared with Go Rust still rely on many C and C++ libraries making it problematic to cross-compile or generate reproducible builds or static binaries. The minus side of Go is too simplistic GC. When latency spikes hit, there are little options to address them besides painful rewrite.
> For me the main advantage of Go over Rust is compilation speed. Interestingly, Rust has quite good failed compilation speed. That's almost good enough. The usual Rust experience is that it's hard to get things to compile, and then they work the first time.
To other people's usage patterns though, I imagine the group of people who don't do much with the type system rely more on running a built binary to see if it worked, which means they'll pay the full compile/link time cost more often.
This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust. Ultimately, if you have to ask , the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there a…
Earlier quoted context omitted.
IMO neither Go nor Rust are great for reading/reviewing code. Go is too verbose and the type system isn't expressive enough. Rust code is littered with little memory management details and it requires tons of third party libraries. I think coding agents will eventually be able to get the low level details right on their own. Reviewers should be able to focus on architecture, design and logic mistakes. I also think we…
> I also think we need a high level formal specification language to tell agents what we expect them to do. Let’s make that specification Turing complete while at it. Jokes aside, IMO it will be a good natural progression. Specify the problem statement in LLM specification, generate the code in Go/Rust whatever is the language of your choice and review the generated code to make sure it adheres to the architecture/de…
It doesn't have to be a new language. I'm sure some existing language can be used to create a DSL that serves this purpose.
It can obviously never be complete. Some parts of the spec will always have to be natural language if we want to make the best use of LLMs.
Some years ago Go was all the hype rage. Now Rust is the new Go. I find that very confusing.
If verbosity is a main stickler, this is coming to golang 1.28 which will cut it down drastically: https://github.com/golang/go/issues/12854#issue-110104883
Earlier quoted context omitted.
Maybe I'm misunderstanding something but non-GC language doesn't mean you have to do memory management manually? I mean, for example, in Rust (or modern C++), it's basically automatic. There is no mental tax or catastrophic mistakes as far as I know.
Ok. https://rust-unofficial.github.io/too-many-lists/ I'm not saying Rust is worse than Go. It obviously isn't. But this argument that Rust's memory management isn't more cognitively demanding than Go's memory management --- that isn't true.
It's not far from true. The fights you get into with the borrow checker can be legendary, but lifetimes serve more as gentle reminders. If you get stuck, you can always just use Rc, which is pretty close to opt-in GC. But it's rare to have to resort to Rc, because ownership is just not that much of a problem. In fact, I very rarely use Box either. All heap memory allocation is done by containers, not manually by me. I guess the main friction point for lifetimes is Rust's closures and async, but if you avoid them life is pretty simple.
In return for wearing this almost not a problem, you almost don't have to think about releasing a whole pile of other things - like closing files, sockets, and locks. They are guaranteed to be released by the same mechanism.
On balance, I would not be surprised if the cognitive balance tips Rust's way once you allow for the fact that Rust's memory management also gives you robust resource management for free.
Earlier quoted context omitted.
For backend web dev, there are advantages. I really like Axum's use of typing: pub async fn dataset_stats_handler( Path(dataset_id): Path , Query(verbose): Query , ) -> impl IntoResponse { ... } With a route like: .route("/datasets/{dataset_id}/stats", get(dataset_stats_handler)) …the "dataset_id" path variable is parsed straight into the dataset_id arg, and a query string "verbose" is parsed into a boolean. Super co…
The Go standard library has learned to interpret path variables as well: https://go.dev/blog/routing-enhancements
I could see migrating from C or C++ or Python to Rust, for various reasons, but for web back-end work Go is a good match. I write almost entirely in Rust, but the last time I had to do something web server side in Rust, I now wish I'd used Go. The OP points out the wordyness of Go's error syntax. That's a good point. Rust started with the same problem, and added the "?" syntax, which just does a return with an error…
in rust say a function returns Result so either the we get a result all an error how is that different from (int, err) in go?
do you not still need to handle the error?
in go you just return the error up to whatever the top caller is.
Earlier quoted context omitted.
I love Go and used to write it heavily for anything non LLM based. Now that we have agentic coding I just write everything in Rust and couldn’t be happier. The struggle with rust was writing it, go was made so it was easy to write for mid level engineers. Now that we have agentic coding I’m not sure Go’s value prop holds up anymore My rust services have been nothing short of amazing from a performance and reliability…
In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust. They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .…