Hacker News Reader

Comment by mtberatwork | Hacker News Reader

Once you start seeing hundreds or thousands of requests coming in per second and you see your cpu utilization sky rocket, then the "slowness" of the interpreted languages really comes into full play. Most apps/websites will never achieve this kind of load or scale though.

View on HN

> interpreted languages really comes into full play.

There are plenty of non-interpreted languages that don't require GC though. When you pick Rust you are picking manual memory management. Does even Google opt for non-GCed languages for their web servers?

We've been having a debate lately, within Rust, if "manual" is really the right term here.

  {
      let x = Box::new(5); // malloc

  } // free

Is this really _manual_? In a sense it is, but it's very different than what most people think about. "Automatic" is kind of a good word, but Objective-C/Swift's "ARC" already covers that, and we don't do refcounting, so that could be misleading too.

Maybe "deterministic"?

Memory management in C is also "deterministic", just forget to ever free. :P

How about lexical memory management as a nod to dynamic vs. lexical scoping?

That might work for now, but something we're working on for the future is making borrows non-lexical, so....

Borrows may be non-lexical in the future, but deallocation via ownership will always be at the end of a lexical scope. Not only would eager deallocation be bad for performance, it's also a backcompat hazard at this point.

"RAII" seems to cover it nicely, and extends beyond memory management to other resources. Admittedly it's not a very friendly term for non-C++ programmers.

What's this non-lexical borrowing idea you mentioned in your other comment? (I can't reply there for some reason.) Is there an RFC for that?

The relevant search terms are "SEME regions" and "non-lexical borrows". The tracking issue is here: https://github.com/rust-lang/rfcs/issues/811 and https://github.com/rust-lang/rust/issues/6393 is the older issue it superseded, with examples.

There hasn't been an RFC yet, because we're in the middle of a large amount of compiler internals work (HIR/MIR), which will make overall analysis easier, including these two features.

> (I can't reply there for some reason.)

HN limits responses based on the depth of the comment tree and the length of time since the comment was posted, to discourage flamewars, you can always click on a comment link directly to kind of bypass that though.

Thanks for the issue link (and for the comment-tree depth hint!).

Scope-bound resource management (SBRM) is clearer than RAII, I think.

I personally like:

Rust: "statically memory managed" Java, Go: "dynamically memory managed"

Similar to: "statically typed" or "dynamically typed"

Statically memory managed already has a meaning. It means that there is no malloc during runtime, all memory addresses are decided (usually manually) beforehand and written into the executable.

I wouldn't call it manual at all. It looks remarkably like automatic storage duration IMO.

Google suggests "affine memory management" is not yet used as a term.

Reply on news.ycombinator.com