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

71–80 of 544 posts

Re: Migrating from Go to Rust

#71

Post by cbondurant »

I already use Rust and don't have experience with Go, so this article maybe isn't super for me.

I do have one nitpick though: Stating that data races are "caught at compile time" in Rust feels like it is overstating the case, at least a little. It sounds a bit like its implying Rust can also handle things like mutual lock starvation, or other concurrency issues. When that's simply not the case. I know "data race" is technically a formal term, with a decently narrow scope, yet I still think it could be a bit clearer about it.

Re: Migrating from Go to Rust

#72

Post by dwattttt »

fweimer wrote: post #61
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.

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

A &(dyn Error + 'static) should be fine for that; you don't need any allocated/variable sized data in a memory allocation failure.

Re: Migrating from Go to Rust

#73

Post by pier25 »

JuniperMesos wrote: post #23
amusingimpala75 wrote: post #2

This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with m…

Why is it worse to import a number of other packages that provide exactly the functionality you need, than to have a large standard library that provides some but not all of the functionality you need, requiring you to still use some large dependencies?

For example, security. See all the supply chain attacks from the past couple of years.

Re: Migrating from Go to Rust

#74

Post by tptacek »

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 are more programming domains where you want a managed runtime than ones where you don't.

That's not an argument for defaulting to Go in all those cases! There are plenty of subjective reasons to prefer Rust. I miss `match` when I write Go (I do not miss tokio and async Rust, though). They're both perfectly legitimate choices in virtually any case where you don't have to distort the problem space to fit them in (ie: trying to write a Go LKM would be a weird move).

The Rust vs. Go slapfight is a weird and cringe backwater of our field. Huge portions of the industry are happily building entire systems in Python or Node, and smirking at the weirdos arguing over which statically typed compiled language to use. Python vs. (Rust|Go) is a real question. Rust vs. Go isn't.

Re: Migrating from Go to Rust

#75

Post by amarant »

OtomotO wrote: post #44
amarant wrote: post #27

Earlier quoted context omitted.

As someone with a background of consulting in the Stockholm based gaming industry for the last decade+, I have to respectfully disagree. Nearly everyone I know is very much on the hype train. And for good reason too! The capabilities are undeniable!

As is the hype. You know, shovels are useful, they are just more useful to the shovel manufacturer than the gold diggers. But in the end it's a cool tool that made it way easier to dig holes and tend to your garden!

Oh yeah, definitely. There has indeed been a lot of hype overestimating the capabilities. People thinking you can one-shot big complex applications with a few paragraphs of descriptions for example. There has also been a lot of anti-hype, or whatever you call it when people seem to believe LLMs don't provide any value for software Dev, basically writing all capabilities off as pure hype.

The truth of course is somewhere in the middle.

It's difficult to tell what people mean when they say hype sometimes.

Re: Migrating from Go to Rust

#76

Post by amazingamazing »

nicoburns wrote: post #63
amazingamazing wrote: post #50

Earlier quoted context omitted.

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?

My point is that it isn't necessarily that fast. It is relative to the amount of changes and where they were made. For a fair comparison you would also have to present the worst case incremental build time which approaches the full build time (this goes for Go too), which per your own example is nearly a minute for rust.

Re: Migrating from Go to Rust

#77

Post by amazingamazing »

J_Shelby_J wrote: post #66
amazingamazing wrote: post #50

Earlier quoted context omitted.

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…

We don’t know how massive the project is, but in any case building and immediately building again of course will be fast. How fast is it if all files have a single line changed, for example refactoring a log message?

Not to mention we haven't even gotten to discussing tests.

Re: Migrating from Go to Rust

#78

Post by PyWoody »

ViewTrick1002 wrote: post #42
amusingimpala75 wrote: post #2

This is probably going to sound generic / repetitive, but my biggest complaint about Rust is the package management situation, which is entirely the result of the developer mindset. I love the ergonomics on the rust side (the functional approach to data types is beautiful), but I’m working on two projects side by side, one in rust and one in go at the moment. The dependency trees are entirely different beasts, with m…

> rusqlite (sqlite), clap (cli), ratatui (tui), and tauri (gui) Does any language, except like Java, exist with a standard library comprising matching that? Also, keep in mind that Tauri itself is 14 crates, where each one shows up in your build tree. https://github.com/tauri-apps/tauri/blob/dev/Cargo.toml And Ratatui is 6: https://github.com/ratatui/ratatui/blob/main/Cargo.toml

Python has sqlite3[0], curses (tui) [1], and tkinter[2] in the stdlib.

[0] https://docs.python.org/3/library/sqlite3.html

[1] https://docs.python.org/3/library/curses.html

[2] https://docs.python.org/3/library/tkinter.html

Re: Migrating from Go to Rust

#79

Post by dwattttt »

tptacek wrote: post #70
iknowstuff wrote: post #15

Earlier quoted context omitted.

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.

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 things I do.

Re: Migrating from Go to Rust

#80

Post by wpollock »

Very nice write up! I am a fan of Rust and have little exposure to Go. That said, a couple of very minor points:

cargo audit is not built-in, it is 3rd party. (The comparison table near the top isn't clear about that, and the following text stating more is built-in for Rust than for Go might be confusing. I would suggest adding an asterisk to mark built-ins in that table.)

cargo watch has been in "maintenance mode" for some time. The author of that suggests cargo bacon instead.

Post reply on HN