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 ️
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!
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?
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 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.
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)
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).
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.
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).
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. ;-)
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
)
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.
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.
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].
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.
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!
52 comments
[ 5.9 ms ] story [ 111 ms ] threadI’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 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?
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.
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.
I was sure there were more examples, though.
Games are hard.
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).
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. ;-)
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.
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
RAM and battery abuse are the main complaints about their app and I'd think that would improve both of them.
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.
[1] https://www.zdnet.com/article/slack-brings-shared-channels-t... [2] https://sec.report/Document/0001628280-19-004786/
Edit: here's a link to others with the same issue: https://www.reddit.com/r/Slack/comments/bj3ltt/windows_users...
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...
I'm pretty sure the Reactiflux channel exceeded 50k long time ago.
Looking at the server right this second, I see 2800 online, and 72.5K total members.
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!
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.