At one point in the past Slack was new and shiny. It had much less features, but every one of them were crafted with UX in mind. People were raving about it, because for many it was the first time they could use something that had the nice properties of IRC chatrooms, in a nicely polished package, and it was usable in a work setting. It brought some fun back into the workplace where you previously had boring email inboxes.
I don't know exactly what changed. Maybe with feature bloat, the same care for UX was lost. Maybe the competition caught up and it doesn't stick out as that special anymore.
Exactly. Slack's biggest benefit was "chat with persistent history, the ability to message offline people, and notifications". That's table stakes now.
Also the free model is _very_ generous.
The only features they work on are the next-gen features while the more comprehensible login flow wouldn’t get you a promotion.
a) People who hate Slack
b) People who hate open-plan offices
c) People who can't imagine why anyone would ever have a different opinion than them on such topics
How do you know? Most people I know, uses Slack because that's the company policy, not because they find Slack the best option. But I don't think that's the majority of people, because is just my biased view, but probably it's the same in your case.
Even then it felt pretty dated, but the infrastructure team that ran it thought it was good enough so we kept it. Hipchat was a thing that was clearly better, I remember talk about it and I think some people pushed to switch to it, but it seemed like a daunting task and not all that important so it never happened.
Then not too long after that, Slack had come out and one day I just happened to notice that the frontend team was chatting on a new app. I'm sure there were some frustrated conversations between them and the security team, we were big enough that we had a couple person security team and had some rules about only using approved software, but I guess not big enough that there were going to be any strict repercussions for breaking those rules. And that was that, a few more teams started using it, and at some point enough teams had it that we just officially switched.
Between search and multi-client use it was clearly better than our corporate chat. The design made it more enjoyable to use. But the real killer feature was the low barrier to entry, I think it snuck into a lot of organizations in exactly this way by having a generous free plan and a web client so that anyone could just start using it without asking permission.
Slack got that right. It’s not perfect, but it was a major upgrade.
I'm not sure how well it is implemented in the backend, but if it is safely separated in the database while having the current UX it's actually really well designed.
A "clean" multi tenant login separates the user from the account, i.e. the same user has different rights depending on the account he is using.
Code snippets: Slack does not allow you to type put highlighted code snippet in a middle of a message (you must import them in a separate message).
Code Snippets: If you import code snippets using the tool, you cannot simply copy paste from it. There will be extra new lines and other noise.
Links: Slack does not allow you to put a hyperlink except verbatim.
I’m sure there are more. But slack is a pretty lousy chat client with poor support for basic needs of developers of code.
Everything you need: High speed communications. Long-form, if you need it. Only getting notified about things you care about. Written discussions about things like how design or business plan decisions were made to be perused at leasure by new hires in the future (Knowlege-base).
For a company that got going for being better than email, it's shocking to me how email (done correctly) is still better on almost every dimension (except asking what people want for lunch).
Preferences > Advanced > Format messages with markup
Drafts seems to also be universally despised, but they haven't yet done anything about it
I just can’t understand many open source project force users to use it. I can understand JavaScript and web development crowd vying to get on slack given the kind of IDE and tools, they use.
I cannot bear the slow speed with which slack works compared to IRC in terminal, emacs or VI.
A 3+ year migration of the bulk of your codebase is sort of intense. Though the Hack team at Facebook has made some great tools to ease migration, their fairly aggressive sunsetting of PHP features in Hack has presumably made this job a little harder.
Also notable: Slack is the only equivalent company (outside of Facebook) that uses Hack, at least that I know of. I wonder if that makes Slack a more likely acquisition target.
M&A guy here. Sure, this is nice, but the answer is pretty much no.
Most startups never see the effects of their bad (or good) choices because they go out of business.
Good choices too, for that matter. They tend to live until they turn into bad ones.
I'm sure there are a ton of small-ish VC-funded startups using all sorts of technologies like Hack. As far as big companies though, FB and Slack are pretty much it.
As someone who uses #1 and #3 every day, I wonder what it is like coding in the 21st century :/
> The vmkernel is a microkernel[13] with three interfaces: hardware, guest systems, and the service console (Console OS).
But we use CORBA a fair amount, kind of almost as an abstraction layer on top of QNX message passing.
Ed Catmull of Pixar calls new ideas "ugly babies." Ugly because they're covered in warts -- aspects that are easy to change, but that doubters seize on because they destroy value. For example, the script for the first Bond film, Dr. No, had an intelligent monkey for a villain. Babies because they don't have value in their current form, they need more work and iteration before they have value.
How does slack identify technologies that don't have value now, but whose problems are superficial and fixable?
That’s a highly disturbing and misguided framework if you ask me.
The point is that a baby is a being with potential - and require outside input to reach that potential.
How can this be? How could my slack client with a 30 Mbps connection have received the signal that there was a new message but also not downloaded the few bytes of text as well. Maybe it did but a MacBook pro from 2018 takes seconds to render text? AOL or MSN didn't back in the day.
The trade off between packaging a html/css website as a standalone app in it's own standalone web browser minus toolbar vs apps using native toolkits such as AOL or MSN.
I mean the system requirements for AOL Instant messenger in 2008 was 300 MHz CPU, 256 RAM, and 250MB of hd space. Compare that to Slack - they don't list the system requirements but I am sure you all know it probably demands at least 1gb of RAM and will use all of it:
https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor...
Let's face it we are reaching a new dark-age of computer programming away from static typing and caring about performance to a hellscape of ECMA script...
https://medium.com/commitlog/electron-is-cancer-b066108e6c32
Sometimes great solutions simply arrive at a bad time, or don't have proper funding, or marketing, etc. It definitely makes sense to be on the lookout and try to improve your chances of identifying the winner early on for business reasons, but that doesn't mean the winner is always the best.
Once you're as big as Slack, you might even be actively harming others by doing that - i.e. a better but less popular technology might have won in the end, had they backed it.
I am not entirely convinced that they are gone:
- Xen is essentially a modern microkernel. The most popular "microkernel" from the 1980s, Mach/BSD, evolved into Xnu/Darwin which powers macOS and iOS. L4 and other microkernels still exist.
- VLIW lives on inside GPUs as well as x86-compatible CPUs
- ORBs turned into microservices
- Neural Nets turned into Deep Learning
https://mirage.io/ https://www.redox-os.org/
Don't microkernels have a real shot at replacing containers? Maybe we can stop running the huge linux kernel for every microservice?
Ehm that's exactly how containers DON'T work. They share the kernel... (and only the kernel)
And at the same time it is a great commercial success. This last one I cannot understand.
1. The rich text editor (thankfully you can turn it off — I am very sad for non savvy users who don’t know this)
2. The UX of snippets - I paste something long into a code fence — fine its too big and you need to send it very a different mechanism — just di that please don’t ask me and make me click around - ideally you’d see the big text blob inside the code snippets and just extract those into something the reader on the other side can click - this way I can provide exposition and give the reader the option to get more details if I’ve convinced them there’s something they should look at. Present options all require me to either lose formatting of my exposition or manually copy stuff out if the message and into one or more snippets
3. Link unfurling - yes I can turn it off for me but the readers not for readers on the other side ... they are less likely to engage properly with what I write because of this crap and I can’t fix it for them ... would be great if I can turn it off for messages I send and receive ...
And people still sometimes use non-deep neural networks because depth can increase overfitting.
It's nice to see a company factoring in the evolution of technology in their product, for a change.
I went through the exact same thing (word-by-word) at my last team and we came to the same consensus.
I caught a bug in our custom made static type checker for Python and argued that all type annotations should be dropped :D but they argued that there are more benefits, mostly because it is easier to understand code in isolation so we kept it and invested in even more type-annotation throughout the whole code base.
Uh... What about Zircon[1]? It powers Google's new mobile operating system: Fuchsia[2].
