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

41–50 of 544 posts

Re: Migrating from Go to Rust

#41

Post by treavorpasan »

Thaxll wrote: post #31
kayo_20211030 wrote: post #9

If you have a green field, by all means write it in rust. If you have a brown field, and a functional profitable system, rewrite the parts that need rewriting in the original language, whatever that is, and carry on. Make your systems better in small measurable ways, with the language you know and a team you trust to implement it all. Anything else is a wasteful religious argument.

I don't see any reasons to use Rust when your team successfully shipped and is confortable with C#/Java/Go ect ...

If anyone one comes and tells me we need to rewrite in a new language from any of those modern languages, other than you are dealing with something cannot wait for GC.

That is a signal that person is lacking purpose in their job or life.

Re: Migrating from Go to Rust

#42

Post by ViewTrick1002 »

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

Re: Migrating from Go to Rust

#43

Post by airstrike »

LtWorf wrote: post #40
0xfurai wrote: post #35

The "when to enforce it" framing is what sticks with me. Go and Rust agree on safety, concurrency, simple deployment, but Go says "catch it in review" and Rust says "catch it before it compiles." The right answer depends entirely on how expensive a production incident is for you vs. how expensive slower iteration is.

> but Go says "catch it in review" So, in production?

It's AI slop, it makes no sense

Re: Migrating from Go to Rust

#44

Post by OtomotO »

amarant wrote: post #27
OtomotO wrote: post #17

Earlier quoted context omitted.

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

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!

Re: Migrating from Go to Rust

#45

Post by [deleted] »

natsucks wrote: post #30
amazingamazing wrote: post #24

Earlier quoted context omitted.

This is true if the token budget and time are not taken into account. In practice though, waiting minutes instead of seconds per build multiplied by prompt and again by change adds up very fast.

When everyone is armed with Mythos-like hacking ability, it's hard for me to imagine people wouldn't make the tradeoff of security over price.

[deleted]

Re: Migrating from Go to Rust

#46

Post by vlovich123 »

praseodym wrote: post #38
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…

Note that many Rust libraries consist of multiple crates, which all end up in the dependency graph. This makes the number of dependencies seem higher than it actually is: the separate crates have the same maintainers and are often part of the same upstream git repo. I agree with the general sentiment though. Rust also has a lot of crates that are stuck semi-unmaintained at some 0.x version, often with no better alter…

Unfortunately the 0.x version has pervaded because of community cargo culting claiming that versioning is easier with 0.x than with major version numbers > 0. Personally I find that hard to believe, especially given packages like Tokio and anyhow (still at v1) make it work and there’s others that are >v1.

That is to say 0.x doesn’t necessarily mean unmaintained, it can also mean “I don’t want to have to think about how to version APIs / make guarantees about APIs). Eg reqwest is very widely used and actively maintained yet is still at v0.13.

Re: Migrating from Go to Rust

#47

Post by nicoburns »

amazingamazing wrote: post #24
natsucks wrote: post #22

Earlier quoted context omitted.

Because the agentic world involves the generation of so much code that gets harder to review, I would think the compile-time guarantees of Rust would make it a better option.

This is true if the token budget and time are not taken into account. In practice though, waiting minutes instead of seconds per build multiplied by prompt and again by change adds up very fast.

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 on an Apple M1 Pro. The latest M4/M5 machines as ~twice as fast.

Re: Migrating from Go to Rust

#48

Post by the__alchemist »

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 the same reason you highlight: The library (including framework) ecosystem. I am also not the biggest Async Rust fan for the standard reasons (The rust web ecosystem is almost fully Async-required).

Re: Migrating from Go to Rust

#49

Post by J_Shelby_J »

praseodym wrote: post #38
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…

Note that many Rust libraries consist of multiple crates, which all end up in the dependency graph. This makes the number of dependencies seem higher than it actually is: the separate crates have the same maintainers and are often part of the same upstream git repo. I agree with the general sentiment though. Rust also has a lot of crates that are stuck semi-unmaintained at some 0.x version, often with no better alter…

There is good reasons to break out projects into multiple crates. It makes reusing functionality elsewhere easier. It makes it easier to reason about behavior. It makes it easier for LLMs to understand (either working within the crate or consuming as an api surface.) So you end up with projects that have multiple crates inside the same workspace and it really blows up dependency count.

Re: Migrating from Go to Rust

#50

Post by amazingamazing »

nicoburns wrote: post #47
amazingamazing wrote: post #24

Earlier quoted context omitted.

This is true if the token budget and time are not taken into account. In practice though, waiting minutes instead of seconds per build multiplied by prompt and again by change adds up very fast.

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.
Post reply on HN