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

201–210 of 544 posts

Re: Migrating from Go to Rust

#201

Post by corndoge »

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…

Thanks for writing this, I learned something

Re: Migrating from Go to Rust

#202

Post by awesome_dude »

what wrote: post #191
awesome_dude wrote: post #157

Earlier quoted context omitted.

Not rust specific, and most certainly not a criticism of you - but I hate when people call a lib that errors, then just bubble that error up. I mean the error is supposed to be tailored to the audience - I guess what you are saying is that you handle the error by saying "I called foo with X, Y, Z, and got this error back" in the logs - which your caller then also does - producing a log message of ERROR: I called Foo…

You’re supposed to bubble errors up to the level that can appropriately deal with them? You don’t need to log them each step of the way.

Yeah - but that's the same as my final point - you have to know who is supposed to manage the error/log - all the way up (and down) the call graph

edit: I've just finished debugging a multi system chain - FE -> SNS -> SQS -> Lambda -> DynamoDB -> Lambda -> Webhook -> My poor code

My code has multiple layers - and I was trying to find where in the very long chain of calls the data was being mangled

It turned out that there was an unlogged error, which was mismanaged by a caller - there's no shade here - the caller was handling the error how it was designed to, but by not logging that there was an error - it took a minute to understand.

Re: Migrating from Go to Rust

#203

Post by awesome_dude »

dwattttt wrote: post #199
awesome_dude wrote: post #157

Earlier quoted context omitted.

Not rust specific, and most certainly not a criticism of you - but I hate when people call a lib that errors, then just bubble that error up. I mean the error is supposed to be tailored to the audience - I guess what you are saying is that you handle the error by saying "I called foo with X, Y, Z, and got this error back" in the logs - which your caller then also does - producing a log message of ERROR: I called Foo…

I have tried to figure out some kind of unification between "collecting error state in a function", "logging error state", and "return error state to a parent". I haven't found any satisfying solution to it all; collecting information for logging vs information that a caller would want... I've been meaning to investigate tracing_error to see if it brings it all together.

Regardless of language - if you find a good, clear answer - blog the hang out of it - I for one have been searching for the right way to manage this, and it's not (yet) clearer - other than what I've said so far

Re: Migrating from Go to Rust

#204

Post by dwattttt »

ViewTrick1002 wrote: post #82
PyWoody wrote: post #78

Earlier quoted context omitted.

Python has sqlite3[0], curses (tui) [1], and tkinter[2] in the stdlib. [0] https://docs.python.org/3/library/sqlite3.html [1] https://docs.python.org/3/library/curses.html [2] https://docs.python.org/3/library/tkinter.html

Right. The famous stdlib where once good libraries go to die so you instead depend on the latest community replacement choice. Also argparse for Clap: https://docs.python.org/3/library/argparse.html

To highlight the problem for Python: Python's standard library has getopt, optparse, and now argparse. I don't think they set out to offer 3 argument parsing libs, one of which is marked superseded, but here we are.

Re: Migrating from Go to Rust

#205

Post by xarope »

fpoling wrote: post #51
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 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.

if you are hitting pauses due to GC issues, you should into putting appropriate data structures into a memory arena, here's a reasonable read:

https://uptrace.dev/blog/golang-memory-arena

These are all tools. Java used to have this all the time, and we (ex-java programmer) had ways around this until the JVM improved.

Re: Migrating from Go to Rust

#206

Post by nirui »

> It confuses easiness with simplicity

A lot of libs/packages in Go's stdlib also has this problem. They like to package everything in a very tight interface (very obvious example includes crypto/* and http), without exposing implementation detail to the end user.

Doing this of course has it's benefits, but if the feature provided by the stdlib slightly don't fit you needs, then you might have to write your own (potentially unsafe and/or less performant) one from zero.

Rust is great overall, but there's some oddities. For example their lib.rs / `mod` is very, very unintuitive, it felt overdesigned and unnecessarily complex (just see [their book]). I like what Go or Java did to their lib/package systems, it's much better that way.

[their book]: https://doc.rust-lang.org/stable/book/ch07-05-separating-mod...

Re: Migrating from Go to Rust

#207

Post by awesome_dude »

ventana wrote: post #171
awesome_dude wrote: post #55

Earlier quoted context omitted.

Linters are available to catch you before you compile - with Go Generally speaking there has to be a mechanism for optional handling of return values, in Go you can ignore everything (ew), you can use placeholders `_`, or you can explicitly handle things - my preference. If you say "Well in C you have to handle the returns - I am not across C enough to comment, but I will ask you - Does C actually force you, or does…

C, as a language, cannot bother less about you using or not using the return values, checking them, discarding them, or using them to index an array without any bounds checking. Various linters and compilers may have their opinions, expressed as warnings, but at the end of the day it's completely up to you as a developer.

Yeah - I assumed so - which makes the GP post... bizarre

Re: Migrating from Go to Rust

#208

Post by LtWorf »

lanstin wrote: post #155
tempest_ wrote: post #93

Earlier quoted context omitted.

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…

I like vibe coding but I am sceptical that a vibe coded runtime in Rust would be as awesome as the Go runtime which is written with deep expertise of Unix software and threading and many low level details that are subtle and do depend on global properties of the code to work flawlessly. It makes sense you can crank out Rust with an LLM if you know what you are doing, but if you want a GC type thing or preemptive sche…

> the Go runtime which is written with deep expertise of Unix software

Go has no mmap(), import a 3rd party dependency for that and you'll get a segfault the very second you do a mistake.

Python has an mmap module which will catch many memory errors and present them as exception rather than causing a CVE.

Re: Migrating from Go to Rust

#209

Post by magicalhippo »

nirui wrote: post #206

> It confuses easiness with simplicity A lot of libs/packages in Go's stdlib also has this problem. They like to package everything in a very tight interface (very obvious example includes crypto/* and http), without exposing implementation detail to the end user. Doing this of course has it's benefits, but if the feature provided by the stdlib slightly don't fit you needs, then you might have to write your own (pote…

I've come to hate hiding internals. Put them in a namespace which makes it clear there's no API stability guarantees, but make them available if needed.

As you note it's just pain with no gain to properly hide them. Users can't readily work around bugs or extend functionality.

Re: Migrating from Go to Rust

#210

Post by samat »

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…

And many others. I felt it too

And it’s a good contrast with ‘just fcking use Go’ article he linked.

Go article is much more human. I love that and would choose a human centered language and human centered culture over LLM-centered everything every time

I guess I am just old

Post reply on HN