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

311–320 of 544 posts

Re: Migrating from Go to Rust

#311

Post by ardeaver »

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…

I also wonder if it's possible that this is just "blog-speak"

The author of this article has what seems like it could be a relatively thriving consulting business, so he probably writes more to advertise his services than anything else. That kind of writing surely lends itself to a particular writing style, which is a non-insignificant chunk of the kind of writing that LLMs were trained on.

Re: Migrating from Go to Rust

#312

Post by pas »

throwaway894345 wrote: post #109
ViewTrick1002 wrote: post #34

Earlier quoted context omitted.

They all convert seamlessly, and the enums make the branches explicit. Don't even need to check the documentation to find which errors supposedly exists like in Go with its errors.Is, errors.As, wrapping and what not. An easy rule before you make a knowledge based choice is Thiserror for libraries, helping you create the standard library error types and Anyhow for applications, easy strings you bubble up. Or just go…

I’ve repeatedly tried using Rust and the error handling has tripped me up every time and has been ~90% of the reason for moving a project back to another language. I’m sure I’m just holding it wrong, but what I run into usually goes something like this (mind you, I have read the Rust book): * Someone tells me to use enums for errors, in a comment like yours * I try writing the enums by hand, implementing the error tr…

there are many (right) ways for writing monad transformers, and it's usually situation dependent which one makes sense. (practical aspects such as which errors do you want to merge, ignore, provide some default/fallback result; and of course overall coding style consistency helps guide this, but it's not trivial.)

(there's a lot of this in Scala too, because of the various monads/containers, eg. the built-in Future, and then Scalaz.IO, FS2, Cats, ZIO, etc...)

regarding lifetime and performance problems, the best practice seems to design the rough scaffolding of the program first, with the structs, so the who owns whom can be figured out. but this is far from trivial. Rust is very good at forcing developers to stare at these problems, but solving them requires practice and patience.

for me the tech toolbox that makes sense is TS by default (because of the super convenient type system and tooling), and Rust when the circumstances really justify it (latency, throughput, scalability, cost effectiveness, or a need for a single native executable [though nowadays this is also pretty simple with Deno], or more safety/control [no GC])

Re: Migrating from Go to Rust

#313

Post by willtemperley »

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…

[flagged]

Re: Migrating from Go to Rust

#314

Post by pas »

dnautics wrote: post #136
dwattttt wrote: post #111

Earlier quoted context omitted.

Do you really want that data passed back down to the caller of the allocation? From the description of the failure state you'd want to log that data instead: what's the caller of the allocation going to do if you tell it it failed with a crazy size? It already knows the size, it's the one who asked for it.

So, suppose it's a rust library -- you're locking me into whatever logging system the library author chooses? Maybe I'd like to consume the relevant data at the entry point and send it to a logging system of my choice.

it depends, if the functionality represented by the library is known to require a lot of memory (or simply allocation failures are an expected part of its operation), then it should be pretty much part of the API, probably with some tracing/diagnostics interface to get the required visibility into how much memory goes and where.

but for most libraries I on allocation failure I don't expect any fancy logging system. maybe even panic is fine.

Re: Migrating from Go to Rust

#315

Post by Luker88 »

wanderlust123 wrote: post #305
Luker88 wrote: post #278

I write purely Go at $dayjob, but I write purely Rust in my projects. I have a huge list of things that I have in Rust that I would like in Go, but I don't have a single thing I am missing from Go in Rust. I grow tired of golang "dumb it down" approach as I find it actually just shifts more and more work onto me. Is anyone in a different position? What does Go have that rust does not?

The simplicity of Go is a feature…

I have to come to believe that Go is simple for the compiler, not necessarily for the programmer.

`nil` is not simpler than references and Option. lack of enum is complicating my code. automatic type promotion is a hidden bug waiting to happen and preventing proper strong types, lack of `?` is making things verbose. struct tags look simple, until you realize they are hiding a ton of code and creating a ton of corner cases that you still have to manually check, and are completely nonstandard (hello json and `default`, `omitempty/omitzero` etc...). `nil` and interfaces? it took decades to recognize that Generics simplify things for the programmer, no Send/Sync like in rust makes concurrent code more error prone, etc, etc...

And that is without talking about the standard library, where "simple" somehow becomes having `url.Parse` that accepts everything without errors. http body `nil` vs `NoBody`. Who hasn't had to write the Nth implementation of a pipe between reader and writer? Apparently most libraries hear "simple" and think "dumb". We could go on for hours.

Golang is much easier to learn, and rust does remain much more complicated. I don't thing golang hit his target of "simplicity" honestly.

Re: Migrating from Go to Rust

#316

Post by simonask »

63stack wrote: post #233
dnautics wrote: post #108

Earlier quoted context omitted.

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

Any time I mention "but I would like stacktraces with my errors" I get told I'm doing it wrong.

That's because the types of errors where you want a stack trace are a relatively small subset of all possible errors.

Stack traces are only useful for errors that indicate a bug in the program, i.e. something a programmers has to respond to. It's not useful for the vast class of bugs that are a result of wrong input, wrong external state, or infrastructure issues.

Rust projects tend to favor panicking over error handling for programmer bugs (which does indeed give you a stack trace depending on environment variables), or even better encoding the invariants in the type system, but there are cases where an error coming from a library are truly, actually unexpected, so both `anyhow` and `thiserror` do provide support for attaching a stack trace in those situations.

Re: Migrating from Go to Rust

#317

Post by pas »

bborud wrote: post #296
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…

For the vast majority of software you want a managed runtime. Some of the problems Rust “solves” are problems you shouldn’t be having in the first place because we mostly write software that doesn’t need direct control over memory. Borrow checking isn’t something you want to have to deal with - it is something you have to accept when you have chosen to manage memory. That choice has a high cost that cost never gets p…

Rust's stdlib is small, Go took more of Python's "batteries included" strategy.

So in that sense it seems like a category error to try to look for crypto stuff in the standard library. Of course this brings the well known problem of "okay, but then which one should I use?". Nowadays this is largely solved by a few web searches and LLM queries, and people are quite helpful at https://old.reddit.com/r/rust/ .

Go was shaped by the needs of Google, Rust is a wildly successful amazing experiment in programming language and compiler design that really got out of hand :) (A bit like JavaScript! Or even C#! Or Python. Same growing pains (async/await!), but arguably on different levels.)

Re: Migrating from Go to Rust

#318

Post by WJW »

fauigerzigerk wrote: post #307
WJW wrote: post #299

Earlier quoted context omitted.

Maybe we can have Large Logic Models instead, and they could have formalized keywords with rigid meanings? Like IF, WHILE and FOREACH maybe. Or even ASYNC if you want to be modern about it.

I do think that AI models should get better at logic. But if code generators are supposed to be tools, we have to tell them what to do. I'm not sure what combination of languages is best for that purpose.

It would be so much easier if we could precisely specify what we wanted, without all the double meanings, slang and general ambiguity that comes from using a natural language.

If only there was an entire class of well-studied languages which don't have any such ambiguity. They'd be perfect for programming LLMs! We could call them "programming languages" perhaps.

Re: Migrating from Go to Rust

#319

Post by Havoc »

logicchains wrote: post #11
gertlabs wrote: post #3

I liked Rust before running a benchmark, but the gap between how effectively most LLMs write in Rust vs Go was still surprisingly large to me (especially in agentic harnesses where they can fix the initial environment issues). I've become a pretty big Rust evangelist after seeing that. We've had a lot of success writing batch processing tools in Rust to be called by our existing codebase, but haven't attempted a full…

The weakness of Rust WRT LLMs is compilation times. LLMs code faster and hence spend relatively more time waiting for compilation than humans do, so on reasonably sized projects (e.g. 100k+ lines) Rust's ~10x slower compilation starts showing up as a bottleneck. If you're writing some critical infrastructure it makes sense to pay that cost, but if you're writing some internal service that's not publicly exposed to th…

>The weakness of Rust WRT LLMs is compilation times.

That's a more tractable problem then basically anything else around LLMs and programming. We're definitely getting more cores in the avg machine judging by roadmaps & leaks

Re: Migrating from Go to Rust

#320

Post by pas »

tptacek wrote: post #192
kelnos wrote: post #189

Earlier quoted context omitted.

> the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". That's not really something I care much about. My beefs with Go are 90% about the syntax of the language itself, and it's weak (compared to Rust) type system. When it comes to a managed runtime, for most tasks, I generally don't care if my language has one or not. For some tasks I do, but there are not many of thos…

That's totally fine. I don't get why people moralize this stuff. Both of these languages are rounding errors compared to the dynamic languages.

Because it triggers the "feeling of other" when someone is so close yet so far ideologically.

I'm sure you know this joke about dogmas :)

https://news.ycombinator.com/item?id=26624442

In some sense this is the same as the NIMBY/YIMBY question. There are perfectly valid reasons to want to live like Spacers do on Aurora, yet many prefer the caves.

Post reply on HN