Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Go to Rust

corrode.dev

Post reply on HN
Print view View original

321–330 of 544 posts

Re: Migrating from Go to Rust

#321

Post by lelanthran »

mountainriver wrote: post #178
Animats wrote: 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 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…

> The struggle with rust was writing it, go was made so it was easy to write for mid level engineers.

In practice, anything that makes it easier for humans to program also makes it easier for LLMs to program.

You also wont typically learn that the LLM is close to the limits of understanding your code base until after it has blown past it's own capabilities, leaving you with a mountain of code that you are not skilled enough to fix.

Java, C# are good choices as they tend to enforce a certain structure. Go, good because it's very readable even if you dont know the language.

C++, Rust are poor choices unless you are already a senior in that language.

Re: Migrating from Go to Rust

#322

Post by virtualritz »

I would add that Rust also has naming guidelines and sticking to them removes or at least minimizes the occurrence of another common topic of discussions on PRs/reviews.

In the article, if you were to mention & follow them GetUser() in Go becomes user() in Rust[1], not get_user().

[1] https://rust-lang.github.io/api-guidelines/naming.html#gette...

Re: Migrating from Go to Rust

#323

Post by christophilus »

Animats wrote: 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 just hate how many dependencies you have to pull in for a typical Rust project vs Go. As far as Go being an ugly language, there are some interesting wrappers that put lipstick on that pig such as https://lisette.run/

But personally, I don’t mind Go at all. I’ve even begun to prefer it for some things. That may be Stockholm syndrome, though.

Re: Migrating from Go to Rust

#324

Post by pas »

p2detar wrote: post #303
sgt wrote: 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.

If you can encode your request processing patterns in statically sized types, then you can get the same high-level memory allocation behavior on both platforms. Arguably Rust makes this a bit easier. (Though I have no idea how much of the concepts of mechanical sympathy made it to mainstream Java.)

If you have some kind of super vague complicated patchwork of plugins that all contribute to processing, then the JVM seems to be the more convenient choice.

https://martinfowler.com/articles/mechanical-sympathy-princi...

Re: Migrating from Go to Rust

#325

Post by Yokohiii »

moltonel wrote: post #276
bottlepalm wrote: post #182

Earlier quoted context omitted.

For me the bottleneck now is reading/reviewing code, not writing code. As you said, AI makes it way easier to write, but do you not review the code? And isn't a verbose, cryptic language with lots of nitty gritty memory management not harder to read/review? I'm not sold on Rust being a great language to use with AI unless the reason to use it is a lot more than just Rust being fashionable.

I find Go harder to review than Rust. The verbose error handling diluting the interesting parts is one thing, but the main issue is the weak type system. Having to read the callee's code to check if it deviates from `res xor err`, or if it mutates its arguments. Figuring out which interface that `func (o *Obj) ()` is implementing, if any. Dealing with documentation that is a wall of 100 disappointing oneliners all re…

I don't see the difference in exploring an dense custom type system versus a flatter one. Both force you to look things up when you don't know about them.

In my opinion these problems originate in architectural style. Much of the open source written today is designed to impress the audience instead of focusing on the problem.

Re: Migrating from Go to Rust

#326

Post by BlackFly »

tialaramex wrote: post #293
BlackFly wrote: post #228

Earlier quoted context omitted.

Certainly you pay a price for lifetimes but you buy compile time race condition detection via the borrow checker's aliasing-xor-mutability enforcement. So all that is happening is the complexity of concurrency is being made explicit and therefore easier to reason about. Many applications can be architected in a way that wouldn't ever trigger a race, so for people working on that it isn't something they would need to…

Rust doesn't promise that your safe Rust doesn't have race conditions only specifically that it doesn't have the one very weird kind of race condition from computers with no analogue to the real world, a Data Race. An ordinary race condition would be e.g. you put the cat out of the front door, then you walk to the kitchen and close that door - well, the cat might race around the outside of the house and get in first.…

> In logic, equivocation ("calling two different things by the same name") is an informal fallacy resulting from [...] knowingly and deliberately using words in a different sense than the one the audience will understand.

Of course I mean data race, most people in such a thread will implicitly understand that is the race meant. Nobody building a webshop with limited supplies wants to prevent "first come first served", it barely makes sense to think about preventing that kind of race

Data races have obvious real world analogues, they are just so obvious people naturally synchronize. You can look over someone's shoulder while they update a paper master copy and observe data tearing as they erase a field and start writing in another value while that is inconsistent with the rest of the form. It is easy to see that data is being modified and wait until the writer is complete instead of memorizing a partial update and walking away to make decisions on the basis of the incomplete information. A good mutex/rwlock is like having a private separate room to go into to make the update so that no overeager person can even observe the partial update (some languages have non callback style mutexes so there the mutex/lock is the analogue of the visual cue that someone is performing the update). I don't find this at all strange to consider. In a concurrent system it is just all too easy to forget that there are other threads (analogue of people) reading/modifying at the same time. So rust makes that manifest through the borrow checker and it becomes obvious.

Rust prevents more than just data races. Even in single threaded code, if you have a reference to a struct (without explicitly choosing interior mutability), you are guaranteed that its value has not changed since the last time you read it, despite other parts of the code having a reference to it. You don't need to make defensive copies. Some people may find this useful, but generally it won't be enough to convince someone to drop their current language in favor of rust. This transfers into multi-threaded code as well: only a single thread can make modifications to a struct through a reference xor as many threads as you want can read from the struct with references. You can easily write go/java/python programs that have these features and so don't feature data races, but they are difficult to reason about: how do you know that there is only a single reference featuring mutation or many threads only reading? The answer requires non-local knowledge which is difficult to reason about and this is enough for some people to consider rust where the answer is local (defined by the variable).

Re: Migrating from Go to Rust

#327

Post by galangalalgol »

amusingimpala75 wrote: post #133
OtomotO wrote: post #13

Earlier quoted context omitted.

The stdlib is the place where good ideas go to die. And then you have httplib3 followed by httplib4. In other words: I highly prefer the Rust approach. It doesn't matter a lot whether I rely on the stdlib or another dependency to me. It's a dependency after all. People think just because it's the stdlib it's somehow better quality or better maintained, but these are orthogonal concepts. In the end it depends solely o…

I’m not arguing on quality of the library, I’m arguing on not getting pwned by the sheer number of transitive dependencies

If you look at the number of authors vs the number of dependencies the gap narrows but doesn't disappear. Many of the most commonly used crates are written by members of the rust foundation amd are used in the tools themselves. But it is always a concern. I'm looking forward to the upcoming option to forbid versions newer than N days at the project level. But just manually only y updating versions when you need a new feature or there is a cve works pretty well.

Re: Migrating from Go to Rust

#328

Post by Yokohiii »

fpoling wrote: post #106
throwaway894345 wrote: post #101

Earlier quoted context omitted.

Isn’t it somewhat easy to remove allocations in Go? I haven’t had to “rewrite” as such, but rather lifting some allocation out of loop. Am I misunderstanding the scenario?

With backend serving many clients with widely varying performance profile of individual requests when latency spikes happen there is no particular hot loop. Just many go routines each doing reasonable thing but with a particular request pattern hitting pathological case of GC.

Extreme variance in usage patterns will always be challenging. But pre allocating some reasonably sized buffers can go a long way.

Re: Migrating from Go to Rust

#329

Post by MeetingsBrowser »

p2detar wrote: post #303
sgt wrote: 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.

Indirect evidence, but parts of AWS and cloudflare have been running Rust in production for close to a decade now and neither company looks to be itching to move services back to Java.

Re: Migrating from Go to Rust

#330

Post by joaohaas »

nihsett wrote: post #200
tptacek wrote: post #74

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…

Exactly. 95% of programmers are application programmers - they ship software used by regular users. I think it's insane to use a non-GC language for most of those cases. Manual memory management is mentally taxing and it's easy to make catastrophic mistakes. The marginal benefit from it is just not worth it unless you're making games or a trading system. 5% who write tools or other "infra" layer for the other 95% to…

This post is specifically about backend development, where you're not shipping software to regular users.
Post reply on HN