There's an old joke about emacs standing for eight megabytes and continuously swapping.
But I think it's more useful to think about the percentage use of RAM for a given application. If you're running on a machine with 32 MB of RAM, then using 20 MB for a single application is obscene. But if you're running 32 GB, it's insignificant.
Even so, a single application shouldn't be using a significant percentage of system RAM on an average consumer grade laptop/desktop (4 to 16 GB of RAM).
If you have 32GB of free memory, then 20MB is insignificant. Installed RAM is not an interesting number.
I'm currently on a 16GB machine, where I only have a terminal, a text editor and a browser with few (<10) mild (wikipedia, hn, ...) tabs open. That gives 351 processes using a total of 8.7GB memory (2.11GB of which is unswappable, and about 1 gig of already compressed memory). My 3GB of disk caches go on top of that, and 0.5GB has already been swapped out.
I sure have room for a 20MB binary right now. However, on an 8GB system, I'd be in the red. I would already be swapping several GB, and any allocation would either evict (useful!) caches or swap out the memory of another process.
Any memory allocated in that state reduces the performance of some other component of the system.
Of course, 20MB is much better than the status-quo of casually burning a few hundred MB (or even a few GB) for simple tasks, and the situation of being out of memory with a whopping 8GB is caused primarily by the other "bad citizens", but the point here is that 20MB is indeed a quite big chunk of memory in real-world use-cases.
why is it obscene? Ram runs between $3-$10 per GB, so 20MB is 6-20 cents of hardware. That's far cheaper than using 20kB of ram in 1990 ($2 of hardware).
Disagree, the reason why it is so popular is because of its slick UI.
> and the functionality of an IRC client.
Disagree. Did you read the other comments? An IRC client is not the same as a SaaS chat service that keeps history, video chat, infinite scroll, allows communication to happen even if a user is not online, etc.
Sorry to sound so harsh but saying that slack is just an IRC client with a 1990s UI shows a complete lack of understanding for why it has dominated the market for business chat.
> Disagree, the reason why it is so popular is because of its slick UI.
I think you misunderstood my comment as being negative. I like TUI's, but it's a UI from 1990's, and the resource requirements for rendering such a UI has not increased since the 90's.
> Disagree. Did you read the other comments? An IRC client is not the same as a SaaS chat service that keeps history, video chat, infinite scroll, allows communication to happen even if a user is not online, etc.
You are missing the point entirely here. First of all, I am not saying that Slack should go away because it doesn't do more than IRC. I am, however, saying that I expect similar resource consumption.
But to tear the idea of there being a difference apart:
"SaaS" is irrelevant. It does not affect features, and Slack is just as much a service as freenode is. No difference there.
This client does not provide video chat, so that's irrelevant.
This leaves us with "history" ("infinite scroll" is just a UX decision) and "allow communication to happen even if the user is not online".
Communication to happen while the user is online is handled in IRC through an IRC bouncer. So, what you're saying is just that the Slack server has a built in bouncer. Not something that takes client resources, or differentiate it from IRC.
So in reality, the only fancy feature Slack has is synchronized history. This is a nice feature that IRC doesn't have, but it takes 0 client resources to implement. It just requires some storage on the server and a synchronization protocol, which could be as simple as "dump the history when the client connects".
> Sorry to sound so harsh but saying that slack is just an IRC client with a 1990s UI shows a complete lack of understanding for why it has dominated the market for business chat.
Sorry to sound harsh, but Slack does not differentiate itself through features. Just like Atlassian HipChat, it doesn't do more than IRC + 1 or two simple features (which in no way complicates the platform or increase resource consumption).
What it does is to wrap an entirely standard feature set in a package more easily consumed by the users in this day and age, that might be turned off by things like IRC. That in itself is an entirely fine proposition, and one which have had success. However, the features are indeed those of an IRC client, and the resource consumption should be thereafter, especially when you go full circle back to having a good old TUI.
For a lot of my projects I use SBCL. The runtime for SBCL is 50MB. That would be a deal breaker for me in 1995, but it is a reasonable tradeoff for the increased productivity I get from it compared to slimmer runtimes.
Huh, I very rarely hear about people using Common Lisp these days. Or Lisp at all, outside of Emacs Lisp (stories of Emacs Lisp often being tied to their nasty core dump hack).
What are your reasons for sticking to Common Lisp?
50MB "runtime" sounds quite extreme, even in this day and age. That's 2.5x the consumption of a fresh Node.js instance on my machine. :/
But I think it's more useful to think about the percentage use of RAM for a given application. If you're running on a machine with 32 MB of RAM, then using 20 MB for a single application is obscene. But if you're running 32 GB, it's insignificant.
Even so, a single application shouldn't be using a significant percentage of system RAM on an average consumer grade laptop/desktop (4 to 16 GB of RAM).