7 ms·
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
by TobyTheDog123 3y ago
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.
- throwaway81523 3y agoNah 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.
- galangalalgol 3y agoCompilers are very memory hungry.
- throwaway81523 3y agoYou can write a memory hungry compiler but you don't have to.
- postalrat 3y agoFreeing 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.
- throwaway81523 3y agoIf you aren't short of memory, why write in a language designed around managing it? The alternative is garbage collection, not simply leaking it.
- postalrat 3y agoYou can write an application that never frees memory and isn't leaking memory.
- throwaway81523 3y agoFor 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.