Seems to be this article is about when your product is bleeding-edge tech, but people are commenting as if it were about building your product using bleeding-edge tech (in-house or otherwise).
Definitely only do one of these at a time, tho :)
Definitely only do one of these at a time, tho :)
I think Discord is one good example of this sort of trade-off. Single, pretty standard type of app that improves on its predecessors, with some bleeding-edge engineering: https://blog.discord.com/why-discord-is-switching-from-go-to...
>Discord has never been afraid of embracing new technologies that look promising. For example, we were early adopters of Elixir, React, React Native, and Scylla. If a piece of technology is promising and gives us an advantage, we do not mind dealing with the inherent difficulties and instability of the bleeding edge. This is one of the ways we’ve quickly reached 250+ million users with less than 50 engineers.
>Embracing the new async features in Rust nightly is another example of our willingness to embrace new, promising technology. As an engineering team, we decided it was worth using nightly Rust and we committed to running on nightly until async was fully supported on stable. Together we dealt with any problems that arose and at this point Rust stable supports asynchronous Rust. The bet paid off.
(They also mention how they're careful to replace decoupled components incrementally, and only where it addresses a real need, rather than for the fun of it.)
I wonder if not speeding is enough to give police officers a reason to make a drugs search in some places.
Czech here, I was stopped by the police once in the night on an empty 4-lane road doing exactly the speed limit. They breathalyzed me, looked at the zero and one of them said: "you know, when someone keeps the limit at midnight on this stretch of the road, they are usually drunk".
* It's users were consequently having to use multiple platforms, with teamspeak or vent or mumble for voice chat and Skype or Facebook for persistent text chat. This was inconvenient adding everyone twice.
* It's hard to explain how much it helped for the "bringing a random into your gaming group" scenario. You could just drop a link into the games text chat and people could join for the night and you didn't have to worry about if they had teamspeak or mumble or whatever installed.
* Teamspeak's free tier had a limit of like 10 users known to the server. Discord did not.
* Slack wasn't a competitor for Discord's initial market. Having to sign up for each instance was a deal-breaker. Discord originally allowed guest accounts, and I think it still does. Also the overhead to creating/managing a new server and adding people is really low comparatively.
* Discord doesn't really compete with Twitch much? People stream to their friends sure, and I have known people who had unlisted twitch channels for like jackbox in the past but that's a relatively late addition, and twitch is much more interested in the big streamers than the long tail anyway.
Obviously discord have significantly expanded their market a few times from FFXIV raiders to all mmo players to all gamers to everyone, but they started with clear problems to fix and fixed them well
It's interesting how they started out focused on gaming and have since moved away from it. I discovered a new Discord competitor, Guilded.gg, that sprouted up with marketing claiming Discord has abandoned gamers and they're going to recapture them.
It just goes to show that you never know which direction it's going to truly move and you have to be able to pivot. But having a core initial user group that you solve a problem for is key, and having a working product is key as well.
All of the comments for some reason are about not using latest-nosql-db-from-producthunt in prod.