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

IRC is used by many projects small and big and I've used it in a few companies as well, it's not like it's an absurd concept.

I don't know if Slack is better or worse (I've never used it, I thought the title was talking about Slackware linux which seemed odd) but you draw a much bleaker portrait of IRC than what I experience day to day using it extensively.

Now if you want to talk about mailing lists I might side with you...



> but you draw a much bleaker portrait of IRC

I'm being brutally real. IRC is a brittle, aged, poorly designed protocol even by the standards of 1988 academia. You could design a more robust centralized service just by using off the shelf components today.

Seriously. Use off the shelf Google Container Engine stuff along with some modest websocket work and even relative neophyte will end up with a more robust service with better scaling characteristics.

Really, that's why stuff like Slack and Hipchat exist. Becuase it's not really all that hard to do a much better implementation than what IRC can feasibly do.


No, the point was that your description was entirely inaccurate. It's not brutally real because I also use IRC extensively every day on freenode and have almost never encountered the issues you are referring to. I think I've seen one netsplit in the last 2 years.


Okay, well I am sorry your experience and mine differ. Fortunately you can continue to use your solution without regard to my criticism.

But I think if we asked your IRC network how ma you nets plots they experienced in the last 2 years the number would be >1.


Ah, yes, IRC has netsplits. Slack, on the other hand, has "reconnecting...", which I encounter a dozen times a day on it.

I guess it's down to personal preference whether you prefer being able to talk with a partial group knowing that some people are absent, and not being able to communicate at all.


Reconnecting in slack then shows you the missed messages. What's the common case for making sure participants have access to all past messages in IRC? An external log, which doesn't really solve the netsplit problem, because it necessarily is part of the split?

I would much prefer clear indication that there is a problem communicating with others so I can fall back to an alternative method of communication.


What people here aren't getting is that IRC and a listserv aren't still used because they have the most features or are the most brilliantly designed pieces of software for the job, it's the best because it's a standard.

I have IRSSI always running in a remote screen session. I read many mailing lists. It's not just my personal preference, it's part of my workflow. When I hit a problem, my immediate reaction after consulting the docs or google is to ask a question on a relevant IRC channel or hit up a mailing list. I don't think I'm the only one that works like this, either.

So asking me to use hipsterchat or slack or gitter or trello or whatever means another another client, and not one that's going to replace my other client, but in addition to it. That's not good. If it had some amazing features other than emoji and fluff, I'd be open to it. But they really don't. People get work done with IRC and a listserv, and that's all that matters.

Let's be honest, Trello and Slack have taken off because young developers aren't familiar with this system and are taking to a new one. And maybe in a few years they will become the norm and my argument will no longer be valid because my workflow will change.

But until that point comes, I agree wholeheartedly that it's a bad choice for FOSS communities, on top of the fact that these are paid services and you're locked out of control of your communications if they decide it's better for their bottom line. That alone seems antithetical to the idea of free software.


> Let's be honest, Trello and Slack have taken off because young developers aren't familiar with this system and are taking to a new one. And maybe in a few years they will become the norm and my argument will no longer be valid because my workflow will change.

I completely disagree with you. My entire team is ~30 or older, and we all used IRC "back in the day". Slack is simply better for communicating with your team because of all the features mentioned elsewhere in this thread.

To suggest ignorance is the only reason Slack and HipChat have taken off is offensive to the people using it because they like it better.

I still use IRC for open source projects I use or contribute to. For the record, I agree with the article insofar as that OSS projects should probably continue to use IRC rather than Slack despite the persistence and team based features. Purely because it's unfair to expect all of your users and contributors to use yet another system for communication that isn't relatively open.


Slack is basically IRC with "subjectively nicer" design and helpful integrations, e.g. your builds, deployment, compilation progress can show up on separate channels, you can see if somebody mentioned you on twitter etc. You get the idea. Principally it's just extended IRC, maybe they even use slightly modified IRC protocol underneath for anything chat-wise.


Slack's benefits over IRC are largely not subjective:

* The ability to directly send files and images to channels is an objective benefit Slack has over IRC, which has even less ability to do that than MIME email (at least MIME lets you post the base64'd file contents of your image, rather than just a clickable link).

* The ability to send long messages or whole source files is an objective benefit Slack has over IRC.

* The ability to, by default and without running a secondary service that can crash or lose connectivity, log and search channels is an objective Benefit Slack has over IRC, which can support that feature only by using bots, and only by tunneling results through privmsgs or forcing users to leave the IRC protocol itself and visit ancillary web sites.

* The ability to edit and delete messages is an objective benefit Slack has over IRC.

There's probably a bunch more. Don't get me wrong: I don't think Slack is amazing; it's good for what it is, but in 2015 it's pretty unremarkable. The issue is that IRC is so. bad.

There are probably still people making fun of poseurs and hipsters who use IRC instead of ICB. The OpenBSD team used to be like that.


You've been able to directly send files over DCC via IRC clients since like 1995.

Interpreting and displaying those DCC'ed files or cutting longer messages into sub messages and recombining them is something that you could implement via the IRC client just as easily as it was implemented in Slack (not to say that it would be easy, it'd be a lot of work, but it likely would not be much more work than what took to make that function in slack).

If you're modifying IRC anyway, you can modify the server to record logs and make those available to clients.

Same goes for editing.

IRC is not as bad as you think it is, and it wouldn't be an insurmountable effort to make it as good as slack, but open sourced rather than proprietary, which was the entire point of the original article.


No. In Slack, files and images posted to channels are content associated with the channel, not a private and opaque stream of bytes tunneled over another protocol between two specific channel members. The comparison between Slack and DCC is silly.

Given the problem of sharing a diagram with a team of developers on a group message channel, I'm sure there's someone here who would say they prefer the DCC option of receiving a named file and then opening it with a file viewer, rather than simply dragging the file into the chat window and having it appear instantly to everyone on the channel. The existence of that person is not interesting to me.


icb4lyfe


yeah, can you script tcl into slack?




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

Search: