Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taming Go’s memory usage, or how we avoided rewriting our client in Rust

akitasoftware.com

Post reply on HN
Print view View original

131–140 of 231 posts

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#131

Post by int_19h »

ComputerGuru wrote: post #75
kevingadd wrote: post #44

Earlier quoted context omitted.

Reflection APIs seem to be pretty messy and slow in every runtime I've ever used, perhaps because the idea of optimizing them might encourage more use. The C# reflection APIs also allocate a lot.

The usual C# reflection APIs that devs turn to allocate a lot, but there are ways to make them almost performant by (re)using delegates and expressions. There are a number of good libraries to use reflection faster, as well.

IIRC, dynamically compiled expression trees in C# have the overhead of a single virtual call (on the resulting delegate) when executing - and cover all object factory and member access scenarios. But if you need to discover metadata, you still have to resort to Reflection APIs.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#132

Post by nyanpasu64 »

oconnor663 wrote: post #48
jcelerier wrote: post #26

Earlier quoted context omitted.

It kills me that RAII is considered modern c++. It's there since 1983 aha, what do you think fstream and std::vector are if not RAII wrappers over files or memory

I think before the introduction of move semantics in C++11, there were a lot of cases where you needed new and delete to get basic things working. (Moving an fstream around is a relevant example.) So the modern rule of "don't use new and delete in application code" really wasn't practical before that.

I suppose RAII is an old concept, but move semantics allowing RAII to transfer ownership and avoid manual new/free of non-copied resources was uncommon until C++11.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#133

Post by bluGill »

pjmlp wrote: post #89
bluGill wrote: post #69

Earlier quoted context omitted.

Most slow languages make escape to C easy for cases where the language is the issue. Most fast languages make writing a C APIed interface easy, so if the language is your issue just rewrite the parts where that is the problem. Of course eventually you get to the point where enough of the code is in a fast language that writing everything in the fast language to avoid the pain of language interfaces is worth it.

Except when the program is actually written in C, then better hold the Algorithms and Data Structures book and dust it off, or Intel/AMD/ARM/... manuals.

Algorithms and data structures come BEFORE dropping to c.

These days it is rare that you can beat your compiler with hand machine code, and even if you can it isn't worth it because the difference is typically small and only applies to one specific machine.

Of course once in C you can often think about memory locality and other cache factors that higher languages hide from you.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#134

Post by nyanpasu64 »

throwaway894345 wrote: post #86
slaymaker1907 wrote: post #24

Earlier quoted context omitted.

While some commenters have pointed out that you still need to deal with lifetimes/thinking about where stuff lives, in practice you can avoid almost all of this by using Rc instead of Type everywhere (or Arc in a multithreaded scenario). Yes Rc and equivalents have a performance overhead, but for many use cases the overhead really isn't that bad since you typically aren't creating tons of copies. In practice, I've fo…

I've tried this before and it was so laborious that I regretted it. I'm not sure I saved myself any time over writing "vanilla" Rust or whatever one might call the default alternative. If I was really interested in writing Rust more quickly, I would just clone everything rather than Rc it, but in whichever case you're still moving quite a lot slower than you would in Go.

I've tried writing Rc-oriented Rust (for gtk-rs) too, and struggled hard with the pervasive cloning/aliasing needed, having to use weak references to avoid leaking memory, and the clone!() macro turning off rustfmt for all code in the method body. In fact, I'd rather deal with Qt-style memory management, with single QObject ownership, QPointer (which is kinda like a weak pointer), and praying you don't use-after-free.

(Normally I use subclassing in Qt to associate extra state with a widget, but gtk-rs's subclassing API was arcane and boilerplate-heavy. Perhaps there's alternative paradigms for state management that follows Rust's single ownership principle better. Some people take a React/Elm-style approach, but I don't think virtual DOMs and diffing the entire UI tree on each user interaction are the last word on GUI interactivity and updates, and I don't find the added memory of virtual DOMs and CPU of generating/diffing them acceptable, but rather "pure overhead" to be eliminated in favor of minimal targeted UI state updates.)

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#135

Post by roca »

jgrant27 wrote: post #111

After using Rust for a few years professionally it's my take that people that really want to use it haven't had much experience with it on real world projects. It just doesn't live up to the hype that surrounds it. The memory and CPU savings are negligible between Go and Rust in practice no matter what people might claim in theory. However, the side effects of making your team less productive by using Rust is a much…

> the side effects of making your team less productive by using Rust is a much higher price to pay than just running you Go service on more powerful hardware.

This entirely depends on the ratio of development effort to deployed instances. At one end of the spectrum, lots of developers work for years on a system which is only deployed on one machine; obviously you optimize for developer effort and buy a single massive machine. At the other end of the spectrum, a few developers work for a short time on a system which is deployed at massive scale; obviously you optimize for performance.

At Pernosco we have a very small team deploying a relatively small number of instances, and after five years of Rust we're very happy.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#137

Post by qaq »

Thaxll wrote: post #107
tptacek wrote: post #39

The big wins in this article, in what I believe was the order of impact: * They do raw packet reassembly using gopacket, and gopacket keeps TCP reassembly buffers that can grow without bound when you miss a TCP segment. They capped the buffers, and the huge 5G spikes went away. * They were reading whole buffers into memory before handing them off to YAML and JSON parsers. They passed readers instead. * They were usin…

It's a question I ask often in interview, how do you upload a 5GB file over the network with only 1MB of memory.

hello world in Go is 1.9 MB

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#138

Post by pm90 »

marcos100 wrote: post #128
wibagusto wrote: post #112

Earlier quoted context omitted.

Well consider all the projects titled “blah blah blah… written in Rust” Who gives a shit what it’s written in—what does it do?

People who is interested in rust maybe want to see how it was used. The author could have just kept "Taming Go's Memory Usage". Maybe they never considered rewriting in rust. The pros and cons looks like just some random arguments to add rust to the title.

> The author could have just kept "Taming Go's Memory Usage".

It’s their article. They can choose to write it however they want. You may find this type of humor distasteful, fine, write your articles that way.

As a user of both rust and golang, I chuckled at the headline and then forgot about it.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#139

Post by gobookdev »

pm90 wrote: post #138
marcos100 wrote: post #128

Earlier quoted context omitted.

People who is interested in rust maybe want to see how it was used. The author could have just kept "Taming Go's Memory Usage". Maybe they never considered rewriting in rust. The pros and cons looks like just some random arguments to add rust to the title.

> The author could have just kept "Taming Go's Memory Usage". It’s their article. They can choose to write it however they want. You may find this type of humor distasteful, fine, write your articles that way. As a user of both rust and golang, I chuckled at the headline and then forgot about it.

a

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#140

Post by ferdowsi »

jgrant27 wrote: post #111

After using Rust for a few years professionally it's my take that people that really want to use it haven't had much experience with it on real world projects. It just doesn't live up to the hype that surrounds it. The memory and CPU savings are negligible between Go and Rust in practice no matter what people might claim in theory. However, the side effects of making your team less productive by using Rust is a much…

Agreed. My organization has been a great testing ground for comparing Go vs Rust service development. The teams that spun up web services in Rust have almost uniformly have had poor experiences. In addition to Rust's steep learning curve, the relatively feature-poor standard library (you have to pull in a third party package to create a SHA256!), and instability of best practices/tools around service writing, in one case, lengthy Rust compile times actually increased the time to resolve an incident. We've largely reached a consensus that all new services should be written in Go.

I don't see Rust having much of a place in web services development until there's years of improvements in place. There's plenty of other potentially appropriate places for Rust replacing systems code.

Post reply on HN