Timeline of Slack’s Tech Stack Evolution | Hacker News Reader

Timeline of Slack’s Tech Stack Evolution

stackshare.io

124 pointsjdorfman50 comments

It's interesting to compare Slack's tech stack vs Discord. The tech stack of slack is pretty common, while the tech stack of Discord is very geeky: Elixir/Rust + Cassandra for crazy high concurrency, and React/React Native for fast developing and consistent experience.

Like LAMP for Slack, Discord also used MongoDB prototyping in the first few years, but while they prototyping they prototype in a manner they can easily migrate to Cassandra later. Then they successfully migrated to Cassandra. This is brilliant.

I remember the React community migrated from Slack to Discord[0], I guess one of the reason could be the performance. According to the blog, at that time the team only have "14 people full time", which means they've got a very high velocity, amazing.

I didn't find any summary of their whole tech stack but there are several insightful articles from their blog like[1].

[0] https://reactjs.org/blog/2015/10/19/reactiflux-is-moving-to-...

[1] https://blog.discordapp.com/how-discord-stores-billions-of-m...

How many more users/how much more traffic does Slack have than Discord...?

Probably the hard part is not about overall traffic. If Slack have a billion channels, while every channel only has 10 to 1k users, it's much easier than say, if Discord having a million channels while some channel having 100k users. If you thinking in algorithmic complexity.

I'm pretty sure the Reactiflux channel exceeded 50k long time ago.

We've done a few purges of inactive users over time, so the number of "total members" has done the usual garbage-collection sawtooth graph shape.

Looking at the server right this second, I see 2800 online, and 72.5K total members.

Slack uses Elixir for their auto and video conferencing as well.

I'm an admin on Reactiflux (although at the time of the switch from Slack to Discord, I had just joined as a newbie).

We got kicked off Slack because we got up towards 10K users signed up, and Slack locked us from having any more people join. Clearly, we weren't a good fit for their business model. Worked out well for us - we've loved Discord ever since we switched over!

This is So cool! Reatiflux is one of the most energetic community I have ever seen.

Every time I use Slack I found the business model is not as generous as Elixir - there are too many constraints for free users/organizations.

Hello HN! We’re really excited to share this with you all. If we’ve missed any key details, or if you’d like to add a new event to the timeline, email stackhistory@stackshare.io and we will update it asap. Have a great weekend!

Hi! We didn't do a great job writing about this at the time, but Slack's migration into HHVM took place in 2016. We've been gradually increasing the coverage of Hacklang (Facebook's gradually typed descendant of PHP) since then, and are now 100% Hacklang.

I know that the HHVM team at facebook is implementing a pretty aggressive strategy to updating the language with regard to deprecating language features, how is this affecting you guys? How often are you guys updating to the latest version of hacklang/HHVM?

Would love to know why you guys think it's a good idea to have a login modal take over the screen out of nowhere after scrolling about 1/3 down the page. So user-hostile ️

That’s stackshare, not slack. But yeah, it’s impossible to read the article because of that.

jdorfman works at StackShare.

I’ve always admired Slack’s pragmatic choice for LAMP, despite the amount of slack it gets (pun intended). Despite its reputation, it still has an amazing community, ecosystem, and tooling to get shit done.

I’m currently working with Flask/Postgres and it’s simply lacking when you need to scale it (in terms of performance/team size/code size) and there’s not great tooling to take it to the next level. Can’t wait to get back to Laravel on my next project.

I admit, it really makes you think about iterations and MVP in a new way.

I am surprised you said you found flask lacking though, because I would have thought they were similar. Can you say more about what you found to be lacking in terms of performance/team, size/code and tooling?

Flask is a micro-framework, it's an explicit goal to not have that kind of tooling included: http://flask.pocoo.org/docs/1.0/foreword/#what-does-micro-me...

There are lots of Flask extensions and other methods to extend it (relevant docs page: http://flask.pocoo.org/docs/1.0/becomingbig/), but it's a framework that practically defines itself around the fact that it doesn't include anything. Pyramid or Django might have been better options.

What's the problem with Flask and PostgreSQL?...

I wonder if they'll consider building the Mac app off of the iOS codebase with Catalyst instead of using the web codebase with Electron.

RAM and battery abuse are the main complaints about their app and I'd think that would improve both of them.

Windows is big but I think it's worth it since they already have a team maintaining the Electron app and team managing the iOS app. They need to hire a few iOS engineers to prototype this idea and evaluate if it's something they can go with. I would defiantly appreciate a native app on my Mac.

What's interesting is that Slack (the company) was founded in 2009 and yet the initial release of Slack was in 2013. That's 4 years of development, that seems like quite a long time.

Well it says it was initially an internal tool for a different startup.

Slack: They first built a game, it didn't do well, so they pivoted to focus on the message system they built for the game.

Flickr: They first built a game, it didn't do well, so they pivoted to focus on the image hosting they built for the game.

Games are hard.

Aren't there other companies that started out as games companies? I mean, it seems obvious, but Discord started out from the wreckage of a videogame company: https://en.wikipedia.org/wiki/Discord_(software)

I was sure there were more examples, though.

Games are hard.

Games require all of the latest technology and require maximum compatibility across all platforms.

Yeah, absolutely. Butterfield was both Slack and Flickr.

Next time Stewart Butterfield co-founds a games company, it'll be one to watch out for.

Slack started out as an internal chat tool by Flickr co-founder Stewart Butterfield's Tiny Speck, which was trying to launch the game Glitch. When Glitch failed, they spun out Slack as a new company (or they renamed the company, not sure).

This is almost the exact thing that happened with Butterfield's first venture, Flickr, which was built on a web platform they wrote for a multiplayer online game called Game Neverending (which is why Flickr URLs have/had "gne" in their URLs).

Poor fellow. Maybe third time's the charm and he'll finally see some success.

Poor fellow indeed.

This is really interesting.

I would love to see something like this for other successful companies.

Too often, we see the tech stacks of famous firms, but not the stacks that preceded them.

It would be very interesting to note if, say, 80% of unicorns started their life as RoR, or PHP projects. It tells you one of two things:

1. Which frameworks were popular n years ago (where n is the average time it takes from launch to unicorn)

2. Which framework actually helps you get an MVP off the ground

Is Hack/HHVM really being used much anymore? I was under the impression PHP7 pretty much reduced the advantages (types, speed).

Well, it's being used by Facebook and Slack at least...

Hack still has a lot of features that is missing from PHP7. Proper data structures (vector, map, set, etc...) including immutable ones, generics, variance, async/awaitable, etc... there is still a heck of a lot for PHP to catch up on.

Considering how experienced Slack appeared to be with Elasticsearch by 2017, why did they choose Solr for search?

They talked about it at a recent Solr conference Activate: https://www.youtube.com/watch?v=EQ336PTZfhU (Rebuilding Message Search at Slack - Josh Wills & John Gallagher, Slack )

The left out the release that had 3 distinct jQuery versions bundled in the app.

The Slack client is a terrible memory hog in my experience. I can't believe they need to use Electron instead of the platform native FWs.

I hope they port their iOS app to Mac with Catalyst. It might solve the issue at least for the Mac users.

Any more details on your voice and video calling infrastructure? Looks like there is one throwaway line that it was built in elixir.

I'm curious if Slack ever considered using XMPP in their stack for core chat? As an outsider, it seems XMPP would fit like a glove (even signing in to a work "domain" screams XMPP).

What would be the advantages now that they already have the product built?

I'm simply curious if the protocol was ever brought up in discussion and if there was a conscious decision to not go that route due to product needs.

I'm not going to speculate on what the advantages/disadvantages would have been as I honestly have no idea. I suppose if a competing product comes out that is XMPP-based then maybe we'll have some good comparisons. ;-)

Interesting read.

I'd always incorrectly assumed they'd started off with a modified IRC stack of sorts & am pleasantly surprised that it isn't the case.

One this is for sure, they are all in on AWS.

Something that differentiates Slack from other apps, is that there should never be any need to manage data across corporate clusters.

Instead of a massive, complicated back-end, imagine if each Slack 'installation' (i.e. customer) had their own set of services, distinct from one another.

Even with 10K users each for the larger customer accounts, I'd imagine that 'customer backend' might not have be super complicated.

i.e. I wonder if there's an opportunity for systems such as these to 'scale horizontally' instead of vertically, whereby each customer has their own little set of services.

In this manner 'managing billions of messages' wouldn't seem so daunting, rather, no more daunting that some 3rd party running several thousand MS Outlook instances, one for each customer.

We decided early on to colocate most aspects of the back-end, in part because we anticipated shared channels[1], but also because provisioning even virtual hardware for each team would be prohibitively expensive: we have over 600,000 organizations in Slack today[2], too many to make hard-partitioning most resources economical.

[1] https://www.zdnet.com/article/slack-brings-shared-channels-t... [2] https://sec.report/Document/0001628280-19-004786/

I remember reading Evernote had a simple MySQL DB for every account, kind of a similar approach.

Let me know when they figure out how to build a Windows client that doesn't run an entire CPU core at 100% all day long.

Nice downvote. Every single person I know who uses the Slack Windows client has this issue. How about you differ with me if I'm wrong.

Edit: here's a link to others with the same issue: https://www.reddit.com/r/Slack/comments/bj3ltt/windows_users...

I find it weird that slack has this unintuitive way of signing into my workspaces, that user experience made me stay away as much as possible. I don't know why they don't make it easy to stay, harder to leave!

Reply on news.ycombinator.com