undefined | Better HN

0 pointshombre_fatal5y ago0 comments

When you're writing synchronous, single-threaded code like, say, a binary file parser or even an HTML scraper with blocking APIs, Rust is 1:1 with high level languages, and usually better.

Where Rust diverges is when you're doing async or multithreaded things with complicate lifetimes.

Getting things right from the start instead of solving them JIT as runtime issues pop up in production over the course of the year is Rust's wheelhouse. But even after using Rust for three years, I sometimes feel like I'm one requirement-change away from a problem I can't solve myself in Rust where I could solve it in a couple hours in another language.

0 comments

zozbot2345y ago

> But even after using Rust for three years, I sometimes feel like I'm one requirement-change away from a problem I can't solve myself in Rust where I could solve it in a couple hours in another language.

Rust does have these sorts of issues wrt. managing highly generic graph-like data, possibly with cycles. That's where tracing GC actually shines, and where writing that whole portion separately in something like Go might be the right answer.

hombre_fatalOP5y ago

Yep.

When I'm writing Go, I spend the whole time yearning for the abstractions of Rust, becoming a little more bitter each time I copy and paste or have to manually reify interface{}, knowing my ceremonious verbose Go code is slower than the simpler compact Rust solution.

When I'm writing Rust, I'm loving life until I hit this sort of "intractable" [for me] problem, and I wonder if I should have used Go for this part.

steveklabnik5y ago

That is true if you have to write your own. 99.99% of the time, if you need a graph, you use petgraph and move on with life.

jfkebwjsbx5y ago

Reference-counted graphs are usually quite fine.

j / k navigate · click thread line to collapse