Hacker News Reader

Comment by mmanfrin | Hacker News Reader

There are two camps: the we-should-just-use-irc camp, and the we-need-every-feature camp. You fall in to the former, and I would bet that a lot of people here fall in to the former.

However, many people fall in to the latter, and Slack handily beats the competition there. There is also an element of having nice and polished features baked in that appeals to many people. Want it on your phone? There's an app. Want to search? Baked in. Want convenient chat bots? Click a button.

To be sure, all these things are possible in IRC and other lo-fi chat protocols, but getting them set up is easy on Slack. I see this as similar to the argument of Linux vs. OSX. Linux can do practically anything OSX can, but it requires tweaking and setting up. It's a battle of pick-and-choose vs having it all baked in.

View on HN

It seems he is in a different camp, specifically the one where you aren't on a chat application all day

You're in the mute-everything-non-critical class, which is a good practice regardless of the client. If they really need you, they'll ring/call/DM. Otherwise, you can check it whenever you're ready.

I think you're confusing communication throughput with latency.

I also don't like using chat at work. It's not because I want less interaction, it's because I want less interruption. Email has a norm of asynchrony where I can respond to email when I reach a good point in my current task. With chat, the other party is presumed to be sitting staring at the screen waiting for my reply, so I have to drop what I'm doing to respond.

I don't think the latter is good for my overall productivity.

I have a different expectation while using Slack. I agree that enough people have your expectation that it's something that should be discussed and agreed upon by everyone using the 'chat' system... Slack provides an easy @channel and @everyone mechanism to control notifications.

I completely agree. It is also the effort to interruption ratio that has reached a tipping point. Once upon a time if I wanted someone's help right now i would have to walk to the actual desk, and bribe them with caffeine or chocolate. If the effort of levering myself out of my chair was greater than the benefit to me I stayed put - hence interrupting another person had a minimum price point - the other person may not like it but the price was paid in public and there was a perceived value to the business.

Phones reduced that price point - but it still has a cost to me.

Now IM / Slack has flipped it on its head - the cost to the interruptor is negligible but the cost for the interruptee is their mental derailment - and no ability to judge the overall benefit of helping until it is too late

Plus I don't really see the win - for real time co-ordination it's hard to beat a mass phone conference ( we are doing a complex release with phased rollouts and devops watching the traffic - then get your headsets on, and everyone must hurry up and wait)

Slack is just secondary for that - useful for spelling out what has been said but otherwise ...

For letting others know what has happened - that's called an after the fact report or "email".

So really i don't see the use case except it means that when like the phone, i reach you i am confident of a reply in a given time period - that may well be defining facto

I find clients tend to call to ask "a quick question", this is very disruptive. My experience is if they can't be bothered putting it in writing, then it's probably not very important.

Have you considered that just might be your own psychological burden though? I mean, plenty of people I know respond to slack messages a few hours after the fact, and I myself don't feel super guilty for turning it off for a few hours, and nobody seems to care.

I have never expected that the other party is sitting and staring at the screen in any Slack or chat I’ve used. An @mention will change the expectation of interrupting or not, but as someone who has used various chat programs for 24 years of my life, this ha never been an expectation I’ve had, nor one I’ve seen too frequently expressed.

What do you think has caused that expectation in your mind? Do you wish that for the people you’re chatting with? Have you worked with people who do expect that? Honestly curious.

I wonder how my growing up with it, and in chat rooms with mostly tech-savvy folks, has affected my use and expectations of it, too.

I've used Slack when contracting at companies (remote and sat in the same room)

> Have you worked with people who do expect that?

Yes. Manager expects it to be like talking to you across the room. You answer there and then. If you slack him though he doesn't expect to reply immediately and gets annoyed if you interrupt him to say you really need an answer.

> Do you wish that for the people you’re chatting with? Yes, saves making a telephone call.

There again, if I Slack someone, it'd better be important not time-wasting.

> I have never expected that the other party is sitting and staring at the screen in any Slack or chat I’ve used.

OK, maybe not literally staring at the screen.

> What do you think has caused that expectation in your mind?

I think the structural analogue and communication style — even the name! — of chat is a verbal conversation. In a conversation, you say as little as needed and then pause for the other person to take their turn. Each utterance is pretty short so that you give the other party a chance to respond.

If you do that asynchronously, it takes forever to work through a sizeable quantity of content.

In email, the analogue is written letters. The expected asynchrony is high and in return the writing style accommodates that: each email is usually a roughly complete though with possibly some paragraphs. Since you know the person replying to you can reply to individual sections, it's OK to put out a complete thought. You don't have to shorten it to give them a chance to interject.

I do that but it's not the same as not having a chat I'm expected to be checking.

> Otherwise, you can check it whenever you're ready.

It's the "check it" that's a mess in a high-volume environment.

E-mail threads that can be seen to branch, and in a pinch I can skip irrelevant branches once I've determined their vector.

But each Slack channel is a continuous stream of text with a tiny scroll slider. There's no possibility of skipping a couple of pages of messages unless one just seaeches for direct mentions, at which point why bother? If it's important they'll just ring / call / e-mail..

Not directly relevant, but it's possible OP is a girl, so not necessarily "he".

It’s possible I’m a fish person, but not likely. And this adds nothing to the discussion.

> There are two camps: the we-should-just-use-irc camp, and the we-need-every-feature camp.

I'm firmly in the "email should be used for substantive discussions" camp, but ever since we got the bandwidth and CPU necessary for the internet to not be a primarily text-based medium, the illiterates took over and that was the end of that.

Email has a lot of problems, but the dealbreaker for my company is that it isn't secure.

And you somehow trust Slack as a "secure alternative"?

Where did I imply that? There are tons of options for business chat. My point was only that email isn't even in the running.

If you want secure emails use GPG. Unlike slack, GPG is both open-source and offers government-level security. I don't think slack is more secure than GPG.

And how does that work for your average person using outlook / google for email?

Then build on top of email, instead of developing yet another 'secure' proprietary system.

If that were viable people would already be doing it. It's not, and so very few people are. I wish this weren't the case but it is.

Companies are generally at more risk from failure to produce message content in a lawsuit, regulatory action, HR investigation, etc. than from eavesdropping. "Secure" in a corporate setting means subject to IT's surveillance, filtering, and archiving. If anything, security's job is to make sure employees aren't using things like PGP, personal webmail, Facebook, etc. to evade corporate retention policies.

Maybe mysterious quasi-state actors will steal your secrets and outcompete you decades from now, but they could probably do that anyway. The SEC will certainly fuck you up right now if you can't demonstrate adequate controls on regulated employees' communications.

I'm talking about personal e-mail. Still businesses can easily enforce retention policies with PGP by using a master key.

The security model for internal email on a corporate email server is pretty similar to a corporate slack instance.

I've never seen any email system used securely. Even smart people will send sensitive info to a personal address instead of corporate, for example. Email wasn't purpose-built for controlled internal comms.

Part of this is a UI problem, but it's still a problem.

I didn't say Slack is the answer, either. Just that email isn't a serious competitor to Slack.

That's a little too harsh. Not everyone is good at expressing themselves through an email chain; doesn't mean they're illiterate though.

It's very much a learned skill. I was fortunate to learn it well in school (and polish it further in my professional life). People who haven't learned to express themselves clearly and concisely are indeed to the left of me in the spectrum of literacy.

But again, it can be learned by everyone, it just takes time and effort.

Not everyone is good at expressing themselves in a real time conversation, either. Any medium of conversation excludes people who aren't good at that medium.

But if you have to choose a medium of conversation, are you better off choosing one that excludes introverts, non-native speakers, and people who aren't loud and obnoxious enough to command the room? Or would you rather exclude people who lack the patience or intellectual ability to read or write more than two or three lines of text at a time? Which choice allows deeper and more thoughtfully considered ideas to enter the discussion?

I'm loud and obnoxious enough to thrive either way, but I really don't want important professional decisions to be made by the "rofl tl;dr" crowd.

That's kind of a false dichotomy you've got going there. Introverts and non native speakers are all slow deep thinkers who need a thinkers medium to communicate, which is slow by your definition. Everyone using a quick communication medium is a moron though right? I assume that's what you meant by people who lack intellectual ability.

They are just different mediums. Long form is better for getting across new ideas that have to be explained for the first time, but a medium like emoji allows for incredibly dense communication with single glyphs once the meaning has been established

It’s not a false dichotomy because it’s not a dichotomy: I’ve mentioned that I myself can communicate effectively either way. A lot of people can.

Email is crap for many types of workflows that Slack excels in.

It’s too bad most of those workflows don’t apply to business use cases.

Is it a chat client? A knowledge base? A conference call? A command line? Who knows!

> It’s too bad most of those workflows don’t apply to business use cases.

Which is totally why Slack isn't popular with businesses. /s

Just because you personally haven't found it useful, doesn't mean hundreds of thousands of other business users haven't.

Businesses pay for a lot of stuff that doesn't work. Simply saying everyone else is doing it is not necessarily convincing.

I'm curious as to how that breaks down? Which kind of workflows are best in email, which in Slack?

_This_ is the 64 thousand dollar question that no one seems to have a clear answer to, and leaves people frustrated with both email and slack.

I tried emailing longer form things at my current job and rapidly hit a cultural wall: people _do not like_ getting long emails, or emails with more than 1 or 2 replies. Slack people apparently have no problem with because it's "lighter weight", but I struggle to see how always-on disruption is lighter weight than check-it-a-couple-times-per-day email.

I think a deeper problem is lack of delineation of responsibility and adequate planning. Slack & other "always on" communication systems make it easy to say "why plan? I can _just ask_ when I need to know something" or "we'll have a conversation" rather than specifying & recording or relying on a more rigid interface like a ticketing system.

tl;dr: get off my lawn you dang kids!!

Featured specifications work better in email, live debugging/forensics work better in Slack.

Featured specifications work better in source control...

You can have both with git format-patch/git send-email and git am :)

Email is crap because there is no agreed on way to structure old and new content, quotes, references and links, everyone insists on bloating with html signatures and crap that isn't part of the discussion.

Additionally, all this bloat and lack of structure makes it hard to search the text for both humans and machines.

Not saying that Slack is better, it addresses some of the structuring and some bloat problems, but adds distraction and encourage discussion bloat instead.

There's way too much noise in my email inbox, stuff gets lost.

Important/immediate discussions take place in person, or on slack. (Or hipchat or sametime or lync or windows messenger or hoary old ICQ for all I care...)

> There's way too much noise in my email inbox, stuff gets lost.

I find that happens an order of magnitude more often in Slack than email. The number of times important things here don't get done on time (or at all) because "Oh, I must have missed that in Slack...)

Email can also create bottlenecks and unneeded silos of information...

Sorry to get triggered but oh my god I dislike those buzzwords. I find those two come up any time attempts are made to delineate responsibilities or make it possible for teams to run in parallel (by saying "you work on this area of speciality, I'll work on that" i.e. "silos").

Ehhh, you kinda mixing problems here.

I'm firmly in the "email has no place in internal discussions whatsoever" camp.

Tasks belong in tickets, long-term documentation/policies/meeting notes/etc belong in shared space (wiki), and discussions are faster and more productive in realtime (in-person, video call, or chat). E-mail might kick some of this off, or be used to schedule, but that should be it.

The problem I think most people run into with the realtime discussion is failing to document the outcome of the meeting -- and that of course goes into a ticket or long-term docs. A meeting with no notes or outcome might as well have not happened.

Your suggestions may work inside a company. E-mail is the only federated system we've left. If you need to contact somebody outside it, you're screwed. XMPP/Jabber could have solved some of this, but it's pretty dead right now.

The org I work for has a bunch of Slack channels that we invite our clients into as single channel guests (If they don't already use Slack). We have Gov & corporate using it without issue and they love it.

I generally agree with greg, and that covers 90% of the cases, for the times where Email is used with external entities, it usually gets dumped into issue tracking / wiki

Most work communication is usually within our issue tracking system

We use slack very lightly,

- most of our conversations are face to face but anumber of remote employees, and slack is used instead of face to face. Often for video calls

- copy pasting things to other people

- a sort of mini internal HN where links are posted to interesting things in the dev world and we discuss

- prodding people "Oi, my PR is still waiting .... " "did you setup ... ?" etc

- telling people where we went to lunch so they can find us.

I think if you ask Slack about that they'll happily tell you about Slack Grid.

EDIT: Whoops actually Shared Channels is the feature I was thinking of: https://slackhq.com/introducing-shared-channels-where-you-ca...

"discussions are faster and more productive in realtime"

Real-time discussion is great if you don't have to think about what you're going to say before you say it. Unfortunately, that places a very, very low upper limit on the level of depth and consideration that a discussion can reach. Some decisions are hard enough and some situations are nuanced enough that you need to take your time with them, enough that the additional cost of making all of that time strictly synchronous can grow exponentially.

It also excludes large categories of people, including introverts and non-native speakers. I've worked with a number of people who just flat out did not or could not participate in real-time face-to-face discussions, but who could express themselves masterfully via email.

Of course, the "faster! instant! now! now! now!" crowd don't even have the patience for slower, deeper, better-reasoned discussions, which is why they shy away from any form of communication that has any more depth than a tweet or a PowerPoint slide. Slack is great for these people because they don't even have to string words together to communicate, they can just click on a reaction emoji.

Sure, some things (operations, for instance) have genuine urgency to them, and I think real-time communication is essential for situations like that. But if you're doing work that will have an impact on the span of months, quarters, or years--either major strategic business decisions, design, or project development--you're better served by thinking deeper instead of thinking faster, and deep thought is exactly what the long-form written word was invented for.

I agree with you and I feel your points are well articulated. I especially like how you summarized the internet as 'the illiterates took over.' Very poignant, indeed. So much of the average person's internet usage boils down to memes and videos, it's quite unfortunate.

One thing to think about with respect to memes and videos is they may evolve to be more dense in their ability to symbolize and convey a much larger amount of information.

There are so many examples of teams successfully communicating state, sentiment and other information among each other with memes and videos an what not.

Also, to help people blow off steam. We don't need to be absolute productive units operating at 100% all the time.

Goofin off is healthy

I don't disagree with not being productive 100% of the time. My gripe is that for many non-tech people, their computer time is majority memes and videos. The ratio is all wrong, IMO. This incorrect ratio has created the click-bait internet and other scorns of the modern internet IMO as corporations are catering to the masses.

The internet is such a large collection of knowledge, I just wish more people used it to improve themselves, or at least their understanding of the many different things we have in the world.

Goofing off via chat has been a thing since IRC, and you don’t really need much above and beyond IRC to goof off. And if tech companies treated Slack as belonging to the same class as ping pong tables and kegerators, that would be highly appropriate. But they treat Slack like it’s a serious business communication tool.

Its superficial to suppose the immediacy of slack is its only feature.

The reality is that email fails to serve the purpose for complex discussions that involve many people, especially when you're using a rubbish email system like outlook.

Another form, be it meetings, chat, forum, whatever is required for this... and to be fair, gmail and the like offer some form of searching and sorting nested threads...

...but your complaint is broadly the same as the argument against having meetings in general.

Certainly, it is an oppinion, but not helpful or realistic.

Slack is disruptive, but 'just use email' isn't the answer.

Outlook may very well be shit, but that’s largely because business/enterprise email products are optimized for the same PowerPoint-addled minds that Slack is. Rich text is where email first started to go wrong.

Seriously, go read the lkml archives sometime, and go tell the authors of one of the most important and high quality pieces of foundational software in the world that they would be better served with something like Slack.

One of my biggest frustrations with e-mail as long-form discussion like this is misunderstanding points. Someone will write paragraphs of text arguing their position, but they made a bad assumption or missed something simple at the start that either partly or completely invalidates the rest of what they are saying. Depending on if people realize this or not, it's easy to slip into a kind of bike-shedding discussion arguing about the incorrect details. I've been on both sides of this, and it's one of the reasons I dislike e-mail for it.

I tend towards being an introvert, and I'm not always good at coming up with an argument on the spot. I recognize this, and I will often end the real-time discussion by literally just saying "Ok, I need to go think about this before we discuss it anymore. Let's come back in a day or two." Just like you don't have to respond to e-mails the instant they come in, you don't have to do it for real-time or chat, either.

I will also do the same to others when I can. For example, yesterday I suggested a new approach to how a certain part of our product works, and pitched it to the team. There was only minor feedback so I just said "okay, go think about it, and I'll bring it up again later", so I will probably ask tomorrow to see if anyone has further thoughts on it. It's amazing what sleeping on ideas can do.

The thing I'm really trying to get at here is real-time doesn't mean "now! now! now!". There's absolutely nothing wrong with several meetings over the course of days or weeks or months. For strategic and key design discussions, there should absolutely be documentation written between those discussions. In fact, that's basically the way I operate: discuss, document, give time for people to review, and then discuss again, repeating as much as needed.

There's people that are opposite and want the response "now!", and don't want to take time to think through problems -- but I would guess there's a large overlap with the type of people that come over to your desk / call you and say "I just sent you an e-mail, did you get it?" and then only read the first sentence or two of your reply anyway.

> The problem I think most people run into with the realtime discussion is failing to document the outcome of the meeting -- and that of course goes into a ticket or long-term docs. A meeting with no notes or outcome might as well have not happened.

I think the attraction of email is it looks like it short-circuits the need for this. "It's all in writing in the email trail" makes moving fast look easy (no realtime meeting that then has to be written up, the document amended on people's feedback etc). But understanding is missing and misunderstanding happens.

I'm starting to move an organisation's planning from emails into meetings and specifications. They are resisting massively because it "wastes" time. Given every project up to now has changed spec twice after launch, I see time being saved if it's correct at launch.

I'm in the same camp. In my company there is so much knowledge hidden in inboxes that should be available and searchable by everybody instead. I ask my colleague and be forwards me an email thread from three months ago where I was not included. This is inefficient.

> Tasks belong in tickets, long-term documentation/policies/meeting notes/etc belong in shared space (wiki), and discussions are faster and more productive in realtime (in-person, video call, or chat).

I wonder how much of this attitude is a result of poor email client UIs. I switched over to using notmuch for my mail about a year ago, and I now consider email to be a great place for discussions: I can search my entire history almost instantaneously, far faster than with Gmail or Inbox.

I definitely agree here. This falls under the heading of 'things we used to know as a society that we've forgotten.' Every meeting should have an agenda, even it's just a single agendum 'discuss $FOO,' and every meeting should have some sort of minutes, even if they're just 'discussed $FOO, decided to pursue course $BAR.'

Email: Two use cases.

With email, how can I subscribe to conversations I'm interested in? Mailing lists are nice, but we have no real way to make mailing lists that start and stop on the fly like a chat channel in a way that is searchable to the entire organization during or after the fact.

What email list system allows for quick creation and the ability for everyone in an organization to know that a conversation is happening and how to join with the ability to get all the context necessary in a chronological order? (Reading threads can get really repetitive in a mailing list, especially when trying to get up to speed on an issue.)

You get to all the requirements, and you end up with a discussion board instead or a new product that is to email lists what slack is to chat.

Email is great for some things, but there's a reason people use slack instead even when they already have email.

> Mailing lists are nice, but we have no real way to make mailing lists that start and stop on the fly like a chat channel in a way that is searchable to the entire organization during or after the fact.

Isn’t that what subject lines and mail archives are useful for?

What's the mail archive that can be set up with the same ease of use and permissions as slack? What, are you going to say hypermail?

Nobody has put together a simple solution in the mail domain. Maybe there's a market for it - turns out someone might pay for it if it's better than the slack experience.

> You get to all the requirements, and you end up with a discussion board instead or a new product that is to email lists what slack is to chat.

This would also be acceptable IMO. Any medium that enables asynchronous long-form written communication has advantages that are fundamentally impossible for any synchronous chat medium to match.

It turns out that listservs have successfully done this for decades. If there was even a fraction of the effort invested in this communication style as is invested in reinventing IRC with emoji and reaction gifs, I'm sure it would be even better.

Our product https://www.fwdeveryone.com does almost all of what you’re looking for, and will do everything within a few months. (We still need to add live updating threads, and we’re also working on an add-on so you can upload content directly from gmail.)

I like it, and that solves an interesting use case. I'd say there's a use case of assumed-private email and assumed-public email, and you're trying to solve both at the same time. What I'd want is basically this combined with a mailing list system where mailing lists could be made and ended quickly - like a slack channel, that ties to this.

I hope you all do well with this!

> With email, how can I subscribe to conversations I'm interested in?

There's always newsgroups, which use NNTP (which isn't that dissimilar to email). They have existing groups in a hierarchy that can be subscribed to. It doesn't really give users the ability to create new newsgroups in the fly though.

Are there any resources on deploying your own internal NNTP service

The standard software package is called INN ( https://www.eyrie.org/~eagle/software/inn/). It should come pre-packaged in upstream repositories for various linux distributions.

> the illiterates took over and that was the end of that.

That's pretty arrogant. Perhaps people have different communication styles than you. Not better, not worse... just different.

What word would you use for people who are incapable of communicating through the written word? Or for an Internet that is increasingly designed to cater to such people?

The dialup-era Internet was mostly text and a little bit of pictures. There was good text, bad text, and lots and lots of fanfiction, but at least it was text. Even if you went to The Onion, there might be one goofy photoshopped photo but you had to read an actual article with real paragraphs to get the jokes. Now everything is a video, or a picture, or a meme, and everything longer than 140 characters is “tl;dr”. That’s a cultural decline akin to when television displaced reading in the mid-20th century.

I can communicate in either style, so it’s not a personal thing from my perspective—except, since I can communicate in either style, I can also tell which style is more conducive to deep and meaningful discussion.

> I'm firmly in the "email should be used for substantive discussions" camp

I wish there were more people who were in the "newsgroups should be used for substantive discussions" camp. They're better than email in that context.

I never had a chance to get into newsgroups that much, but I believe you.

> the illiterates took over and that was the end of that.

That's a very harsh attack and I'm sure you're aware of all the nuances you're conveniently skipping over. I'm not sure how you think this adds to the discussion at all.

Email has unfortunately become "I don't check it or care anymore"

I am flooded with automated notifications that basically are "who gives a shit". I think the main reason I use email is for password reset. When you receive 1-2 thousand emails of non-spam but still unimportant cruft, it gets ignored or overlooked.

Email is pretty much dead to me as a meaningful way to communicate.

Sidenote: the term "ping me" needs to go away.

I don't see any compelling reason to adopt IRC. It does nothing that I care about that Slack doesn't do. If Slack completely implodes, I would search for Slack alternative. If IRC really was my only option, I'd use it just long enough to write a basic alternative myself that replaced or extended IRC w/ the features I really want.

I don't see any compelling reason to adopt Slack. It does nothing that I care about that IRC doesn't do. If IRC completely implodes, I would run my own IRC server.

> I would run my own IRC server

That's nice for you personally, but how does running an inhouse bespoke IRC server have anything to do with whatever line of business your company is in?

IRC is horrible on phones (shitty history when you drop out of an internet connection, no cross-device unread-count synchronization, no encryption or login, etc). There are add-ons that try to fix that, but it's still a giant pain.

I personally love Riot and Matrix as a "modern IRC".

The Lounge is an IRC client that solves the problems you describe (persistence on any device, synchronised unread counters, push notifications) - https://github.com/thelounge/thelounge

It does require having your own server to host it on though.

Hadn't seen this before. Looks nice. I tried the demo, smooth other than the /j is not an alias for /join, which I think is an obvious oversight.

For one thing, an IRC client doesn't pin a core of my cpu at 100% and consume half a gig of ram...

(But I realise I'm well out on the losing end of this argument, even in groups of old-school hard core technical friends/colleagues, I've been given the "crazy look" when suggesting we just use irc for chat... )

Slack isn't perfect; I agree with that. I haven't experienced the CPU issue, but it does seem to like RAM quite a bit. I just opened it w/ one account active, and it was eating maybe 400MB of RAM. I bumped that up to 6 open accounts, and now it's chewing up maybe 2GB of RAM.

I'm quite fond of emacs-slack, which is a much better client experience than the Slack 'web' UI.

> pin a core of my cpu at 100% and consume half a gig of ram...

I'm not doubting you, and I acknowledge that I hear that kind of thing with some frequency, but I've not seen Slack (running in Chrome on Ubuntu) use anything like those amounts of resources.

I've had a pretty busy slack client running for several days, and it's using 204,484K of memory and 2.0% of one CPU.

200M/2% is still pretty bad, isn't it? IRC clients worked perfectly on machines with less total virtual memory 20 years ago (and before).

    USER        PID %CPU %MEM    VSZ    RSS TT  STAT   STARTED      TIME COMMAND
    fubar      2922  0.0  0.1  61648  26668  2  S0+    19Mar18  22:58.73 weechat

I hear you! I've been using the Internet most every day since 1988, and am still occasionally struck by the amount of resources seemingly straightforward programs use these days.

Re: Slack resource utilization: I'm not passing a value judgment as much as expressing confusion over multiple claims I've noticed about Slack utilization that is far, far greater than anything I've seen.

I had this problem with Slack. I switched to using it within Chrome. I can't be sure why it performs so much better that way (Chrome throttling it?), but it does.

If I had an irc server/service were I could easily login/control access with a Google domain account... <3

I like this approach very much.

IRC is just a particular implementation of chat. The only thing keeping it relevant is the several hundred thousand people currently connected to servers.

Within a more defined context, such as work communication, adoption network effects become irrelevant. You can just build your own system and set everybody up to use it.

I'm in the camp that Slack is a great UI for work chat, and that work chat is for low latency, low bandwidth communication.

If I want high latency, high bandwidth, there's email. If I need low latency, high bandwidth, that's an in person whiteboard session or a video call.

That does mean I think Slack is overhyped... but that also means I think Slack does something valuable. Just maybe not as valuable.

Hipchat actually outperformed Slack for my team in every respect, with three exceptions (all of which were supposed to be solved by Stride):

1. No markdown support and half-assed code highlighting support. 2. No (real) message editing. 3. Silly parenthesis based emoji.

Its search is better than Slack’s; its performance is better than Slack’s; its integrations are better than Slack’s; its client memory and CPU usage are better than Slack’s (whether in a tab or as a real, native app); its group video chat is better than Slack’s (does Slack even have video chat integrated, with screen sharing?). Most importantly for us, its price was 4x better than Slack’s all while offering better features, performance, etc. The only thing it didn’t win out on was hype. (It should also be noted that HipChat could also be bought in a self-hosted configuration, which allowed for HIPAA compliance, something that Slack won’t even bother competing on. I didn’t need it, but hey, it matters to some people.)

Slack is an overpriced distraction monkey. They’re selling it like it’s the whole enchilada, but it’s a damned feature bullet. I personally cannot wait until Slack is dead, because it’s the worst chat service I’ve ever used (and I love full-featured integrations).

Now, I have to find a replacement for HipChat that won’t cost us US$200 per month for our office (if we pay a year in advance, more if we don’t).

You and I have had very different experiences with Hipchat. The search is terrible, the integrations are worse, the mobile app hardly ever sends me notifications when it should, there's almost no customizability, the native app randomly drops messages. For me, Slack isn't hype, it's simply a better product.

The lack of Slack on-prem over HipChat is a deal killer for major Enterprise. You can justify "cloud" when Microsoft is running it and has millions of dollars to put into feasibility and security studies and audits.

Letting a strappy upstart have access to that data is a completely different story.

This point is spot on, but often overlooked.

Disclosure: I work with Flock, a messaging product.

I think even though the industry is fairly nascent, a lot of team messaging products seem to occupy unique sweetspots. It's probably just a case of which product suits an individual's/ team's working style more. In fact, I have seen different people rate the same set of features in contrasting ways.

That said, a lot of stuff which you mentioned resonates with features we feel are critical as well (integrated group video chat with screen sharing, seamless integrations, better pricing, among others). We have had a bunch of Hipchat users migrate to Flock over the past few months using our migration tool. Per the reviews we got, they found the transition pretty seamless. If you want to give us a try, reach out to us at support at flock dot com. We do have some offers for Hipchat/ Stride users :)

The different in the Linux/OSX comparison is that Linux is constantly improving. IRC hasn’t changed much in years.

> IRC hasn’t changed much in years.

https://ircv3.net/

It's changing a lot for some time now.

A set of RFCs isn't really in the same ballpark of the same planet of the same local galactic group as a mature product that I can go sign up for and be using in under a minute.

Maybe in a few years. I say maybe, because XMPP is an IETF RFC, and frankly, it sucks.

What do you not like about the protocol? Like everything, it has its warts, but having worked on a few more-or-less proprietary protocols XMPP is much better designed and thought out than most of them. The community has had a lot of time to address some of its flaws whereas Slack, Stride, et al. tend to reinvent the same problems XMPP solved 20 years ago.

Let me just start by saying that I'm a big fan of XMPP. I run my own server, and talked to my friends exclusively through XMPP until that fateful day that Google turned off federation support for Gmail chat, and I lost contact with a bunch of friends. I still run my own server, though I don't use it nearly as much as I used to.

XMPP is a well-thought-out protocol, and a lot of the XEPs are great features. The problem I always had with XMPP is that XEP support is unequally distributed among clients, and the fragmentation really undermines the amount of cool features XMPP has to offer. As a (made-up) example, Psi+ might support video calls, but not server-side history, and Pidgin only supports server-side history, and Adium is the only one that supports Service Discovery...if I want both, I have to pick a client, and possibly have to use two clients signed in with different resources.

As a possible solution, we could have a "logo program" for XMPP, where a core set of XEPs are required to call yourself an XMPP client (this is the case already IIRC), and you get rights to call yourself "supporting XMPP-Enhanced" if you support these other XEPs, and "supporting XMPP-Full" if you support all of these XEPs. Something like that might work, but you'd have to have a way to actually drive development toward these features.

I'm going to be pedantic here, but I think it's important to be precise: this is a problem with the public/federated XMPP network (let's call the network "Jabber", since some people use the term that way), not with XMPP (which is a network protocol that could be used by any number of services). That is to say, XMPP==HTTP, Slack==google.com.

XMPP could be used to build a service like Slack (with its own clients, specific feature set, etc.) that may or may not be federated and it would still have the benefits of using an open protocol (even if it's not federated I can use a more accessible client, a client on a platform they don't support, less work to get up and running because libraries exist, etc.)

I'm hoping the Compliance Suites will become something like you mentioned in the future, but I'm no longer the author so we'll see what the new authors do with it: https://xmpp.org/extensions/xep-0387.html

I thought about this too. My idea was to introduce some sort of version badges, like 'This client supports feature set 2018'. Every 2 to 3 years there should be new definition of which XEPs a client should support in order to be allowed to be called 'Supports feature set xxxx'.

That way you could very easily coordinate a common target for XEPs. Clients which would not support the newest features would still work with the others but users could simply see which clients support the state of the art features. And for developers it would make it easier to identify and skip old XEPs (e.g. how many XEPs are there to confirm a message has been received? Which is the recommended one for new implementations?).

It's amazing - I've used IRC before but every feature is an indecipherable mess based on what it offers me as a user.

https://ircv3.net/irc/

IRC is interesting, but it doesn't solve the use case by itself. (IE, as a user I can easily look back to the entire history of the channel regardless of when I joined and can search every message that was ever sent on the server - or every message in the last 12 months even.)

I use that daily.

IRCv3 has some great features it’s trying to standardize: https://ircv3.net

Mean while, every single chat and IM application has steamrolled straight past.

I think ‘steamrolled’ is a little strong. Slack is more or less a pretty design on otherwise old concepts and ideas. Not to trivialize that: it was despirately needed.

Really IRC just needs some well designed clients, I don’t like any of the offerings I’ve seen for iOS or desktop.

When was the last time you used Linux? I installed Ubuntu on a Dell lappy provided by work, everything just worked and it required less tweaking than osx would have for serious SWE work.

I heard the same luring song for the last 20 or so years. If Linux works for you then enjoy it. Don’t even try to suggest that Linux is easier than Mac OS X because I don’t like liars.

it's easier for development. os x sucks, I use it to surf the web on my ouch. my real dev machine is in my office with linux

It "sucks", really? You don't think that might be a bit of an overstatement?

You may not prefer it, but it objectively does not "suck".

I would agree with most of what you said except for the point about Linux and OSX. Yes, it used to be like that some 10+ years ago, but not anymore. However I can still find this myth repeated here and there nowadays. These days Linux works out of the box, with no more tweaking or settings up than what is required for OSX.

Reply on news.ycombinator.com