Live data from Hacker News

Migrating from Go to Rust

corrode.dev

61–70 of 544 posts

Re: Migrating from Go to Rust

#61
post #16
post #6

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…

> Rust lacks a uniform error type Rust has practically one error, it's the Error trait. The things you've listed are some common ways to use it, but you're entirely fine with just Box (which is basically what anyhow::Error is) and similar.

Surely you need an alternative to Box for reporting memory allocation failures?!

Re: Migrating from Go to Rust

#63

Earlier quoted context omitted.

Incremental Rust builds are almost never minutes (on recentish hardware) A quick measurement on my web browser project with almost 600 dependencies: - A clean "cargo check" was 31s - An incremental "cargo check" with a meaningful change was 1.5s Building is a little slower: - A clean "cargo build" was 56.01s - An incremental "cargo build" was 4s But I find that LLMs are mostly calling "check" on Rust code. --- That's…

I mean i wouldnt call a 100% a little slower wrt check vs build. In any case, the more you change the longer the incremental check or build will take.

Sure, but when we're talking single-digit seconds it feels not that significant regardless?

Re: Migrating from Go to Rust

#65
post #6

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…

I was a big fan of go for a while. Though now that I have programmed more swift and rust recently, having a compiler that doesn’t protect against null pointer deferences or provide concurrency safety guarantees feels a little prehistoric.

Though go certainly did a much better job than rust on the standard library front.

Re: Migrating from Go to Rust

#66

Earlier quoted context omitted.

Incremental Rust builds are almost never minutes (on recentish hardware) A quick measurement on my web browser project with almost 600 dependencies: - A clean "cargo check" was 31s - An incremental "cargo check" with a meaningful change was 1.5s Building is a little slower: - A clean "cargo build" was 56.01s - An incremental "cargo build" was 4s But I find that LLMs are mostly calling "check" on Rust code. --- That's…

I mean i wouldnt call a 100% a little slower wrt check vs build. In any case, the more you change the longer the incremental check or build will take.

1.5s for a massive project, on a laptop,like the OP said is still barely anything in the context of agentic coding. It’s less than a single percentage point of the total time in the loop, even if the agent has to compile multiple times.

This is cope.

I do give you that rust is more verbose and thus more token heavy. However that verbosity is meaningful and the LLM would have to spend tokens thinking about the code to understand less verbose languages. So I’d consider that a wash - in some cases it hurts and in some it helps.

Re: Migrating from Go to Rust

#67
post #17

Rust is great. However in an agentic world go will win. Look no further than incremental build times. This, combined with high token costs mean that for a given application it simply will cost more to to write it in Rust than Go. This can easily be justified for many usecases, but for your vanilla crud app, do you really need Rust? Per the article, you are getting 20-50% better more performance with Rust. Not worth i…

It's a good thing then, that the AI hype is dying outside of ycombinator, the silicon valley and the US

[dead]

Re: Migrating from Go to Rust

#68
post #53

Earlier quoted context omitted.

The cost of verbose compiler output surely cannot compare to the cost of shipping bugs that would've been caught at build time.

Indeed, but is it the case that all bugs you have are those in which would be caught by the compiler? It’s not like rust code inherently is bug free.

Of course, there's plenty of bugs in Rust code still. The fact that safe Rust should be able to statically guarantee entire classes of bugs like data races are impossible is a huge deal, though. We're totally free to have different values when it comes to what matters, but compile time and a verbose toolchain are not high costs for that, to me. I personally would first consider other things like the cognitive overhead of learning to work with the borrow checker.

Re: Migrating from Go to Rust

#69
Go has shorter and more predictable GC pauses. If a reference count drops to zero in Rust, it may take an unbounded time to free all the things it refers to (recursively if necessary).

Re: Migrating from Go to Rust

#70
post #6

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…

Rust does not have three error systems. It has one: the Error trait. io::Error is one of many that implement it (nothing special about it). Errors defined via thiserror also implement it. “Anyhow” just allows you to conveniently say “some Error” if you don’t care to write out an API contract specifying types of errors your function might spit out.

He's not making that up; in practice, you're going to run into and need to make mental space for the idiosyncrasies of multiple error frameworks.
Post reply on HN