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

91–100 of 544 posts

Re: Migrating from Go to Rust

#91

Post by awesome_dude »

tadfisher wrote: post #85
corndoge wrote: post #52

Earlier quoted context omitted.

Nix solved it. Languages could choose to adopt Nix as their packaging system.

It did and didn't. Nix tools for building language-specific packages almost always wrap the language build tool/package manager. This can be easy or hard, depending on how onerous the build tool is for vendoring libraries. What Nix and build tools need to agree on is a specification or protocol for "building a software dependency tree". Like, I should be able to say 'builder = cargo' in a Nix derivation and Cargo sho…

I think one of the key problems too is that a system level dependency is managed by people dedicated to ensuring the chaotic nature of the package they are responsible for conforms to the way the OS they are maintaining for has proscribed.

There's no real way to do that at a language level - we cannot have "Go has determined the package you are trying to fix has not met the versioning requirements proscribed so you cannot submit the patch to fix it"

What language dependencies do is what OSes would think of as "unofficial versioning" that is, an OS will let you install and run an unofficial version of some lib (we've all been there, right, multiple versions of some core library because one doesn't work with whatever you are trying to install), but they will not manage it at all.

Re: Migrating from Go to Rust

#92

Post by hasyimibhar »

It is also easier to make your code deterministic with Rust vs with Go, which is incredibly useful if you need to perform deterministic simulation testing + property-based testing. I recently wrote a Postgres-to-Iceberg data mirroring tool [1] in Go, but I ported it to Rust because I wanted the ability perform DST without fighting Go's runtime [2]. But if the domain is not critical that warrants DST, I would still pick Go over Rust any day.

[1] https://github.com/polynya-dev/pg2iceberg

[2] https://www.polarsignals.com/blog/posts/2024/05/28/mostly-ds...

Re: Migrating from Go to Rust

#93

Post by tempest_ »

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 to and approximate it and doesn't complain at all when writing async rust despite some of the rough edges.

Re: Migrating from Go to Rust

#94

Post by com2kid »

tptacek wrote: post #88
com2kid wrote: post #86

Earlier quoted context omitted.

Us Node folks adapted typescript because we wanted static compiled types. I wish TS had more of a runtime. The only thing I'm jealous of with regards to python is how seamlessly you can do JSON schema enforcement on HTTP endpoints. The Zod hoops are a constant source of irritation that only exists because the TS team is dogmatic.

I think Typescript is a perfectly cromulent language. I don't know it well but would seriously consider it for any problem that had a shape that admitted a dynamic language. There's a lot to be said for using dynamic languages, too!

Every non-runtime language is dynamic after being compiled to x64 machine code!

It is illusions and lies all the way down the instant the compiler finishes its job.

Re: Migrating from Go to Rust

#95

Post by LoganDark »

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…

thiserror and anyhow are just std::error with extra steps. Note that io::error is just a specific std::error.

The entire point in Rust is that you wrap Error impls with other Error impls, or translate one impl into another using a match. I've found this is far more flexible and verifiable than most other languages, because if you craft your error types with enough rigor, you can basically have a complete semantic backtrace without the overhead of a real backtrace.

I use thiserror a lot to help with my impls. Notably, all it does is impl Display and Error. It's not a specific other paradigm because it basically compiles out, it's just a macro.

Anyhow is perhaps the closest one to another paradigm because it allows you to discard typed information in favor of just the string messages, but it still integrates well with Errors (and is one).

Re: Migrating from Go to Rust

#96

Post by atombender »

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 convenient compared to Go, and you type validation along with it.

Many other things to like: The absence of context.Context, the fact that handlers can just return the response data, etc.

What I don't like: Async.

Re: Migrating from Go to Rust

#97

Post by LoganDark »

I still think rustfmt made a mistake by going with four spaces. It's basically inferior for everything except forcing everyone to use the same indentation width, which is actually a downside, since I constantly encounter two-space indent codebases that I can't read and also can't change to four spaces because it's not tabs. Also translating spaces to tabs visually is undecidable thanks to alignment, while the inverse is not true. Ugh.

Re: Migrating from Go to Rust

#98

Post by fpoling »

hedgehog wrote: post #83
fpoling wrote: post #51

Earlier quoted context omitted.

For me the main advantage of Go over Rust is compilation speed. Then compared with Go Rust still rely on many C and C++ libraries making it problematic to cross-compile or generate reproducible builds or static binaries. The minus side of Go is too simplistic GC. When latency spikes hit, there are little options to address them besides painful rewrite.

I've run into GC pauses, I think in many (most?) cases there is some class of bulky data that you can either move into slices of pointer-free structs (so the GC doesn't scan them) or off-heap entirely. The workload where GC is slow is also likely prone to fragmentation so whatever the language you'll have to deal with it.

Java with its copying GC deals fine with fragmentation albeit at the cost of more upfront memory. And even in Rust one can change the allocator to try to deal with fragmentation. But with Go there is simply no good options besides the rewrite.

Re: Migrating from Go to Rust

#99

Post by nicoburns »

amazingamazing wrote: post #77
J_Shelby_J wrote: post #66

Earlier quoted context omitted.

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.

> in any case building and immediately building again of course will be fast

FWIW, the compile time test above was done comparing consecutive commits. Which in this case happened to have ~3-4 lines changed.

Re: Migrating from Go to Rust

#100

Post by dilyevsky »

> Under heavy allocation, P99 latency tails are noticeably worse than a Rust equivalent that simply doesn’t allocate on the hot path.

Lmao so not an equivalent then? Standard glibc malloc, which is default in rust, will also similarly degrade albeit for different reasons.

Post reply on HN