After I used Discord in different contexts for months now (and Slack for years), I can't understand why someone willingly chooses Slack. It's the Atlassian of chat tools. Horrible performance and bad usabillity.
Because it's the Atlassian of chat tools. It's the lowest common denominator. Discord also doesn't let you set message retention that I'm aware of which is an immediate nonstarter. End up in one lawsuit where the other party demands a fishing expedition and you'll be real happy that you've got retention limited to 90 days by policy and in practice.
A terrible, horrible, no-good, very bad day at Slack
161–170 of 282 posts
Re: A terrible, horrible, no-good, very bad day at Slack
#162The title is an allusion to a popular children’s book[1]. I’m assuming that an automated algorithm pulled the “very;” hopefully the mods will consider restoring it. [1] https://en.wikipedia.org/wiki/Alexander_and_the_Terrible,_Ho...
There's also a film based on the book. https://en.wikipedia.org/wiki/Alexander_and_the_Terrible,_Ho...
Re: A terrible, horrible, no-good, very bad day at Slack
#163Not being involved in this kind of scaled-up devops kind of stuff, my read of this article was "HAProxy sounds awful "... but they noted in the article 1) Migrating to better software, and 2) Newer versions of HAProxy are also better software. But yeah, the first half where they're discussing "we don't do X, Y, or Z clean, idempotent way of doing config because the HAProxy doesn't perform right if you do it that way.…
I don't think that's fair. HAProxy is good and reliable. It's just old for the use cases we need today. Even the article has this opinion: > While HAProxy has served us well and reliably for many years, it also has some operational sharp edges Saying it sounds awful is like saying Vanilla JS sounds awful because it doesn't scale to the demanding webapp use cases of today. And, as you mentioned, it's really compounded…
... it kinda is?
Re: A terrible, horrible, no-good, very bad day at Slack
#164Re: A terrible, horrible, no-good, very bad day at Slack
#165This is one of the biggest arguments I see for serverless (AWS Lambda + DynamoDB) or at least managed PaaS systems (Google App Engine, Heroku with RDS or CloudSQL). These systems may seem to cost more for some workload curves (or might even be cheaper for your curve), but the difference is worth it because you're paying for specialized 24/7 dev-ops teams whose only job is to keep these systems running smoothly, and b…
Replace "serverless" with "managed service" and I agree. But serverless doesn't give you any magical reliability improvement over anything else, because your NFRs dictate the implementation that will produce the most reliable product. The design of a wooden table will inform what tools will produce the best version of that table. It may not be the newest power tool; it may end up being chisels, hand planes, winding s…
Re: A terrible, horrible, no-good, very bad day at Slack
#166Earlier quoted context omitted.
You can't assume that, these costs, specifically the server less stack at AWS, scale up quite opaquely. You can put billing alerts in place, but once you tie your infrastructure to one specific serverless vendor, even if you identify a harmful cost scale, you can't easily mitigate it. I am not saying serverless is expensive, all I am advocating is extensive planning and preparing before adopting any particular server…
Lock-in is one of the worst reasons to avoid serverless. If you're really putting in the effort to avoid lock-in, you're wasting engineering time that could be better spent on your product. AWS (or GCP, or whatever cloud provider you choose) has a number of really great products that ultimately save you time and help you get to market faster and better. It doesn't matter that you're locked-in, with slightly higher th…
Again, everything must be planned beforehand. Savings could also be marginal, but it could also be significant. In big enterprises, where billing is north of a couple of millions of dollars, every percentile you can save is justifiable.
Re: A terrible, horrible, no-good, very bad day at Slack
#167Earlier quoted context omitted.
As someone who uses Discord, I can tell you it goes down too. My favorite part is looking at their status page, seeing that API response time is exceedingly high, and getting no updates from the team about whether or not they're fixing it.
I'm not saying Discord is perfect or "always up", it's just that their client UI is better structured and more responsive in most cases. I am on multiple OSS Discord servers with thousands of users, and it works just fine most of the time. I am on multiple Slack servers with just 10-20 users and it is unbearably slow.
There's no way that my company would adopt a platform so "fun" in the way Discord tries to be. Animated characters, a logo which looks like a gamepad, etc...
It sucks, because I use Slack for work and mostly Discord for personal use (mostly dev communities for different companies), and Discord is far and away a better experience. If Discord provided a "cleaned-up" offering for orgs like mine (finance), I think it would be an instant hit.
Re: A terrible, horrible, no-good, very bad day at Slack
#168Earlier quoted context omitted.
I don't think that's fair. HAProxy is good and reliable. It's just old for the use cases we need today. Even the article has this opinion: > While HAProxy has served us well and reliably for many years, it also has some operational sharp edges Saying it sounds awful is like saying Vanilla JS sounds awful because it doesn't scale to the demanding webapp use cases of today. And, as you mentioned, it's really compounded…
> Vanilla JS sounds awful ... it kinda is?
Re: A terrible, horrible, no-good, very bad day at Slack
#169After I used Discord in different contexts for months now (and Slack for years), I can't understand why someone willingly chooses Slack. It's the Atlassian of chat tools. Horrible performance and bad usabillity.
Threaded comments. I tried using Discord with a group of 4 people for real job and we missed threaded comments. Also the ability to draw on screen while screen sharing. So simple yet so useful.
The central value proposition is its reimagined UI, making threaded replies more visible and more interactive by separating conversation topics (threads) into different columns.
It’s currently just an MVP, but I expect to at least improve the UI and maybe rearchitect the system in the near future.
Any feedback is greatly appreciated!
Re: A terrible, horrible, no-good, very bad day at Slack
#170Earlier quoted context omitted.
Threaded comments. I tried using Discord with a group of 4 people for real job and we missed threaded comments. Also the ability to draw on screen while screen sharing. So simple yet so useful.
Interesting. I personally didn't like threads and this is the first time someone mentions them favorably.