Messenger may not have "HN clout" but the devs who work on it are having some of the greatest software impact in the world.
To be fair, this is part of the problem ^
In fact people who like stories and camera effects likely way outnumber the people that don't.
Summarizing it as a chat app is probably the first miscommunication here.
The number of people that use camera effects as anything other than a gimmick is even smaller.
Maybe a different age group?
I think that most of people of HN have friend groups which are wildly unrepresentative of world population at large. We're talking not even an average US or European citizen here - we're talking 1+ billion. People from developing countries who very often access internet only from a smartphone (they don't own a computer) and who almost don't visit plain http websites outside of the few social apps.
It's a completely different world out there.
Some of the problems outlined, like having 40 different views of contacts, with unique code, seem like fairly clear organizational problems.
I wonder if they could make apps more modular, and only load the binaries for e.g. payments on demand. I know Apple offers a system that does that for content chunks (e.g. levels and assets in games), and in a web-based application (e.g. react native) they could use bundling to remove it from the initial download.
Spotify had about 500k, lines of code in 2015, (not including external libraries).
We did make it in a feature based architecture, where there was a main container app (and a major core playback library) and for every major feature they had their own sub-project.... and there were 10+ teams contributing into it.
There were about 13 features at the beginning, (think, playlists, radio, shared ui libraries, etc...).
Each feature was about 10-20k lines of code in total. So, about 2-3 features equal a small standalone iOS app.
When I left, there were more than 80 features in the app. Some were essential, many were a/b tests, and some were probably just legacy/waiting to be removed.
80 features * 15k lines of code = 1.2mil loc, easily, and they are the equivalent of shipping 20 small apps standalone....
What are these features and why is just a stupid music app so large? : video, podcasts/shows, genius, etc.. etc.. etc.... To users just looks like another tab but almost every one of these major features could be its own standalone app for size and complexity.
Most people (including myself) will probably never see a >500K loc application or a project with >100 developers working on it. Biggest ones I've worked with had around 30-50 odd developers?
No.
> incompetence
Yes.
> or self interest
Yes.
That said, I’m happy with React.
I currently work on a project that is much larger than I would expect it to be, both in terms of codebase and people, and while I don't know who to jank, I also don't understand why it has to be so big.
And then your bathroom. And then convert the garage. And then add an addition. And in 10 years you have this cobbled-together monstrosity
Now your entire house is built with those screws, but they’re not produced anymore so you’ve set up a small smelter next to your home where you’re making them yourself.
Unfortunately the quality is a good bit worse, so parts of your house start degrading faster and faster, but meanwhile you’re still building all new parts with your shitty screws.
Nobody wants to replace the screws because “It’s a proven method”, ignoring all signs to the contrary.
All new parts of the house are only as good as the worst part, the screws, and the moment anyone steps on the wrong plank the whole room comes crashing down. But nobody worries, next time they’ll just use two screws.
It can oftentimes be worthwhile to have individual teams each fully "own" a piece of the product, and that also comes with the autonomy to choose to duplicate stuff that other teams might have already built rather than working with them and tweaking it to match their own specific new requirement.
This significantly reduces communication & coordination overhead for delivering new features, at the expense of consistency and code reuse, which can often be a worthwhile tradeoff at scale.
Because nobody ever got promoted for not hiring people or for not writing code.
The problem is 10x as bad when you're an "IT company", i.e., writing code is your primary product.
True though, if you want more features you need more code. Sure, loads of people on HN could build a 'chat app' in a lot less but if they kept it going for ten years (same age as our product) and kept on adding new features the lines would start to add up...
So, each team runs its own servers, for the features it is developing/maintaining, and most of the api goes throw a common gateway, etc.. etc... don't want to give out more than this.
Some of the simple front end web pages (i.e. marketing websites, analytics) might even be on php/python/ruby. Some teams wanted to use javascript (Node), but those are not the critical main app, as java is pretty much required to be used for anything that affects the main app.
Also, if you are doing machine learning, then whatever it gets the job done (usually Python).
btw, I left few years ago, so things might have changed.... I know at least one team that wanted to use GO for some of their services....
I can't shake the feeling that the dominating factor in growth of LOC isn't the number of features per se, but the number of features worked on in parallel by separate teams.
I honestly think it is. Compliers, DBMS, a library such as NumPy— they're all complex, but Messenger, even considering the features removed, is a very full-featured application. We're not talking IRC here. It has activity status, payments, stories, photo filters, audio messages, location sharing, video-calling, etc. It's actually pretty impressive that that fits in 360K LoC IMO.
> We also used quite a few of the OS libraries, including the JSON processing library, rather than building and storing our own libraries in the codebase.
I'm really not a fan of this virtue shaming that people often tend to do as developers, where if you're not working to solve world peace then you're a waste of a developer.
Sometimes people just like getting paid? Sometimes people just don't really care, they just want a job or want to write code?
I am not really defending it, but number of code lines alone is not a good way to evaluate code.
Having a GUI doesn't justify 1 million+ LOCs, but just for a sanity check, pgAdmin 4 has ~260k LOCs, without counting its dependencies.
THAT code, my "all encompassing, personal repository for every VR app I'd ever make", is only 100K lines of code.
I once downloaded all of my dependencies and counted all of those lines and still only got to 200K. Well, not counting Unity. But at that point, you might as well start counting the LoC of the OS.
I wouldn't mind if other people started using the code, but I've been burnt too many times during attempts to push my OSS projects over the years that I just don't want to put any actual effort into attracting people anymore.
If it having 1.7M lines of code indicates anything it is that creating a "simple app that provides simple functionality over a network well" is hard.
Look at the garbage generated by Google - text messages and images on Google hangout are not guaranteed to arrive in order ( or even be sent in order ) unless you are on a great network.
Does it? I routinely use Telegram, Line and Messenger. Messenger is without contest the one that gives the most trouble.
I've been using chat apps at least since ICQ (1996) and sometimes I feel the user experience has declined.
That being said, I'm sure that a lot of progress have been made and that there's a lot going on behind Messenger in terms of security and scalability. I'd be curious to know what's hidden between the millions LOC.
You never used ICQ over a spotty 3G connection, though, did you?
$ tc qdisc change dev eth0 root netem loss 0.3% 25%
$ tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal
That's a joke, right? On a crappy internet connection (e.g. using O2 as carrier on the train cologne-hamburg you get ~12s ping, 30kbps, >90% packets dropped, via edge) most chat apps stop working, but Facebook Messenger is (except for Riot.im and Discord) probably the one that works worst.
Telegram works better, even IRC via Quassel/Quasseldroid works significantly better, and especially WhatsApp works so well you don't even notice the connection issues.
Facebook Messenger doesn't even properly start on such crappy connections.
FB messenger exists and works on crappy connections. Google hangout exists and messes up on crappy connections. Telegram exists and messes up on crappy connections ( see the issues it has in Africa ). Signal exists and does not work well even on non-crappy connections. Whatsapp exists and sort of works on crappy connections. Matrix exists and sucks on crappy connections.
What we need is something that exists and works on crappy connections that has less LOC than FB messenger to demonstrate that it is possible to handle crappy connections and modern messaging in much fewer lines of code.
That's why your comment is nonsensical, if not downright contradictory noise.
> Ordering messages and providing reliability does not require 1.7M lines of code.
This has been demonstrated ad nauseum a priori with loads of toy chat apps that reconnect and retain state. It's not really a challenge. EVERYTHING else crammed into it, should be the reasoning for 1.7M lines of code, but as they demonstrated TO THEMSELVES AND EVERYONE, it wasn't (360k now)
Yes and they figured out what was needed after first writing a 1.7M line of code thing that worked. That's the process of reiteration and a process of initial LOC bloat before LOC stripping.
Without that process by thinking it has all been demonstrated ad nauseum a priori with loads of toy chat apps that reconnect and retain state you end up with deciding that if Friday was Feb 28th then Monday is certainly March 3rd because date/time handling is simple and end up being Robinhood, down for a day.
Speaking of garbage, looks like most of the 1.7m LOC on Messenger was actually garbage, now that they’ve literally thrown most of away.
Also known as:
You can do dropbox with FTP.
If Friday is Feb 28th, then Monday is March 3rd. There's no need for those bloated date libraries.
> Speaking of garbage, looks like most of the 1.7m LOC on Messenger was actually garbage, now that they’ve literally thrown most of away.
Certainly. It worked before the change. So it is given that 1.7m of "garbage" provided a working product.
How many lines of code it took Google to make Hangout not get confused by image uploads on crappy connections? Unknown, because it is still confused.
How many lines of code it took Signal not to delay messages when a recipient is on a crappy connection? Unknown, because it still does that.
NumPy is a library. The other three are compilers. Why are you comparing these with a GUI-based chat application?
> [...] We accomplished this by using the native OS wherever possible [...]
- NumPy is 360K lines mostly C
- Postgres is around 2.1M of C
- Go 1.13 is around 1.5M of Go code
- Rust 1.37 is around 1.2M of Rust code iirc
- core llvm is around 3M of C++ iirc
...
A chat app is 1.7M. A chat app...
Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've worked together on something truly awesome, big and useful. But we all know that doesn't pay the bills and so here we are.