Disclaimer: I'm developing a chat app/serivce as well, but it's not a Slack/Teams competitor.
I personally would love to see real alternatives to Slack and Teams.
Discord has Stoat (formerly "Revolt") and a newer app called "Root" but both of those have a long way to go to replace Discord.
Maybe I am atypical, but to me the biggest problem with Slack is not the 90-day retention (because I would assume any paid version should include message retention), but rather the per-user pricing.
Given your current pricing (at least what you show right now), it seems like your team-based pricing model is a much better selling point for your service over something like Slack or Teams which use per-user pricing, assuming you offer most of the features that typical Slack/Teams clients need.
The only issue I see with pricing is your free tier might ultimately undermine your revenue since the only differences between it and the first paid tier are 15 more users and priority support (which most people should never need).
This is actually a smart and common sense move by Apple.
The non-hardware AI industry is currently in an R&D race to establish and maintain marketshare, but with Apple's existing iPhone, iPad and Mac ecosystem they already have a market share they control so they can wait until the AI market stabilizes before investing heavily in their own solutions.
For now, Apple can partner with solid AI providers to provide AI services and benefits to their customers in the short term and then later on they can acquire established AI companies to jumpstart their own AI platform once AI technology reaches more long term consistency and standardization.
I think a fundamental mistake I see many developers make is they use caching trying to solve problems rather than improve efficiency.
It's the equivalent of adding more RAM to fix poor memory management or adding more CPUs/servers to compensate for resource heavy and slow requests and complex queries.
If your application requires caching to function effectively then you have a core issue that needs to be resolved, and if you don't address that issue then caching will become the problem eventually as your application grows more complex and active.
Idk I think caching is a crucial part of many well-designed systems. There’s a lot of very cache-able data out there. If invalidating events are well defined or the data is fine being stale (week/month level dashboards, for example), that’s a fantastic reason to use a cache. I’d much rather just stuff those values in a cache than figure out any other more complicated solution.
I also just think it’s a necessary evil of big systems. Sometimes you need derived data. You can even think about databases as a kind of cache: the “real” data is the stream of every event that ever updated data in the database! (Yes this stretching the meaning of cache lol)
However I agree that caching is often an easy bandaid for a bad architecture.
Caching is definitely a useful and even a key component to producing efficent and high performance applications and services.
I think the mistake is not using caching, but rather using it too soon in the development process.
There are times when caching is a requirement because there is simply no way to provide efficient performance without it, but I think too many times developers jump straight to caching without thinking because it solves potential problems for them before they happen.
The real problem comes later though at scale when caching can no long compensate for the development inefficiencies.
Now the developers have to start rewriting core code which will take time to thoroughly complete and test and/or the engineers have to figure out a way to throw more resources at the problem.
There are a lot of things necessary to be a successful human but doing them without doing the fundamentals just makes you a monkey in a suit.
Caching belongs at the end of a long development arc. And it will be the end whether you want it too or not. Adding caching is the beginning of the end of large architectural improvements, because caches jam up the analysis and testing infrastructure. Everything about improving or adding features to the code slows down, eventually to a crawl.
> It's the equivalent of adding more RAM to fix poor memory management
No it’s ten times worse than that. Adding RAM doesn’t make the task of fixing the memory management problems intrinsically harder. It just makes the problem bigger when you do fix it.
Adding caching to your app makes all of the tools used for detecting and categorizing performance issues much harder to use. We already have too many developers and “engineers” who balk at learning more than the basics of using these tools. Caching is like stirring up sediment in a submarine cave. Now only the most disciplined can still function and often just barely.
When you don’t have caches, data has to flow along the call tree. So if you need a user’s data in three places, that data either flows to those three or you have to look it up three times, which can introduce concurrency issues if the user metadata changes in the middle of a request. But because it’s inefficient there is clear incentive to fix the data propagation issues. Fixing those issues will make testing easier because now the data is passed in instead of having to mock the lookup code.
Then you introduce caching. Now the incentive is mostly gone, since you will only improve cold start performance. And now there is a perverse incentive to never propagate the data again. You start moving backward. Soon there are eight places in the code that use that data, because looking it up was “free” and they are all detached from each other. And now you can’t even turn off the cache, and cache traffic doesn’t tell you what your costs are.
And because the lookup is “free” the user lookup code disappears from your perf data and flame graphs. Only a madman like me will still tackle such a mess, and even I have difficulty finding the motivation.
For these reasons I say with great confidence and no small authority: adding caching to your app is the last major performance improvement most teams will ever see. So if you reach for it prematurely, you’re stuck with what you’ve got. Now a more astute competitor can deliver a faster, cheaper, or both product that eats your lunch and your team will swear there is nothing they can do about it because the app is already as fast as they can make it, and here are the statistics that “prove” it.
Friends don’t let friends put caches on immature apps.
I’d say a useful way of thinking about caching is through the lens of the CAP theorem. You are facing a situation where compute requirements exceed the bounds of a single process. There are a variety of things you can do here, all with consequences to the Consistency aspect of your data. Two strategies with consequences are caching and horizontal scaling. So look to vertical scaling or efficiencies in data modeling first.
I like your comment btw. I’d add Observability to CAP to incorporate what you’re saying.
> If your application requires caching to function effectively then you have a core issue that needs to be resolved, and if you don't address that issue then caching will become the problem eventually as your application grows more complex and active.
I don’t think this is always true. Sometimes your app simply has data that takes a lot of computation to generate but doesn’t need to be generated often. Any way you solve this is going to be able to be described as a ‘cache’ even if you are just storing calculations in your main database. That doesn’t mean your application has a fundamental design flaw, it could mean your use case has a fundamental cache requirement.
If your database is slow because it's on spinning disks, then a cache will speed up access.
That's not a fundamental mistake, and there's very little you can do about that from an efficiency point of view.
It's easy to forget that there was a world without SSDs, high speed pipes, etc - but it actually did exist. And that wasn't so long ago either.
And of course sometimes putting data nearer to the user actually makes sense...like the Netflix movie boxes inside various POPs or CDNs. Bandwidth and latency are actual factors for many applications.
That said, most applications probably should investigate adding indexes to their databases (or noSQL databases) instead of adding a cache layer.
Not to mention latency! Caching does nothing to fix the latency of “misses”, which means any app that uses a caching layer to paper over a bad design will forever have a terrible P99 (or even P90) latency.
“But, but, when I reload the page now it’s fast! I fixed it!”
I remember playing Ultima Online and really enjoying that game when I heard about a new first-person MMORPG in development called EverQuest.
I ran a couple of popular game sites back then and had industry connections so I got early beta test access to try out EverQuest.
Unfortunately, I made a bad choice when I chose to make a Human character, which was night-blind. On top of that, it seemed like every time I logged in it was night time and the game was nearly unplayable away from lights, fires and torches for that character.
To make matters worse, I started in Freeport which had several invisible zone walls so on top of not being able to see, I constantly kept zoning which constantly interrupted the game.
As you can imagine, I lost interest rather quickly and went back to UO. I gave my beta account to a gamer friend of mine, who had a much better experience than I had during beta.
When EverQuest eventually launched, several friends of mine bought it so I decided to buy it as well. By then I had learned to make elven characters because they had infravision/ultravision that allowed them to see at night.
It was fun for a little while, but then bad game design concepts led to another problem. They arbitrarily decided to assign some of the classes with experience penalties, including the one I played which had a 40% experience reduction, which was ridiculous.
The problem was that at that time, that information was not well known so I all I noticed was all of my friends were outleveling me because none of their classes had penalties.
Eventually by around level 12 (which took a while back then), I was too low to group with them, despite playing the same amount of time they did, and I could no longer gain experience in their groups.
Since EverQuest was heavily group-focused, I decided to go back to Ultimate Online.
A few months later, I decided to give it another try and made a bard. Suddenly, everyone was inviting me to group and that made the game a lot more fun and led to a lot of great memories.
A few years ago I tried to go back and play it but, either due to age or having less free time, it was just too slow and difficult to play after all of these years.
While I don't play it any more, I am really glad that it is still online and even if it shuts down, there is another player-run (and licensed) rogue server available.
I met so many good friends in that game, including one of my best friends to this day, so I will always have fond memories of it.
You can also combine searches ..
@theverge.com elon musk twitter
There are no user accounts on WhatSubject, but there are several settings you can change including the site theme and search result layout format.
You can also take advantage of several content filters including blocking known right-biased sources and/or left-biased sources, political content and paywalled sites.
Your latest searches are shown on the home page as the first entries in the tag cloud followed by other recent popular searches.
You can disable or delete your search history (it is stored using cookies) as well as delete all cookies.
Also, rather than !bangs, I added quick search buttons for other news and search engine sites to the bottom of search result pages.
I built WhatSubject because I wanted a way to find and read site content quickly by topics and sites using a clutter-free interface.
That is an area that I need to improve. With a high focus on privacy, it makes it hard to track what users read without creating a user tracking system and that is something I really want to avoid doing.
The thread links use the CSS :visited selector to show the links in a different color to help identify the links you have previously clicked without the site knowing that information itself.
There is a history function for logged in members, but for user privacy it can be limited or disabled by the user via the Settings page and is also auto-purged periodically.
At the very least the site needs to show content that has been added since your last visit and that is something I plan to implement soon.
The problem is not really the methodology or implementation but the perception caused by it. If you can tell a user "we know you read this" then that implies you are tracking what they read which is something I try to avoid.
I plan to work on a solution, but if I do, users will be able to opt-in or opt-out depending on the implementation.
I really try to avoid using local storage because it delves into potential user privacy issues. I will look more into it as well as other options as I know having a list of already viewed results would be helpful for users.
I personally would love to see real alternatives to Slack and Teams.
Discord has Stoat (formerly "Revolt") and a newer app called "Root" but both of those have a long way to go to replace Discord.
Maybe I am atypical, but to me the biggest problem with Slack is not the 90-day retention (because I would assume any paid version should include message retention), but rather the per-user pricing.
Given your current pricing (at least what you show right now), it seems like your team-based pricing model is a much better selling point for your service over something like Slack or Teams which use per-user pricing, assuming you offer most of the features that typical Slack/Teams clients need.
The only issue I see with pricing is your free tier might ultimately undermine your revenue since the only differences between it and the first paid tier are 15 more users and priority support (which most people should never need).
reply