231–240 of 333 posts
So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment: - 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…
The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2
From TFA: "We reduced core Messenger code by 84 percent, from more than 1.7M lines to 360,000." Sounds like not only did they make the app quicker and lighter, they improved code maintenance too. If the android app is as the same size as the new ios messenger app, they'd still have less code to maintain than the previous ios messenger app. See also: this other comment - https://news.ycombinator.com/item?id=22468036
> And yet, for the people using the app, it won’t look or feel much different. Yikes. Okay, I know I'm maybe being a bit unfair here, but I'm sorry to say that this is one of the weakest engineering blog posts I've ever read. This seems to be a massive "let's end the craziness and finally pay our tech debt" effort. Good for them, but not something that excites me about working at Facebook.
From https://engineering.fb.com/data-infrastructure/messenger/ : Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used qui…
They make it sound like the clouds parted and a ray of sunshine struck the programmers at Facebook and they realized that they didn't have to ride the framework-go-round to hell. These are supposed to be the smartest people in SV, but from the outside, it strikes me more as a "No shit, Sherlock" moment.
“They’re not confessing, they’re bragging”
The loop of app building: 1. Build app with native framework. 2. Re-build app with some alternative framework which is slower, but let's you deploy single code on all platforms. 3. Re-build app with native framework, because it is faster. 4. GOTO 2
Is there anywhere that suggets it was ever non native?
From https://engineering.fb.com/data-infrastructure/messenger/ : Rather than reinventing the wheel, we used the UI framework available on the device’s native OS to support a wider variety of application feature needs. This reduced not only size, by avoiding the need to cache/load large custom-built frameworks, but also complexity. The native frameworks don’t have to be translated into sub-frameworks. We also used qui…
Earlier quoted context omitted.
What language(s) does Spotify use for the backend? not the website or the mobile clients, but the backend itself.
Mostly Java.... some scala (some teams might use it), and potentially other languages. It built its own api lightweight java framework around 2014-2015 (called Apollo), which is actually pretty decent/nice to work with. There was a lot of protobuf usage early on, but most teams started transitioning to plain json. So, each team runs its own servers, for the features it is developing/maintaining, and most of the api g…
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.