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

401–410 of 544 posts

Re: Migrating from Go to Rust

#401

Post by malcolmgreaves »

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…

> Rust lacks a uniform error type.

Not quite true. The unifying error trait is std::error::Error.

> pain when you have to pass them upward through a chain of calls

Kind of? You just make an enum with the various variants that need to be passed through and use the #[from] macro to generate the conversion code automatically.

It’s more characters than eg. A union type in Python or TypeScript, but it’s not much more.

Plus, it makes you think about your error design, which is important!

Re: Migrating from Go to Rust

#402

Post by tuetuopay »

mxey wrote: post #396

> You literally cannot dereference an Option without acknowledging the None case. Whole categories of pager-duty incidents disappear. This is at the very least misleading, given that you can use unwrap. Regarding error handling: will a parser error in the config return an error that includes the name of the file that’s failed to parse? That’s the kind of useful context that I add to errors in Go.

The difference is, unwrap will stick out like a sore thumb, and it’s opt-in. You explicitly tell "this may panic".

As for error handling, this kind of enrichment is usually left to the caller (that is, the end application), with error libraries like anyhow where you can add arbitrary string contexts to an error. You would end up writing `Config::load(path).with_context(|| format!("Failed to load configuration file {path}"))?`.

Re: Migrating from Go to Rust

#403

Post by AtNightWeCode »

Anybody who actually moved a set of services from Go to Rust? I've heard that in practice Rust uses more memory than Go for web services. When I ask LLMs I get the same answer as in the article. A 30-50% reduction but then also claims on how much memory Go uses. Which is about 5-10x more than our average service use.

Re: Migrating from Go to Rust

#404

Post by Capricorn2481 »

maxloh wrote: post #259
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 don't know about the author's background, but there is now a generation of non-native programmers who learned to write English by using LLMs for corrections (yeah including this comment). The irony is that studies show LLM detectors have a much higher false-positive rate for non-native speakers [1]. If most of what you read stems from LLMs, you end up writing like an LLM. [1]: https://hai.stanford.edu/news/ai-detec…

> but there is now a generation of non-native programmers who learned to write English by using LLMs for corrections (yeah including this comment)

LLM writing has not been overly abundant for more than a couple years. I don't know where you got the idea that an entire generation of people have already learned to write like an LLM.

Re: Migrating from Go to Rust

#405

Post by ventana »

LtWorf wrote: post #255
ventana wrote: post #171

Earlier quoted context omitted.

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.

Same as in go, a language designed several decades later.

Which is probably not really surprising, if we consider who were the original designers of Golang!

Re: Migrating from Go to Rust

#406

Post by deagle50 »

nihsett wrote: post #200
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…

Exactly. 95% of programmers are application programmers - they ship software used by regular users. I think it's insane to use a non-GC language for most of those cases. Manual memory management is mentally taxing and it's easy to make catastrophic mistakes. The marginal benefit from it is just not worth it unless you're making games or a trading system. 5% who write tools or other "infra" layer for the other 95% to…

Or it could be insane to pay the cloud memory costs when you have tools that can write rust for you.

Re: Migrating from Go to Rust

#407

Post by aatd86 »

drykiss wrote: post #370

Quite new to Go, so sorry in advance for a stupid question: > "Go got generics in 1.18 (March 2022), thirteen years after the language shipped. They are useful, but they feel tacked on, and in practice they have most of the downsides of a generic type system without delivering the upsides you’d expect coming from Rust, Haskell, or even modern C++." The problems with Go generics have now largely been solved, haven't t…

That's the thing, a programming language is not something static, it evolves. For instance, people are working on adding generic methods for the next release cycles.

And what the article complains about is by design, not a bug. It is a tradeoff made to avoid bloat. In any case, given the future possibilities, I'd bet on Go.

If anything, the language is just slower to evolve because every language change means the tooling needs to catch up. And now llms would have to catch up. ChatGPT is still using Go 1.23 for instance...

Re: Migrating from Go to Rust

#408

Post by PyWoody »

chlorion wrote: post #367
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

And ironically with the exception of the python sqlite3 module, the rust alternatives are much higher quality, IMO. Does anyone even use tkinter in modern times anyways?

I wouldn't start a company behind it but tkinter is perfectly fine for basic guis. It has its quirks but who doesn't?

Re: Migrating from Go to Rust

#409

Post by kstrauser »

mre wrote: post #365
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…

Author here. I use the term 'genuinely' too often, but that's just me. I do that when speaking here as well. Suffice to say that I'm not a native speaker, so that might have something to do with it. I will go over the text and replace some of those. thx.

My own iA Writer flags are great, love, hope, literally, "but,", and genuinely. Sigh. They just sneak out there.
Post reply on HN