I just want something between this and Slack's mac app, which sometimes doesn't want to load on even Starbucks wifi. Ideally a GUI app that can load messages on airplane wifi would be amazing. Every time I try to open slack on an airplane it just sits there loading and loading and loading.
Yeah, I'm looking forward to checking in with eul in about six months, the idea seems promising but it's nowhere near usable (for my personal value of usable) yet
I'd love to try my luck with this, but I'd also love to use Rust and QT. I need to do a bit of research is this even possible yet, or is it going to be fun at all...
Oh man, that "you can't even see the messages that were in RAM when your computer went to sleep because we're doing... something... with your slow network" behavior is infuriating. I work a lot on airplanes and mobile hotspots, and it comes up depressingly often.
IMO that's a poor excuse, and leaves open a lot of room for competition. There's a lot of hubris in assuming their position as a market leader is unassailable.
There's also a fair amount of hubris in assuming that assuming that you know the market better than the market leader.
They're killing it for a reason, and it just may be that the market they're targeting cares more about the app Just Working than about the RAM consumption.
Slack is merely the latest contender in a very long succession of group chat technologies. They will be usurped one day, but they are substantially accelerating their demise by making their product so infuriatingly slow.
Microsoft is gunning for them hard with Teams. It's not really a very good product, but it might win traction just by being bundled into their Office 365 subscriptions.
Microsoft does have people on staff that know how to make an Electron app not suck really horribly, though whether any of that expertise from the DevTools branch makes its way to Office and the red-haired stepchild UC teams...
> assuming that you know the market better than the market leader.
I never made that claim.
> They're killing it for a reason
Sure, but who knows what that reason really is. I've gone through numerous cycles of "best chat app ever", and they're pretty much all in the dustbin now. I just don't see anything about Slack that makes it any better than several alternatives other than the number of users. In fact it's objectively worse than alternatives in several ways. The video and regular calling for example is pretty terrible on anything less than a high speed internet connection. In general the app often fails to load on weak WIFI. I can still use Skype, Discord, Gittr, Facebook Messenger, Signal, et.al. on coffeeshop wifi, but not Slack. You don't need to be a genius to see that this is a problem.
> There's a lot of hubris in assuming their position as a market leader is unassailable.
This is only your very free interpretation of the comment you responded to.
I personally only encounter slack in companies I freelance for - if it does not perform, I file a ticket with whoever does office supplies and demand a bigger computer.
Well yeah, of course it's just my opinion. I think my experience with Slack is pretty different, as I use it in my 9-5, and we often have to find work arounds for places where it's just plain broken. Specifically, the screen sharing and video calls often just don't work.
Sure, but who buys into a messaging platform because the client makes more efficient use of resources? Don't get me wrong, it's on the list of priorities somewhere but the decision to go one platform over another will be made miles above.
My criticism isn't just about RAM use. Slack is plain unusable on weak WIFI or slow connections. It also tolerates interruptions in connectivity very poorly. Video calling is more often than not terrible, and it has about the worst screen sharing experience I'm aware of at the moment.
If I were starting a new company, I wouldn't use Slack again.
Hipchat, Facebook's Workplace, and whatever Microsoft's service is are all competitors but I don't think any of them are serious. Hipchat is probably the biggest competitor, but that's because it was around before Slack.
When there's a serious competitor in the space, then I'm sure they'll start caring. For now, I don't think anything else is close.
It was always a website in nice packaging. Actually I don't want slack engineers to build a semi web browser, it's already crappy enough with the good foundations. A rebuild only increases one thing: bugs. Although Slack runs slow and GIFs in background are like CPU stress tests it does not have major bugs in functionality. Never touch a running system... it's easy to rebuild a simple chatroom experience but Slack is far from simple... it has a vast amount of features on closer look.
I know someone who uses the gateway but it was a long while before we (I) found out that he didn't receive edits or emoji reactions, which may or may not have caused significant miscommunications.
I've always used the sed style edits over the IRC gateway. Then someone let me know that they don't work. I always thought that people just read them and parsed the correction manually rather than relying on their client to do it. It's not like I use very complext sed substitutions.
It shouldn't take more than 1MB, but a "power user" with the stock Slack desktop client will probably see RAM usage of 1.5 GB[1]. So* GP was referencing the fact that currently the Slack desktop client is using >1GB and that is way too much.
* I recognize your sarcasm, but figured I'd reply anyway since the internet is a weird place and lots of people might not catch the joke.
It's based on Electron[1] which has a reputation for being a bit of a resource hog. The upside is that it makes it really easy to create a cross-platform app.
Slack gets pretty resource-intensive when the user is part of multiple workspaces. I know one of my co-workers is part of three or four, whereas I'm only part of the main company workspace. Co-worker's Slack memory usage is around triple that of my own.
how is it taking up that much data? I'm at 550mbs with 6 very active teams and while on voice chat. Dropped out of voice chat I'm at 340mb. Each team has 10-20 channels.
I also use Discord which uses Electron and with it, I'm on 8 separate active servers with anywhere from 10-30 channels. This sits at 115mb without an issue.
Can you tell me where these electron metrics come from where people have slack take up 1gb or even 2gb of memory?
> I'm at 550mbs with 6 very active teams and while on voice chat. Dropped out of voice chat I'm at 340mb
That's still a lot of RAM for a chat with giant emojis.
You have to consider that people reporting these issues with memory consumption are running the app in different operating system than yours. Maybe your system is optimized. I just checked my co-workers computer and his main Slack process is at +97MB but there are 3 instances of "Slack Helper" at +433MB, +297MB and +255MB respectively. That's over 1GB in total. So either you are just looking at the main Slack process (which at +340MB makes sense) or your Slack is leaking memory somewhere that your RAM monitor is not able to map.
I checked. I'm at 360mb for 8 separate Slack processes grouped together. I'm on Windows 10, not sure if that matters.
There are no Slack helpers.
I'm not sure why you're this adamant about it.
I still it's quite a good deal given that my Discord instance has a similar feature-set and is accessing just as many channels/servers/teams as Slack but at a third of the memory.
Current software stacks are incredibly bloated. I recently wrote a simple Java web server. I took care no to use unnecessary memory, I didn't use a single library for it, yet it can't do even basic functions without OOM unless I'm giving it 16MB RAM for heap (and it eats even more for other things). So almost 20 MB RAM for hello world. And that's for relatively efficient VM. I guess, similar web server written with C would use around 20 KB RAM (and most of it for I/O buffers).
That's such an unfair comparison, though (and really, with 8+ GB of RAM being the norm, 20 MB is still pretty svelte). Java has an entire virtual machine and runtime, whereas a C program is just a binary that gets loaded straight into memory.
You can't say "wow, look how much smaller the C program is" and then ignore why it's so much smaller in the first place (no runtime, no garbage collection, etc.) If that's the case, then we should hand-roll assembly all the time because it's "smaller". You also can't just call Java inefficient because it produces larger programs or is "slower". It's all about choosing the right tool for the job.
Perhaps Java should have been designed to scale down and not require all that stuff when perfectly reasonable applications don't need them all the time.
Then those "perfectly reasonable" applications are free to eschew languages like Java. People do it all the time to great success. People also use Java to great success. But that's neither here nor there. My point is that it's unfair to call Java programs bloated when the extra space is necessary to support the runtime environment that makes Java Java. I'm not arguing the merits of such a thing (indeed, swap Java with literally any other language), I just want it to be clear that C and Java programs run differently, and both languages/runtimes, such as they are, were developed at different times and to serve different purposes, and therefore it's not correct to bemoan that Java programs are larger. That's like complaining that JavaScript doesn't give you direct memory access or that assembly doesn't have classes.
Java theoretically taking a lot of care not to use excessive memory. It loads classes on demand, it compiles bytecode only when this path is really hot. I don't really see why it's necessary to use 16MB RAM. Golang has GC and doesn't that much memory. Lua has an entire virtual machine and runtime and doesn't use that much memory either. It's not a valid argument. I still believe that current JVM developers just don't care that much about memory consumption which is a valid decision, but I don't like it anyway. Not everyone has 8+GB of RAM. I have 256 MB VPS which runs quite a few of network services and has half of memory free, but I don't think that I could afford Java if I want to run something there, even if my load is tiny.
What's the advantages of using the client vs. using it as a tab in your browser? Tab in the browser seems to be working for me OK, once I figured out I could "pin" the tab in Firefox, which prevented me from accidentally closing it.
I work with three to four Adobe programs open for my workflow, even the browser version has a noticeable effect on performance. I actually run it on a $60 Amazon tablet next to my monitor (only because our organization insists on slack)
> A chat client should not be taking over 1GB of RAM
Why do you care so much about RAM usage? All this concern over RAM is completely missing the picture here.
Every conversation about slack or electron people complain about RAM usage. The market could not give two shits about RAM usage so why does everyone on HN complain about it?
Probably because their $3000 desktops are grinding to a crawl under these unwieldy stacks of cruft. The market might not care but that's only because most users are too naive to realize that spending hundreds to thousands of dollars a year upgrading their phones and laptops is neither necessary nor desirable. Eventually consumers in this space will gain more awareness and these wasteful software development practices will have to end.
1GB of RAM is anywhere from 25-50% of the RAM available on the average new (let alone used) consumer-grade laptop. For a chat app. And that's not even factoring in the OS overhead.
That's fucking bonkers. Objectively and scientifically fucking bonkers.
Because when you combine that with the silly MS overhead from useless processes because the team that controls your Win 10 environment insists on running Group Policy without a care.. then you notice that your machine is suddenly bogged down, when it's been running fine for the years you had total control of it! !!
Now I want a mattermost version of this; the mattermost native client for linux is so terrible as to be nigh unusable (I need to restart it every 24-72 hours as it just hangs regularly).
You could try this libpurple plugin for Mattermost [0]. Should work fine with finch if you want it to live in a terminal or tmux session or something, or else Pidgin or Adium if you want a more GUI look.
I actually do use this, but it is missing a lot of useful features, some of which seem unimplementable in IRC
One example: the mattermost clients won't register a message as "read" until you switch to that view, so if e.g. I check messages on my phone, I will see unread messages, but IRC doesn't have a way of communicating this between client and server so matterircd seems to mark all messages as "read" with mattermost)
Shameless plug: I'm one of the developers of https://github.com/matterhorn-chat/matterhorn which is a terminal-based Mattermost client for Unix-like systems. I haven't used slack-term so I don't know how it compares feature-per-feature, but we definitely try to make most day-to-day features of Mattermost usable from a terminal setting.
This cool, but not terribly usable right now if your team uses threads a lot. Thread messages are mixed into the main channel with no context and no way to reply to them.
So we've gone from IRC which worked perfectly fine to a billion dollar business just to port that software back to the terminal, where we started out to begin with
Well then everyone should feel stupid for not realizing you could make a billion dollars creating a sane sign-up and account management system for IRC.
Yes. As of a couple years ago at least, Slack was a monolithic PHP app that could support a few thousand users in a single team. Each “workspace” was assigned to a server and scaled vertically. LinkedIn notoriously had two Slack workspaces in order to support all of their users, and I’m guessing other large companies have had to do the same.
I’m sure Slack is using their vast resources and large team to solve these problems at this point, but it probably hasn’t been easy to create a horizontally scalable system from the early codebase, especially when the data model was designed for a single team of users.
So, I preface this by saying that I do feel like Slack could have better authentication mechanisms, decoupling the account from the networks. But I do think that some of this is by design as well.
I think it is worthwhile to think of each Slack organization as a completely independent and isolated network. This is one way that they can reasonably give some security to their corporate customers. I don't believe that there is any intention to ever lat you send a blind message to someone on another Slack organization, but maybe I am wrong there.
It would absolutely be nice however for me, as a user who is in multiple organizations, to be able to log in one time and have all of them be connected.
I'm in multiple organizations, but some are against different email accounts, some use an external SSO and some don't. Were Slack to give a single login I would probably NOT be able to connect to the multiple workspaces I do now, which is a major benefit to me.
...and push notifications, and offline message history, and a mobile client, and services that aren't hacky god-clients, and content storage, and previews/inlining, and....
About the only thing IRC has going for it is decentralization, and that's not very valuable in the market it seems.
Seriously. IRC has had 30 years to get with the times. It's stagnated and been lapped by its competitors, and the efforts to improve it didn't properly start until Slack and friends simultaneously re-cooked and ate everyone's lunch and dinner.
I pay for irccloud, but most people don't. It's annoying trying to talk to someone who disconnects when they shut their laptop and will never receive your message. Not very good tooling to build a community or relationships, that's for sure.
Having to pay for basic features that competitors like slack/discord have is exactly why the slack community for something is often much bigger these days. Even the larger communities like #node.js are really just 10 regulars.
For example, Elm's slack is vibrant. Elm's IRC channel is dead. This is the reality for most communities I've been joining these days.
Depends where you chat. Some rave/techno channels are still very active since the last 25 years. For English speaking crowd, at least #haskell, #rust and ##ibmthinkpad are having lots of discussion every day. But maybe it's just me. I've been using IRC since 1995 and I see it much nicer compared to the centralized bloat of a chat Slack is.
But it gives up decentralization (and privacy) and still requires that you have a server to connect to anyways (read: server to set up and manage).
And on top of that, the behavior of irccloud from the standpoint of everyone else is identical to that of a bouncer like ZNC. It's yet another hack around the fact that clients don't exist in IRC unless they're online.
I fail to see how those things should be part of the protocol. That's like complaining HTTP doesn't support tags for your bookmarks. It's so out of scope.
Unless, of course, you are talking about a user-friendly service offering IRC access to those who do not want to set up their own clients.
So, something like IRCCloud, which does exist, fyi.
I can’t convince my colleagues to use IRCCloud at least people will put up with using slack.
Rocketchat has much more feature parity to slack tbh. Comparing slack to IRC isn’t really fair even though they do the same thing.
I have used irc and slack and slack’s ease of use is its asset. I used freenode in high school and college to teach myself scheme. The barrier to entry is not something that can be explained as just use IRC.
IRC is an open protocol. Messages like what you see can be hidden by the client or suppressed by the server. And free intermediary servers can keep logs.
It's amazing to me how people think Slack is this amazing tool. If someone had thrown millions of dollars at IRC, it wouldn't suck.
But instead, you'll fork over your personal info and insist I do too.
Infinite scrollback is only possible with support from the protocol: if you assume that partitions happen between two servers or between the client and the server, then the client will not be able to see every message that happens so cannot provide the scrollback.
Unless your employer decided to disable that option because an upper manager didn't like the idea for reasons that I don't even understand. It's even more difficult when you are part of a corporation with thousands of employees that are in favor of using Slack over IRC.
A colleague of mine uses through irc gateway but tells me a lot of stuff is not supported well like threads (which some people unfortunately started using more) and that you can't see edits, which many people also do. I think attachments and files are also a problem.
And slack is complete garbage that is pushed and we as employees most of the time have no other options.
Besides the whole problems mostly talked about related to memory and cpu usage, the one nobody seems to check or understand is that it is completely frustrating and unusable from accessibility point of view. I've seen this first hand as that person above is blind and the slack application is of one the worst offenders there is regarding this point. I've seen and felt his frustration and how slack team manages to avoid his point all the time.
Your failure to set your coworker's expectations for your availability or the failures of organizational culture being projected onto the messaging tool are not the fault of the messaging tool.
How is this Slack's fault, again? Or is the argument that messaging systems should be hard to install so they aren't misused?
Seriously, what even is this comment chain getting at? If you work somewhere where always-on is a hard requirement, it doesn't matter what messaging system is used. Any place that would fire you for muting notifications would just as easily fire you for turning off email notifications.
In short: Let's stop blaming the damn tool for something that is the fault of the humans using it.
Other instant messenger are primarly (yes, some companies probably use Whatsapp and co for work stuff) for family and friends. "always-on" is different here.
Your corporate culture shapes use of the tool a lot more than the design of the tool, especially when that tool's essential components are identical across the entire set of competitors.
Slack doesn't have some voodoo set of features that make it more problematic than Hipchat or Teams or Stride or Mattermost or (nn programs elided).
If your org sucks, your communication within that org will suck too. Let's not burn down the concept of instant messaging in the name of sucky orgs.
One of my grievances was the missing ability to remove or at least drastically shrink most parts of the UI. When I set the window to the desired size, the actual area where peoples messages appeared was ridiculously small. One would think that's not how you treat the most important part of your UI.
which has its share of problems, just from the top of my head:
- you will miss edits
- in some cases when people sign up with their email addresses, you now have "info" and "mail" as nicknames, because they signed up with info@example.org and only the slack client shows "joe".
- everytime someone pastes a snippet, you'll have to open it in a browser anyway (ok, minor issue)
- The lack of conversations/threading is really annoying. Most worthwhile IRC channels have more than one conversation going on at once. Not only do you have to untangle who's talking to who, there's no way to know where the beginning of a conversation is. I have to read messages backward to find the beginning .
- By default there seems to be a lot of leave/join spam. I used IRC for a year before turning this off and it vastly improved my experience.
- I think most clients don't save anything by default. When I reboot my computer and don't log in again, I miss messages.
- Having to use pastebins for code is annoying.
I'm sure that someone will respond with how you can solve all these problems with a certain IRC client. But I don't want to do that. I'm not technically unsophisticated -- I write software in 5+ languages and I know all about Unix and networking. I just don't want to spend my mental energy on my chat client -- I have tons of other projects to spend it on.
So I only use IRC when necessary; I use e-mail otherwise (through GMail.)
Of course, I also don't use Slack. But from what I hear it solves some of these problems.
IRC solves these problems via things like bots and bouncers. Although running always connected irssi client [1] in a screen [2] on a server is probably the easiest way to achieve it.
And yet every thread about Slack (or Discord or Gitter or whatever) is full of people saying "why not just use IRC"?, as if IRC could replace a complete service.
IRC doesn't solve those problems; individual users solve those problems on top of IRC (and usually not very well.)
A proper open-ecosystem solution would involve network-level history-storage-and-retrieval nodes (basically archival peers in the IRC protocol), and additions to the protocol to direct archive-access queries to those nodes.
Not sure what you mean by "open ecosystem solution." IRC is literally just a few RFCs, a variety of server software, and a variety of client software. It's as extendable as you need it, and most networks have their own extensions already. Is that not open enough for you?
> IRC doesn't solve those problems; individual users solve those problems
As opposed to...? AI solving them? Do we need a corporation to hold our hand while we solve these issues? I'm not following what you're objecting to here. You're free to write and propose your own RFCs and extend IRC however you wish.
I was trying to contrast with existing solutions—IRCCloud, for example, "solves" the problem of history search by effectively wrapping IRC into a proprietary web cloud service.
By an "open-ecosystem solution", I mean a solution that applies to anyone and everyone who uses the IRC protocol, rather than only for users of some specific client.
I'm not saying IRC isn't amenable to open-ecosystem solutions; I'm saying that nobody has (yet) tried to solve this problem in an open-ecosystem way.
> As opposed to...?
As opposed to network-operators being enabled to solve these problems for users of their networks.
Consider the contrast of POP3 vs. IMAP. In POP3, the tasks of "email storage" and "email search" are left to the user, and often they'll solve them badly (by e.g. setting up direct POP3 connections from several devices to one POP3 account, ending up with random emails living only on one or another device, whichever one happened to pull them.) In IMAP, by contrast, email storage and indexing happen on the IMAP server, and users don't need to worry about it. But, since the solution doesn't involve any proprietary services, users can still "take control" of the process if they want—in this case, by setting up their own IMAP server. They just don't have to do that.
> You're free to write and propose your own RFCs and extend IRC however you wish.
I think we're in violent agreement about that. My point was that nobody seems to want to do that for the IRC ecosystem vis-a-vis network-level message archiving.
I think you are focusing on the wrong thing by spending several paragraphs on the problems with the out-of-the-box experience and only one on the fact that it is an open protocol so a sufficiently technical user can fix it.
An open protocol, free choice of clients, and decentralised infrastructure is a baseline. A change is not an improvement if it removes those. (You could argue you have valid reasons to remove any of them and you'd be wrong.)
I don't see why it would be much more exhausting to use a hosted IRC service like IRCCloud to solve your problems than pick a specific alternative protocol entirely.
> A change is not an improvement if it removes those.
If you see Slack as a replacement for IRC, then sure, it's not an improvement.
If you see Slack (and other proprietary solutions) as a capitalism-incentivized R&D lab for features that can then be absorbed into the open ecosystem, then it's nice that it exists, isn't it?
If you want "An open protocol, free choice of clients, and decentralised infrastructure" then Jabber and Matrix are both much closer competitors to slack. IRCv3 is a step in the right direction for IRC, but is not as far along as either of those.
I'm explaining to the parent why "I don't understand this world" isn't a reasonable response. If you've used Slack and IRC for 5 minutes, you should know why most users prefer Slack, even if you prefer IRC.
I don't use Slack regularly, but I have tried it, and it is instantly obvious what the difference is. If you don't see it, then you probably have never designed software for end users. (FWIW, I also agree that Slack is bloated and that's one of the reasons I don't use it.)
As far as contributing to free software and open protocols, I'm working on fixing Unix shell. It would be great if IRC developers would take some inspiration from Slack and other proprietary services and fold them into IRC. Although, as mentioned in this thread, some of that may be very difficult or impossible without a commonly accepted client.
And I understand it's not a one person job. It probably requires a more coordinated effort. Decentralization has drawbacks as well as benefits.
What is not OK is pretending that problems with IRC don't exist. If you have that view, and spread it, then you guarantee that open protocols won't win.
I prefer open protocols, and I lament what has happened to Usenet and e-mail (trying to set up a mailing list for my open source project has been frustrating; spam causes problems for mailman-type lists). But honestly the proprietary services have innovated. They're not better in all respects, but they are better in some.
Open source doesn't mean being ignorant of users and dismissive of their complaints.
(FWIW I didn't know about IRCCloud. It looks interesting and I may check it out.)
Unsolicited feedback for you @chubot, in case you're open to it:
Clicking through to oilshell - I wanted to know what is different and exciting about it, but all I found was text saying it's "new". Making the value proposition clearer would go a long way and be a big help to people who are curious and geniunely want to understand what's amazing about your creation.. !
Thanks for the feedback. I thought I had solved that with the "Why a New Unix Shell?" link at the very top, but I understand you still have to read a bunch of text to answer your questions.
My main goal right is to have sophisticated users try it and give bug reports. It's not ready for people to use as their daily shell (and that isn't even the primary purpose of the project. As explained in the FAQ, I'm focused on shell as a programming language first.)
Some people have tried it and reported bugs, but I could use more reports. So I suppose I could try to sell it a little more and maybe get more feedback. But overall I feel like it's gotten a lot of feedback and attention. I'll think about whether it makes sense to "sell it" more.
The other thing I would like is to attract experienced developers who have implemented VMs and programming languages. Most of those people are working on their own projects. But I think many of them understand my project and half of the blog posts are aimed at that audience.
Slack addresses some of the problems, but not all:
> The lack of conversations/threading is really annoying.
Slack is arguably worse - they recently added threading (really comments that can go on a post - there is no nesting), but this has made me much more likely to miss any follow-up because messages are less visible than otherwise.
> By default there seems to be a lot of leave/join spam. I used IRC for a year before turning this off and it vastly improved my experience.
This is entirely client dependent, so not really a fault of IRC. Slack has the same option, it just defaults to not displaying it like clients as opposed to whatever IRC client you used.
> I think most clients don't save anything by default. When I reboot my computer and don't log in again, I miss messages.
Yes. I don't know the inner workings, but generally if you're offline on IRC you will miss anything directed at you. Slack definitely addresses this, and it is my favorite "feature" - it means that Slack is not good for only casual discussions. (Slack's search is my second fav, and there's nothing special about that, it just works well enough that I can usually find that comment I vaguely recall someone making within the last 6 months on one of the many channels I'm on).
I expect this is largely a client issue, though I also imagine that most IRC servers have a very limited amount of immediately available conversation. Remembering that you have direct messages waiting for you would require servers that reserve nicks. That's all guessing though.
- Having to use pastebins for code is annoying.
Slack allows for posting code in text, posting text "snippets" that can include code, and posting files that can be downloaded.
Overall your frustrations seem very reasonable, but from the sound of it you're "hanging out" on IRC channels that are being friendly for outside users to drop in and out, and for devs to have conversations that are considered temporary. Plus not having users post goatse pics or worse. Which means they aren't even TRYING to accomplish what you want. Hard to blame IRC in that case - those features aren't used even when available.
I'm not exactly saying "You just need to use IRC client X" as you predicted, but more "you probably just need to change a config and connect to IRC servers that are INTENDED to do what you want". Not wanting to go through that effort is fine, and I'm not saying Slack and other alternatives are worse or even equal for those tasks, but don't blame the plane for not flying when the pilot is making donuts on the runway.
I'm responding to the parent, who was questioning the existence of Slack, because IRC already exists. That's not reasonable, as I explained in the comment you're replying to, and even more in another reply.
IRC doesn't work "perfectly fine", at least in the context of the problems that Slack solves.
I think we largely agree on technical matters; it's a matter of what relevance this has to the OP -- a Slack client for the terminal.
If your stance is that IRC is irrelevant to this thread because Slack and IRC solve different problems, then I might mostly agree. But I didn't bring up IRC!
> If your stance is that IRC is irrelevant to this thread because Slack and IRC solve different problems
I was saying you are comparing Slack to IRC-when-used-to-solve-a-different problem. You haven't described IRC as it could be configured to handle the same problems as Slack, only when you've encountered it in the admittedly more common case that it's intended for drop by traffic.
> The lack of conversations/threading is really annoying.
I find it interesting that people want to have threaded conversations in what is essentially a synchronous chat, but they prefer to have a degraded threading experience in their email client by using conversation view rather than traditional email threading using the Reply-To and/or References headers.
I created my own Terminal client to communicate with Slack [1].
I did it because I like IRC, but my employer (and many of my co-workers) love Slack.
I dislike Slack, having the option to connect to an IRC gateway (unless your employer disabled this option) or to communicate with their API service with a program like this one (linked above) or mine (linked below) is good for people who still need to communicate with their peers but want to do so through the program that they are more comfortable with, in this case, the Terminal.
Everything old is new again. ;) Okay, that’s a bit flippant. Obviously Slack isn’t IRC (with several major differences), but I think as far as communicating with your coworkers goes, they both accomplish the task. It’s just a matter of how much you want to spend.
I have arrived at the mindset that if you are in a technology company than all these people need to be technically-oriented as well. Failure to perform these fundamental tasks should be grounds for coaching or discipline.
Slack is a billion dollar company because they made IRC accessible to the non-technical people. Technical people write a terminal client for it because they like being in a CLI for reasons. Making a popular service look and feel like the older service that inspired it is completely reasonable.
Different people, different needs, different drivers. Just don't expect the actions and motivations of different groups of people to align with each other. Sure as a while it doesn't seem to make sense but each individual part is reasonable on it's own. There must be a powerful German word for things systems that look crazy at the macro level but are reasonable at the micro level.
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).
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. :/
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.
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.
I remember there was a multi-IM client called centericq which was console-based and pretty awesome. I used it for several years back when ICQ was still a thing.
Yes I know about irssi and friends, but they're not really having an UI, many things are commands or config based, but centericq was.
Obviously slack got something right, otherwise people would still use irc. It always amazes me how we devs fail to ack the business side of a success case as slack. And if any contender in the space fail to identify what slack got right they won't thrive.
Maybe it was the ui, or some particular features, but they did resonate with the users. And now they are the benchmark that all the others will compare to.
Same issues as IRC are same ones XMPP suffers from... Decentralisation becomes confusing and the benefits are not obvious to regular end users. They just want to be on one network and download the "app" for that network. Slack and Discord fulfill these roles. IRC and XMPP have a dozen clients and no default server to join. I still think a well intentioned IRC client could do wonders for IRC.
I would hope that people would spend their effort improving open systems instead of closed ones. The same effort could be spent improving matrix (via a terminal client if one of the existing ones don't suit or improving the slack bridge or implementing features slack has and matrix is missing)
While I would generally agree with the idea, I think it's also important to see that people aren't always in the position to choose said open systems.
I presume most of the non-commercial projects posted on HN are started to scratch an itch of the autor, which might as well be that they're stuck with a closed system that sucks. Trying to improve that situation somewhat seems sensible to me.
reply