Seems like especially poor tone on an outage thread... “Don’t kick them while they’re down” or something?
This abusive resource usage has created a dislike of Slack among a subset of its users.
I'm currently sitting at 400MB total usage (including helpers) for 4 workspaces.
Fantastical, a calendaring app, is sitting at 333MB.
1Password is taking up 168MB in the background.
Finder, which I don't even have a window open for, is eating 127MB.
I'm not saying 400MB is amazing or anything, but it's a significant drop from the gigs of memory wasted by previous versions.
Using the browser based version often is less resource intensive.
This is a pretty reasonable complaint when you're talking about a system with 2gb, and a chat application that uses 1.5gb of memory...or heck, a 16gb system when you have programs that legitimately need as much memory as you can give them and are being starved of it. Nobody would begrudge this usage if it was necessary for the task, but it isn't. Not even close.
Edit: Apparently this is better than it used to be, but there have been times when Slack also ate up CPU like crazy. Which, again, no biggie if you have plenty to spare, but when you don't...and even then, if you have plenty to spare, you're still going to be annoyed with Slack if it's eating all of your battery because the CPU is working really really really hard at...um...dunno? If it were mining bitcoin/monero without your knowledge or consent then at least it would be DOING something.
Ire, jealousy, hate... There are a lot of bad feelings towards Slack.
These are not necessarily my feelings, but I'd be lying if I said I didn't dislike them just a little.
Not sure why you think OP can’t say “Slack sucks”.
1. While today's incident was unfortunate, Slack has been historically reliable.
2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.
3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity.
4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?
> 1. While today's incident was unfortunate, Slack has been historically reliable.
Screen sharing and video have not been reliable in the past month. With several public incidents.
> 2. There's a team of real people that works very hard to keep it that way. Using dismissive language just dumps all over their hard work.
I feel very little sympathy for an engineer who make couple of hundred thousands per year. Not accounting stock options, vacation, and work environment. And Slack won't fire the culprit.
> 3. It's easy to be dismissive but once you move away from Slack you'll realize how much an app that size gives you. IN other words the "sucks less" statement has shades of ignorance, and of course subjectivity
We invest our own time building integrations. Why should be doing that for Slack and not for the competition?
> 4. Why be rude at all? Even if you don't buy into any of the above, is it that hard to be nice in making a point?
I don't think OP's "It sucks" is dismissive or rude. You can be nice and still thinking something sucks. It helps no one to lie by choosing less explicit words.
Similar peeve is when people say “don’t politicize this tragedy.” No, politics is how we decide to act, a tragedy is exactly when we should be the most political. The Boeing 737 crashes is when we should excoriate and eliminate the rot at Boeing and the FAA, not six years later after some respectful silence.
Borrowing from Lin Manuel-Miranda's Thomas Jefferson:
> These are wise words, enterprising men quote 'em > Don't act surprised, you guys, 'anaphor wrote 'em
It's a nicer way to convey the same idea, without triggering a combative emotional response in reaaders.
Matrix[1]: maybe the most impressive. A chat _protocol_ with multiple server and client implementations, gateways to everything, and just out of beta.
Zulip[2] (as mentioned), Rocket.Chat[3], Mattermost[4]---Slack clones. open source, developement open to pull requests to various degrees, can pay to have hosted in cloud or get support.
Non-free or qualitatively different solutions include Discord, MS Teams, and the original IRC, I guess.
Apologies for any inaccuracies or omissions; I'm not an expert in the space.
[1] https://matrix.org/ [2] https://zulipchat.com/ [3] https://rocket.chat/ [4] https://mattermost.com/
- "replace email"
- "increase productivity"
- "centralize communication"
None of them. Not a damn one. I've worked at over 20 startups, there has never been a single case where any of these claims are true. They purchase one of these damn chat clients, and it becomes the biggest timesink the entire organization has every. single. time.
But, you know what? You can't get rid of it. Everyone has it. Nobody wants to change off of it. So what do they do? Introduce other methods of communication through other apps. So no. It doesn't reduce it. If anything it increases the noise.
Also, you think you make the right choice in the beginning. It seems great, your 7-50 people organization works fine. Wait until it's over 300 people, 1000 people. It becomes an absolute nightmare.
Slack is probably the worst for 1000 people organizations. It was horrible at 150, then at 300 you start seeing people fight each other over rooms.
Here's what the docs say, for reference (excerpt of https://zulip.readthedocs.io/en/latest/production/maintain-s... ):
> For an organization with 100+ users, it’s important to have more than 4GB of RAM on the system. Zulip will install on a system with 2GB of RAM, but with less than 3.5GB of RAM, it will run its queue processors multithreaded to conserve memory; this creates a significant performance bottleneck.
> chat.zulip.org, with thousands of user accounts and thousands of messages sent every week, has 8GB of RAM, 4 cores, and 80GB of disk. The CPUs are essentially always idle, but the 8GB of RAM is important.
As a practical matter, I think 4GB of RAM is not a lot to ask for a service that 100+ users are actually concurrently using all day. That's a small fraction of the RAM the clients are consuming; and you can get a suitable cloud machine from Digital Ocean (simpler pricing than AWS, so good for a quick price check) for $20 USD/mo.
On the implementation side, it turns out that a lot of moving parts go into a full-featured chat app. Here's a partial architecture diagram, plus detailed exposition: https://zulip.readthedocs.io/en/latest/overview/architecture... Database, plus caches, plus code for lots of features x running in a number of processes, adds up to a few gigs of memory.
The IRC server also doesn't store images or any other kind of file people want to show each other. There are lots of good practical reasons to want to share images in a conversation (e.g., screenshots), plus of course silly GIFs. That work also gets pushed out to add-on services.
When people say here that Slack or Zulip etc. are a much better user experience than IRC, I think those two things -- message history, and images -- are major reasons for that.
Message history means a database that gets big, and images mean a lot of data too. There's a large working set of both of those that you want fast access to. That means providing adequate RAM.
Works perfectly.
'Bot' scripts can also be added to do things like tell a channel when a repo has been pushed etc. Very handy.
I really want to like Zulip Chat. It has everything all the alternatives have + self-hosting, but as soon as they switched to their Electron client, it has become yet another resource hog that I have to put up with.
I already have to put up with 10+ electron apps slowing down my Macbook. I shouldn't have to make space for another to do the same.
FWIW I use Zulip every day -- I work on Zulip, and naturally we use it among ourselves -- and I never touch the Electron client, because I prefer the experience of a browser tab.
Chrome's task manager (shift-esc) reports that tab is using 281M right now. Less than Gmail, or some old GitHub tabs (>1G, yikes!), or a freshly-started VS Code (... oh wow, or my Emacs which is at 337M. Wasn't expecting that.) Not sure how that compares to the Electron app.
As another reply pointed out, there is also a terminal client! You might enjoy trying it: https://github.com/zulip/zulip-terminal
I just migrated off of and removed Atom, GitKraken and Github Desktop to only use VS Code but I don't think I am able to open Chrome or Firefox without it swapping out to my SSD. I have to kill two or three other apps to recover my RAM usage just to stop the constant freezing when using either browser. After sometime browsing the internet, I see a list of swap-files everywhere and eventually I run out of space.
So when I see another Electron app to use instead of Slack, I usually avoid it and I try to find another usable alternative if I can.
Beyond that, Zulip is open source and self-hostable, while Twist is not.
Side note, we have a chat about self-hosting set up on Zulip at https://homelabos.zulipchat.com/ with 85 members and growing. It's been great for new users to be able to come in and catch up on old discussions in a way that isn't possible with non-threaded platforms.
If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc.
"Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.
Except that IT can say "Complain to Slack or complain to your manager that we shouldn't use Slack. Don't complain to us."
This is remarkably valuable--doubly so if your management is stupid and regards IT as a cost center instead of as something useful.
> chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client.
Is that true? Take Single-Sign On, for example. That's remarkably non-trivial for IRC. I'm skeptical it's any easier for Matrix/Slack/etc.
> 1. We purposely made our commitment to the ‘fourth 9’, viz. 99.99% uptime guarantee in contrast to the typical SLAs which tend to offer 99.90%. We believe that extra availability makes a difference: the ‘fourth 9’ is important when your team relies on Slack every day. You need Slack at least 9,999 out of every 10,000 minutes. [1]
[1]: https://get.slack.help/hc/en-us/articles/204113126-Service-L...
What is the A part of Stack's SLA?
Disclaimer: I've done a GSoC project with them last year.
(I work on Zulip.)
(I work on Zulip.)