Hacker News Reader

Comment by crubier | Hacker News Reader

This is amazing! It might be a personal feeling, but my opinion is that Facebook is SO much better than Google at delivering open source libraries that people want, and support them in the best way.

React vs Angular, Pytorch vs Tensorflow. These are just two examples among many where the Facebook framework arrives a bit later on the market but is then supported awesomely and improved continuously while the Google framework arrives earlier but then becomes a hot mess of non retro compatible upgrades and deprecations...

My “loyalty” to Facebook open source libraries just keep growing.

View on HN

Not to dismiss anything you mentioned, but looking at the big picture Facebook also published things that went awry / never really gained adoption. Flow, Buck, Hack to name a few.

I mean, the cool things are cool (even if I have a really hard time with Facebook as a company) but I think it's a bit of a stretch to say Facebook has "the recipe".

FB has thrown a lot of random stuff over the wall that they use internally and thought might be useful to other people. I think Hack and Buck fit into this category. Facebook will maintain them forever, because they are core parts of internal infrastructure. Their value to Facebook is completely independent of wider industry adoption.

Whereas PyTorch is intended, from the ground up, to be a widely useful project, and the dev team weights open-source issues at least as much as internal ones.

(Full disclosure: I used to work at Facebook, including, briefly, on PyTorch)

That's because people at FB have to contribute OSS to help with leveling. Especially after lvl5

This might explain the difference I perceive between FB and Google on OSS. I’ve heard that Google rewards more the creation of new projects.

I actually have been burnt by Flow so I agree with you, I don’t say that they have “the recipe”.

But my subjective point of view is: Google project = “Meh, this big opinionated framework will be probably be abandoned in 2years and all those poor folks who adopted it will have to rewrite everything”, while Facebook project = “Wow they just took the best of the state of the art, and packaged it in a simple reusable library that will be supported decently”.

Not a big fan of Facebook as a company, but as an open source contributor they are among the best in my book.

I would say their track record is still better but it’s hard to compare since some projects are more impactful than others.

Another example is Presto SQL Engine.

FastText, RocksDB...

Isn’t part of that caused by Facebook actually drinking their own poison?

Part of what made AWS get such a head start is that Amazon actually build it for themselves. Google just throws random tech around, but most of their own tools stay internal.

Being a little slower to release allows you to learn from other's mistakes. Python tends to follow this philosophy when adopting language features, they're usually not the first to introduce something, but when they do introduce it it tends to be very polished. For long term maintainability, and adoption this matters tremendously.

Google has go, that one at least is pretty great.

Not everyone agrees with that one.

Maybe its because I haven't got much experience with PyTorch but I find Tensorflow's API much simpler to understand. Do you think putting time to learning PyTorch will change my mind?

I guess you never used React Native then，talk about a hotmess that was broken with each release.

I have been using react native for 3 years and it is amazing! To my knowledge there are no equivalent platform allowing to develop cross platform apps in Typescript.

My react native app does some advanced stuff like displaying 3D stuff with openGL, running separate threads, interacting with drones and running neural nets (hence why I am happy about this news!). I still have to think how to upgrade to 0.60 while supporting threads though.

While it was not always super easy to configure all this, it has stayed unbroken for all this time so again this is something I am thankful for.

Well, that wasn't my experience, my experience is that each new release seriously broke my project, that Android React-native was in a sad state for a long time, that scrolling list and image loading performance was bad and had to be replaced with custom versions, that the attempts to write the Navigator in JS were bad and janky, and you invariably had to resort to native platform dependent ones, and one and one. The migration tool frequently failed for me.

And I'm not even referencing the sorry state of third party components as well. Something as simple as a map component or bluetooth component would break on every release.

Oh, and then there's Babel choking on large complex projects in hard to debug ways.

I agree that upgrading versions in react native is not as simple as increment it a number in package.json.

My advice to you in your case would be find the versions that work and then stick to them.

Only update when needed and treat migrations seriously (in a separate branch, migrate, test everything and only merge once everything works perfectly).

That’s what we do and we did rollback several migrations because of various problems. But given our complex stack I think this is fair enough.

Reply on news.ycombinator.com