Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Jemalloc added over a megabyte to every project for only questionable gains, and it was awkward and unwieldy to remove it. While there are good reasons to use a different allocator depending on the project, Rust defaulting to this type of behavior failed a certain personal litmus test on what it wanted to be as a language in that it felt like it was fighting the system rather than integrating with it.

It also does not give a good first impression at all to newcomers to see their hello world project built in release mode take up almost 2MiB of space. Today it's a much more (subjectively) tolerable 136kiB on Windows (considering that Rust std is statically linked).



> Jemalloc added over a megabyte to every project

Right, but, so what? I can't imagine a practical reason this matters for the vast majority of situations. So either you're doing something pretty niche, or it's a purely aesthetic complaint.


> or it's a purely aesthetic complaint

Those are certainly valid. There are entire Linux distros whose mere existence is as the answer to what is only an aesthetic complaint.


So it's wasted space if you don't need it. Being a small amount of space to waste doesn't make it reasonable to do that.


Imagine you had a bunch of rust binaries on your system instead of one. And you're running on a 2 GB emmc.


Okay, that's a niche scenario. I agree Rust during the statically linked jemalloc era might not be ideal in that scenario. But just because you can concoct some possible scenario in which it's not the best language to use doesn't mean you should write it off completely.


I would think Embedded Linux would be one of the most desired use cases for rust (certainly it's a place where higher level languages are often not an option due to resource usage).


It's a matter of what use cases are catered to by default, and what use cases are possible. For example, having debug symbols on by default makes it easier to start using the language and debug your applications, at the cost of more disk space and having to configure your project if your needs are different. I think the discussion would have more merit if the defaults weren't configurable. But of course, the choice of defaults is one that will be contentious no matter what. It should still be done following the Hippocratic Oath of "first, do no harm". And some of us need to accept that our usecases are more niche than others, including mine.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: