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

481–490 of 544 posts

Re: Migrating from Go to Rust

#481

Post by zero_shift »

bborud wrote: post #478
zero_shift wrote: post #474

Earlier quoted context omitted.

It also means that everything is (over) optimised for Google's usecases, but not general purpose applications I came across this problem pretty directly a couple of weeks ago - I wanted to see if I could port a small C program to Go, where one of the needs is to create gzip archives. But the Go stdlib insists on extraneous padding that breaks the backwards compatibility requirements of my program. The padding isn't n…

How is this «optimized for Google»?

Somebody at Google decided this is how they wanted it to work. They don't have to explain why and they don't have to fix this deficiency until it becomes a problem for Google

Re: Migrating from Go to Rust

#482

Post by [deleted] »

awesome_dude wrote: post #450
mxey wrote: post #394

Earlier quoted context omitted.

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)

I don't think you understand the term "pinning" go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it. The workaround is vendoring, where you control the versions in a cache.

[deleted]

Re: Migrating from Go to Rust

#483

Post by com2kid »

Recursing wrote: post #250
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.

express-zod-api works well for me https://github.com/RobinTail/express-zod-api I'd say about as well as anything Python

Typescript supporting runtime usage of types instead of making me define them in Zod first would be 100x better.

Or at least support a standard for code transform plugins.

Re: Migrating from Go to Rust

#484

Post by kbolino »

awesome_dude wrote: post #450
mxey wrote: post #394

Earlier quoted context omitted.

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)

I don't think you understand the term "pinning" go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it. The workaround is vendoring, where you control the versions in a cache.

There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g. https://stackoverflow.com/a/77412524/814422

It is worth noting though that, even without such pinning, `go mod tidy` does not update versions willy-nilly. [edit: the following is inaccurate, see grandchild comment] It only syncs go.mod with what is already being used by the build process. In other words, if you see `go mod tidy` change a version, it means that you haven't tidied the file since making other changes to it, and the listing in go.mod was stale with respect to the resolved set of transitive dependencies actually being used.

Re: Migrating from Go to Rust

#485

Post by mxey »

awesome_dude wrote: post #450
mxey wrote: post #394

Earlier quoted context omitted.

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)

I don't think you understand the term "pinning" go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it. The workaround is vendoring, where you control the versions in a cache.

Pinning to me means there is a file with all the versions as they will be used. I don’t see how “go mod tidy” modifying it is different from “bundle install” modifying it.

Re: Migrating from Go to Rust

#486

Post by mxey »

kbolino wrote: post #484
awesome_dude wrote: post #450

Earlier quoted context omitted.

I don't think you understand the term "pinning" go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it. The workaround is vendoring, where you control the versions in a cache.

There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g. https://stackoverflow.com/a/77412524/814422 It is worth noting though that, even without such pinning, `go mod tidy` does not update versions willy-nilly. [edit: the following is inaccurate, see grandchild comment] It only syncs go.mod with what is already bei…

> It only syncs go.mod with what is already being used by the build process

If dependencies are incomplete, Go will fail to compile and tell you to run go mod tidy to fix it.

Re: Migrating from Go to Rust

#487

Post by dwattttt »

dnautics wrote: post #475
dwattttt wrote: post #260

Earlier quoted context omitted.

I think this is a clash of terminology: a Rust enum isn't an integer with pretensions of an identity. You'd describe it as a tagged union in some languages. So when you say you'd return an error with extra information, what that information is is associated with the specific variant of the enum. Using yuriks AllocError as an example, if the error is SizeTooLarge, it has the size field. Other errors may have no additi…

I'm aware that a rust enum isn't just an integer? How would it have a payload if it were just an integer? right. If allocerror only has size field, where do you stash the unwind information (which could be of arbitrary size)

There's a few confusing things here. For one, just because the allocator gave you an AllocError, that doesn't mean your function has to return an AllocError: you can return whatever error type you choose. If you want to collect a stack trace at that point, put one in there.

What value would a stack trace that includes internal allocator functions be to you? What do you lose by having to collect the stack trace at the point where your function receives an AllocError?

Re: Migrating from Go to Rust

#488

Post by apatheticonion »

apatheticonion wrote: post #354

I wrote Go professionally for years. Moved to Rust and couldn't be happier. There are some annoying syntax quirks but they are minor. After writing web services, GUI apps and terminal apps professionally in Rust, I honestly struggle to see a use case for other languages.

Shameless plug. I've been developing a web server library for Rust based on the ergonomics of the Golang standard library.

It has a router, middleware, and uses AsyncRead, AsyncWrite for the request/responses.

I use this for my production applications and have found it much easier to work with than Hyper or Axium.

https://github.com/alshdavid-public/uhttp/blob/main/examples...

The API is largely complete but under the hood I have a few things that need doing. Open to contributions so please feel free to help out

Re: Migrating from Go to Rust

#489

Post by kbolino »

mxey wrote: post #486
kbolino wrote: post #484

Earlier quoted context omitted.

There is something you can do to stop it actually. You can use a replace directive, specifying that a module is replaced by itself at a fixed version. See e.g. https://stackoverflow.com/a/77412524/814422 It is worth noting though that, even without such pinning, `go mod tidy` does not update versions willy-nilly. [edit: the following is inaccurate, see grandchild comment] It only syncs go.mod with what is already bei…

> It only syncs go.mod with what is already being used by the build process If dependencies are incomplete, Go will fail to compile and tell you to run go mod tidy to fix it.

Indeed, I ran two tests (missing indirect dependency, stale indirect dependency version) and it refused to compile both. Either what I said was never true, or it was only true for earlier versions of the `go` command. Nevertheless, adjusted accordingly, I believe the following statement is true: `go mod tidy` doesn't change versions in go.mod unless it needs to, to satisfy the other dependencies listed in go.mod, or to fill in a missing dependency for an import in code. It would be nice if there were a flag to turn off the latter behavior, though.

Re: Migrating from Go to Rust

#490

Post by ryan_n »

jorvi wrote: post #270
x-yl wrote: post #244

Earlier quoted context omitted.

In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust. They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .…

LLMs generally write poor quality anything. It'll [usually] work, but it'll need massive refactoring to get in a maintainable and efficient state.

this was true a year ago but not so much anymore. You still have to supervise the agents, but they can write maintainable code if you keep an eye on it.
Post reply on HN