In comparison everything else puts reasonable effort into the mobile clients and phones in the rest with bloated, half-baked web apps or if you're lucky an iOS Catalyst port.

Along with UI/UX quality, this stuff matters and impacts adoption, even if most users can't put their reasoning into words.

Easy: Be at the right spot in the right time and be lucky to be noticed.

WhatsApp had one smart idea: tying accounts to phone number, which solved detectability, while SMS where expensive in many regions. When ICQ/AIM still missed the mobile market and before Apple made iMessage.

Easy to replicate, as we can see with Facebook messenger or Google's different attempts, who invested quite a few resources into that.

I was at WhatsApp from 2014 - 2019. Growing a large userbase from scratch doesn't happen by any one factor. You have to do a lot of things well. (and probably get lucky)

a) potential users need a compelling reason to join. Messaging at data rates was significant, but not in the US were many people had large messaging allowances. Works better than SMS/MMS was compelling for some.

b) existing users need to be satisfied enough to stay: service has to work consistently, client has to work, etc.

c) signup flow needs to work well. Doesn't matter if people want to use the app if they can't. You need to help users understand their phone number (or other identification). You need multiple methods of verification, because SMS doesn't always work. Giving someone a several digit code over the phone is a cognitive task for the user, and it's harder with disjointed speech generation, so you need to spend some time on that too. You need multiple providers because if you can't get verification codes to users, some of those people will give up and never come back. Since you have multiple providers, you need to figure out how to pick one based on current conditions which you also need to figure out how to track. Also --- you need some money, sending all these codes gets expensive. Phone numbers as ids is a blessing because "everyone has one" and you can use the system address book for contacts, but verification costs add up; usernames or email as id make contact discovery messy and a surprising amount of people in the developing world don't have an email address or don't know what it is.

d) users get new phones, a lot, you need to make it easy to move their account. Or they will likely drop your service when they get a new phone.

e) you need to be prepared for and handle large events. If some big news happens, people will want to talk about it. If some similar service has an outage, you will get more traffic --- if you also fall over, that's a lost opportunity.

f) things need to work well on the devices people actually have. Which might not be the ones you would prefer to use. Worldwide, most people don't have flagship phones. If you want a large number of users, having good experiences only on recent flagships is self limiting. Working well (or at least better than alternatives) on low end and older devices is a path towards addressing users that others miss.

There's probably more. Most of these require sustained consistent effort to deliver. It's not a one time thing. And it's not quick. Sustained consistent effort is easy enough as a one product start-up, but it's very hard as a big-corp.

Userbase can be a positive feedback loop: once you have enough users, that becomes its own reason to join ... and having no one to talk to is a reason to leave. There's not really a way to jump start it, unless you've already got a large user base somewhere else that you can use to seed your service.

Either you provide message interchange with any other message system operating in a specific country or you can't advertise or sell anything in this country (also app stores must country wide ban). Bootstrap by taking two largest chats and offering them provisional access to the market for few months. If they can provide interchange between them they can remain and others can follow. If not bigest one is out, let's say for two years and the third one (pre-ban) tries to establish interchange with the remaining of the two biggest.

Both look ass at desktop too, way too many wasted space, tho Telegram at least doesn't stretch the chat on the entire width of monitor when in fullscreen, having to go from far left to far right just to read the chat

Hard no. Have you tried activating encryption in personal chats?

https://i.imgur.com/YDaP5EH.gif

1. Child components can magically refer to variables in their parents. This is basic encapsulation 101. The only other language I know of that allows that is SystemVerilog and that's from an era where people didn't know better (especially hardware guys).

2. You can create custom widgets... but they can't display text! There's a class called something like QmlSceneGraphTextNode that is the way that all the provided widgets display text but it's private. I guess they might have fixed this eventually but it stayed private for the ~5 years I tried to use it. They wanted me to just use Label widgets in QML land which sucks.

It also felt like there was a pretty huge impedance mismatch between QML and C++ due to its use of Javascript. E.g. stuff like using 64-bit integers. That reminds me:

3. It uses Javascript.

4. I never found a good way to use dialogs. They seem to push you towards having all possible dialogs exist all the time and just showing and hiding them, which is kind of crazy.

I don't think the idea of a GUI DSL is fundamentally bad, but QML is certainly a pretty miserable implementation. Hopefully the Slint guys have learned all of these lessons.

Also, the comment claims that QML is not Qt. QML was added to Qt in 2009 and has been where a large proportion of the developer's focus has been ever since. It is absolutely Qt and you can't claim otherwise.

A bit of a passionate response to a passionate parent comment.

Edit: Oh, my bad. I thought they open sourced it separate from Zed. Looks like they are still tied together.

Until having language specific features really lost to AI auto complete, and now it's some vscode flavor.

However with the Clangd extension it is much much better. Even better than Qt Creator. 100% accurate C++ code intelligence, really really fast error squigglies. Honestly I was kind of surprised it's even possible to get it that good.

It's not quite on the level of Dart (which is basically instant and perfect), but I'd say it's on the same level as Rust at least in terms of responsiveness and reliability.

I think QML is very easy to get started with and you should just give it a go. It's not without its weirdness as other comments have already mentioned, and unfortunately there's still many controls that are less-than-ideal for desktop applications than their original QWidget equivalents. Using QWidgets+UIC is nice, but in my experience creates problems when you want to get fancy and custom with your design, with animations and shifting layouts and whatnot, well, especially after using QML.

Once you fix it so that Rust-analyzer sees the same env vars as your shell then the issue goes away. It's kind of annoyingly hard to debug though.

Torrents themselves work against this, because you have known hash values as part of seeding... with email and messaging, you wouldn't have one-off advanced knowledge, and if anyone can send anyone a message, you'd be open to a flood of messages from what seems to be randos. There's some of this from scammers on Telegram and other social media, but it would be much worse.

A federated system that's otherwise tethered to a domain/email or similar would at least allow for self-management and/or block listing techniques to work better in practice.