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

121–130 of 544 posts

Re: Migrating from Go to Rust

#121

Post by onlyrealcuzzo »

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…

> Ultimately, if you have to ask, the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not".

You don't need a garbage collector which is perhaps half of the Go Runtime when you're using Rust.

You can also bolt on a few crates and get ~95% of what you'd get from Go's runtime.

Go has the best runtime in the world. I'll give it that.

But this is not the only reason...

Re: Migrating from Go to Rust

#122

Post by tptacek »

onlyrealcuzzo wrote: post #121
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…

> Ultimately, if you have to ask, the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". You don't need a garbage collector which is perhaps half of the Go Runtime when you're using Rust. You can also bolt on a few crates and get ~95% of what you'd get from Go's runtime. Go has the best runtime in the world. I'll give it that. But this is not the only reason...

You obviously don't need a GC when you're using Rust, because Rust doesn't plausibly have one.

Re: Migrating from Go to Rust

#123

Post by nemo1618 »

dillon wrote: post #84
nemo1618 wrote: post #21

LLM writing tells are getting more subtle, but they still jump off the page for me, in particular the word "genuine:" "This is the area where Go genuinely shines, and it’s worth being precise about why" "the lack of GC pauses is a genuine selling point" "Humans are genuinely bad at reasoning about memory" "There are cases where the borrow checker is genuinely too strict" tbc I don't think the article was fully AI-gen…

I have to agree here, but I'm not sure why. I don't have any clue what makes something sound AI generated or not. I got to about here "Go is clearly working for a lot of people," -- before I became suspicious that it was AI-assisted (but also maybe I'm wrong and it's not AI-assisted, I am very bad at telling). It's more about vibes (ironically) than anything else in particular. If something "sounds" AI-assisted then…

Agreed. In fact, one of the things I now watch for is my mind starting to "slide off" the text, or finding myself re-reading a section multiple times. It's like the brain subconsciously recognizes a lack of substance even if we can't point to a specific tell.

Re: Migrating from Go to Rust

#124

Post by onlyrealcuzzo »

tptacek wrote: post #122
onlyrealcuzzo wrote: post #121

Earlier quoted context omitted.

> Ultimately, if you have to ask, the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". You don't need a garbage collector which is perhaps half of the Go Runtime when you're using Rust. You can also bolt on a few crates and get ~95% of what you'd get from Go's runtime. Go has the best runtime in the world. I'll give it that. But this is not the only reason...

You obviously don't need a GC when you're using Rust, because Rust doesn't plausibly have one.

Right, so you don't need a large portion of Go's runtime benefits, because you have a far better version of it already, zero cost abstractions and TRUE memory safety, not pretend memory safety behind a -race detector with zero compiler guarantees...

Re: Migrating from Go to Rust

#125

Post by stock_toaster »

innocentoldguy wrote: post #89
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 find Elixir's memory and threading models much more compelling than Go's for web services. There are many great libraries for Elixir as well, but if you need something else, Elixir makes rolling your own libraries very easy. I'd recommend giving Elixir a try, if you haven't already.

Or gleam if you don’t fancy elixir.

Re: Migrating from Go to Rust

#126

Post by xyzzy_plugh »

atombender wrote: post #96
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…

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

Re: Migrating from Go to Rust

#127

Post by sieabahlpark »

BobbyJo wrote: post #25
lionkor wrote: post #16

Earlier quoted context omitted.

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

Having many semantic options for error usage is functionally the same as having many error types, except worse.

[dead]

Re: Migrating from Go to Rust

#128

Post by hu3 »

tempest_ wrote: post #93
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…

The use of LLMs has caused Rust usage to explode. If youre not writing the code yourself and vibing away which I think most people generally are despite the disdain around here then why would you not choose the "more performant language" (I know that isnt necessarily reality but it is a common perception). Go's managed runtime is less valuable when the LLM is perfectly happy to slap a bunch of stuff together for you…

Correction: The use of LLMs has caused every major language usage to explode.

And as mentioned in other comments, Rust slow compilation can be detrimental to LLMs + fast iteration speed. And it's not just speed, Tauri takes 20GB of disk space to compile. It's bonkers. This is npm/js ecosystem all over again but slower.

Another reason to pick Go if you're leaning on LLMs is the standard library. Often you can do more work with fewer dependencies.

I'd rather leverage world class engineers paid by Google to maintain dependencies for me than try my luck with half a dozen of 0.x crates. Plus stdlib APIs can (and are) versioned just like third party dependencies.

Re: Migrating from Go to Rust

#129

Post by marcus_holmes »

the__alchemist wrote: post #48
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 agree! The line early on about this being for backend services caught my attention. I love the Rust language and use it for embedded firmware and PC applications, but still use Python for web backends, because Rust doesn't have any tool sets on the tier of Django (Or Rails). It has Flask analogs, without the robust Flask ecosystem. I have less experience with Go, but would choose it over Rust for web backends, for…

Conversely, the Go community tends to actively shun frameworks, especially anything Rails-like, and will tell you to just use the standard library. Which is good advice, the standard library really does have everything you need. But it's also roughly on a par with what's available in Rust (though as someone said above, the Go stdlib routines have been heavily, massively, tested in production by now, and are fully mature and load-bearing).

Re: Migrating from Go to Rust

#130

Post by iknowstuff »

the__alchemist wrote: post #104
dwattttt wrote: post #79

Earlier quoted context omitted.

I guess you might have to if you need to use a library someone's written that doesn't implement the standard. Writing primarily applications, I couldn't tell you what error handling frameworks my dependencies are using: I literally don't know, and haven't needed to know in order to display, fail, or succeed. EDIT to add: I use anyhow for this, so I should also add "add context to an error when I fall" to the list of…

What's the standard? I'm not being snarky; I'm going down the thought process of how this would work in practice. I am on team Io Error [on std rust]", somewhat arbitrarily. If I call a lib that is on Team Anyhow, or Team Custom Error Enum, I will have to do some (Straightfoward, but a little clumsy) conversions if I want ? to work. This is complicated by being able to impl From for ErrorType2 only in one direction i…

There is no team io::Error. There is only one standard: https://doc.rust-lang.org/core/error/trait.Error.html
Post reply on HN