Hacker News Reader

Comment by throwaway81523 | Hacker News Reader

Why write something like this in Rust since it presumably doesn't have anything memory intensive or real time going on? Rust's manual memory management is a necessary thing sometimes, but it is a pain, right?

View on HN

> but it is a pain, right?

Not really.

Ha - I was thinking the exact opposite. I'd have figured that tools that require an understanding of an entire project (imports/exports/types/etc) would need be VERY memory intensive, and something that would actually benefit from manual management/rust.

I don't know much about compilers/formatters/linkers and how they work though, so I could easily be wrong.

Freeing up memory has a cost and if you don't need to do it then don't. And if you don't need to free up memory you can't have a memory leak.

If you aren't short of memory, why write in a language designed around managing it? The alternative is garbage collection, not simply leaking it.

You can write an application that never frees memory and isn't leaking memory.

For some embedded applications, fixed memory regions work fine. For something like a compiler, not so much. Remember that you have to deal with chunks of data of unpredictable size. Even string literals might occupy megabytes. You could program your way around that, but most of the time these days, it's ok to burn memory (i.e. use GC) for the sake of development velocity.

Nah at worst it's like a compiler. Memory intensive = browser engine that is going to burn gigabytes. That was the original use case for Rust.

Compilers are very memory hungry.

You can write a memory hungry compiler but you don't have to.

Reply on news.ycombinator.com