You asked: Slack is kinda like IRC, no?

Slack is definitely not not like IRC:

It intrigued me to observe that early Slack features, such as #channel and /command, bear a resemblance to functionalities found in IRC. This observation prompts a curiosity regarding the Slack founding team's perspective on IRC, specifically how they differentiated their vision to accommodate general users beyond the technical limitations or user experience barriers associated with IRC.

Sincerely, Boyan

The company that became Slack was geographically distributed from the outset. During its video game era there was a game studio in Vancouver, engineering in San Francisco, a cofounder in New York, music in Toronto, and customer support just about everywhere. When you can't work together in an office, you have to do all of your work together over the internet somehow. The founding team had been on the internet for quite a while and was fully aware that email sucks for running a company. They decided that this company would be run on IRC instead. irc.tinyspeck.com, an internal server, was the nerve center of the company for its first three+ years.

IRC is great except for all the ways in which it isn't. Messages sent while you were offline were messages you'd never see; there were file sharing mechanisms, kinda, except they were hard to use and you could only share files via DM with one other person; search was nonexistent; native notifications didn't exist; and users had to maintain a mental catalog of slash commands and how to use them to do anything beyond chatting. But, it got the job done. IRC was user friendly but very picky about who those friends were. (See also: Linux. It turns out that MacOS is the Year Of Linux On The Desktop that we wanted all along.)

The team built a suite of services that bolted onto our IRC server to solve some of these shortcomings. Messages were stored in a database and were browsable via a web interface, and if memory serves, MySQL FULLTEXT was used to provide rudimentary search. (We expect an email from Cal in a few hours if this is incorrect.) There was a webpage to upload files and share links to those files in a channel, backed by an S3 file server to store them. A separate pastebin site was spun up for sharing server logs. There were several IRC clients available for the desktop and mobile that solved some of the usability shortcomings for those who weren't familiar with slash commands, and employees picked whichever one was their favorite.

When it came time to build Slack, we wanted to capture the best parts of IRC in the context of running a business, add all of those ancillary services as native features, and vastly expand the group of people with whom our product could be friends. From a technical perspective, Slack has zero elements of IRC — it's an entirely separate and custom-built codebase. From a functionality perspective, we retained two main concepts: channels and slash commands.

Channels are why IRC worked in a business context. There was never a question about whether they'd be part of Slack: they were, in fact, going to be the cornerstone of Slack. We'd all seen plenty of non-technical people grasp the channel concept in IRC over the years, and the # prefix seemed to work well enough to visually and conceptually set them apart as a special element of the system. We were about three years into the social media hashtag era at the time, so we knew that people would generally understand the idea of topic grouping using that symbol.

Slash commands were the way that we used IRC, but we didn't want everyone to have to learn them in order to use Slack, so we included them for people like us but built UI to do everything that slash commands did. For example, you can still join a channel with /join #channel-name, but most people just click on a channel name to join it. On the back end, these are indistinguishable: they both call the same API endpoint to get you to the same end result.

We did, however, want to extend the slash command affordance to developers using our platform, and boy was it popular. Developers love building slash command integrations. If you find yourself using slash commands in Slack to do something, it's likely that you're using something that Slack itself didn't build. The most notable exception here is /giphy; we built that integration in partnership with Giphy and never fully integrated it with native UI controls beyond the custom shuffle/send affordance. (There is finally a full UI interface for sending GIFs, though, added just last month.)

There you have it! The tl;dr: channels are foundational, slash commands are optional but extensible.