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

371–380 of 544 posts

Re: Migrating from Go to Rust

#371

Post by physicsguy »

fpoling wrote: post #275
physicsguy wrote: post #231

Earlier quoted context omitted.

> Rust still rely on many C and C++ libraries Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.

With Go basic stuff like url parsing or HTTPS support is written in Go and comes with the standard library. With Rust too many necessary things are just wrappers around C and C++ making cross-compilation and reproducible builds much harder to archive. As for availability if CGO is ok, then calling C or C++ code from Go is not that hard. Also, there is always an option to just start C++ process if extra data copies ar…

C APIs are much more annoying to wrap in Go than in Rust because of lack of enums (important) and unions (less important).

Re: Migrating from Go to Rust

#372

Post by tptacek »

LtWorf wrote: post #238
tptacek wrote: post #217

Earlier quoted context omitted.

I don't agree with the parent comment, but mmap is exposed (low-level) in the standard library and there's a high-level wrapper in x/exp. You need to be careful with mmap no matter where you're using it. What Go mmap CVE were you thinking of?

> What Go mmap CVE were you thinking of? Every time you see "segmentation fault", that right there is a CVE.

No, obviously.

Re: Migrating from Go to Rust

#373

Post by imtringued »

dnautics wrote: post #108
dwattttt wrote: post #72

Earlier quoted context omitted.

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

stacktraces? might also be useful to know whether or not the latest allocand was a jumbo sized allocand that caused the failure?

If you let the allocation error panic you will get your stack trace.

You can't have a stack trace on an error in the error path that failed to allocate. If you have a "jumbo sized" error and the error fails to allocate, it won't get reported. The only reporting you will get is that the error failed to allocate and this new allocation error overrides the error that failed to allocate.

Re: Migrating from Go to Rust

#374

Post by tptacek »

fg137 wrote: post #343
PaulRobinson wrote: post #230

Earlier quoted context omitted.

By that reasoning, we should all be vibing away C code. It's the most performant and efficient language out there, there's a ton of code out there the LLMs were trained on, and the complex logic of memory management is abstracted away by the LLM so you don't need to think about it. Most people are not doing that though. There's probably a good reason, and it applies to other languages too.

There is a good chance that your vibe coded C program segfaults immediately upon running and contains lots of subtle logic errors, all of which requires many iterations (finding issues at runtime) before you program runs as expected. With Rust, you'll likely get many compilation errors, but if your syntax is correct, compilation errors will be few, and your code will almost certainly just work.

I wouldn't build anything in C that I didn't absolutely have to, but, no, there is not in fact a good chance that your vibe-coded C program segfaults immediately.

Re: Migrating from Go to Rust

#375

Post by yamapikarya »

i like go because it's simple and just works. i like the error handling, if err != nil return err, i like the philosophy to focus using stdlib instead choose which libraries are the best for doing x. i like how go handle the concurrency like using channel or sync.waitgroup. i am very biased but someday i will also learn rust

Re: Migrating from Go to Rust

#376

Post by imtringued »

echelon wrote: post #368
dnautics wrote: post #163

Earlier quoted context omitted.

What about the data in the error payload?

You can do better than the errors in other languages. You can provide all the relevant information in the emum variant. enum MyApiBindingCrateError { // You didn't provide an // API key. Maybe we should // design our interface to // make this impossible ApiKeyMissing, // Client was unauthorized // to make this request AuthorizationError, // The entity you requested // did not exist (404'd) NotFoundError, // You're se…

In the current context with regards to failed allocations, you're also supposed to add a variant that wraps AllocError.

Re: Migrating from Go to Rust

#377

Post by jafffsuds »

> There’s no built-in goroutine-style preemption. Long CPU-bound work in an async task starves the executor; you offload to tokio::task::spawn_blocking or rayon instead.

I don't know why anyone uses spawn_blocking for CPU-bound tasks. It's clearly designed for blocking IO tasks. There's a reason why Erlang cordons them separately into Dirty CPU and Dirty IO schedulers.

Re: Migrating from Go to Rust

#379

Post by never_inline »

awesome_dude wrote: post #33
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…

Package management is the bane of nearly every language/technology Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?) For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine) There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseud…

> we cannot "pin" versions

you can? that's why go.sum exists. you can also use the replace directive for more advanced scenarios.

Re: Migrating from Go to Rust

#380

Post by [deleted] »

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…

[deleted]
Post reply on HN