Live data from Hacker News

Migrating from Go to Rust

corrode.dev

301–310 of 544 posts

Re: Migrating from Go to Rust

#301

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…

Go was never about being easy to write (thought it is), but it was always about being easy to read and it is, by far, the easiest language to read that I've ever used (and throughout the decades, I went through Basic, Pascal, C, Java, JavaScript, C#, TypeScript, Ruby and Python). That becomes even more important if you are not writing the code yourself...

it's too verbose, yet not explicit.

you need to know the conventions to spot what's not there (did you miss the error handling? or the magic comment for the whatever codegen serializer? c'est la vie!)

edit: just a few comments below an even better description of what I'm trying to convey: https://news.ycombinator.com/item?id=48264853

Re: Migrating from Go to Rust

#302

Earlier quoted context omitted.

Reading the code? Who has the time. Aah, I am sure the chickens of vibe coded origin, will never come to roost.

Time isn't the constraint here, but ability. Someone complaining about how hard Rust is to write is probably not capable of reviewing Rust code very well. The usual reaction or opinion from e.g. good C++ programmers switching to Rust is that the added guardrails and expressivity are great and make things easier.

I find it easier to review Rust (but Go too) than to write it.

Re: Migrating from Go to Rust

#303
post #284

Meanwhile.. Java's still around. Modern, and fits the LLM paradigm quite well. It's not going to be as amazing or fast as Rust is, but close.

> as amazing or fast as Rust

For cli tools, game engines, etc. certainly so. But what about monoliths? Do we have enough data to say Rust handles long-running monolith apps exposing web and other network services better than the JVM with its hot spot? I haven’t come to any stats on that matter, yet.

Re: Migrating from Go to Rust

#305

I write purely Go at $dayjob, but I write purely Rust in my projects. I have a huge list of things that I have in Rust that I would like in Go, but I don't have a single thing I am missing from Go in Rust. I grow tired of golang "dumb it down" approach as I find it actually just shifts more and more work onto me. Is anyone in a different position? What does Go have that rust does not?

The simplicity of Go is a feature…

Re: Migrating from Go to Rust

#306
post #151
post #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).

I still prefer having deterministic control over when the free occurs. For example, I can transmit the response to the client and then free the memory afterwards so they're not kept waiting.

Can't use that approach for a GUI.

Re: Migrating from Go to Rust

#307
post #299

Earlier quoted context omitted.

It absolutely should be Turing complete. I want to formally specify some constraints/invariants that any generated code has to meet, like very high level test cases. 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…

Maybe we can have Large Logic Models instead, and they could have formalized keywords with rigid meanings? Like IF, WHILE and FOREACH maybe. Or even ASYNC if you want to be modern about it.

I do think that AI models should get better at logic. But if code generators are supposed to be tools, we have to tell them what to do. I'm not sure what combination of languages is best for that purpose.

Re: Migrating from Go to Rust

#308
Golang is an amazing runtime with a bad language, one that conflates simple with easy. I view it the same way I view Java: a fine choice for a corporation, but nothing to love. Although Java’s gotten a lot better lately.

Re: Migrating from Go to Rust

#309
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 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.

Now there is a cult of rewriting everything in Rust. System level software? Yes. Web? I prefer not to.

Re: Migrating from Go to Rust

#310
post #308

Golang is an amazing runtime with a bad language, one that conflates simple with easy. I view it the same way I view Java: a fine choice for a corporation, but nothing to love. Although Java’s gotten a lot better lately.

For me having the proper tool for the job trumps loving. I don't have to love the language, I have to love the process and the end result.
Post reply on HN