Lots of nonserious companies that take those issues as enough of a reason to move slowly.
Many fewer serious ones where bad tooling is expected to be fixed, smoothed over, or replaced entirely in the interest of future dev time.
Since Bento doesn't appear to be usable by the public, aparallel version of this that people can get a feel for cross-tool integration would be Google's Colaboratory / Colab notebooks (https://colab.research.google.com/) that have many baked-in integrations driven by actual internal use (i.e. dogfooding).
That decision is also illustrative of why they end up forking most things - Facebook's usage patterns at the far extreme end for almost any tool, and things thats are non-issues with fewer engineers or a smaller codebase become complete blockers.
At Meta, N tends to be hundreds of billions to hundreds of trillions.
So your algorithm REALLY matters. And git has a Big-O that is worse than Mercurial, so we had to switch.
Nail in the coffin on this was a benchmark GitHub ran two years ago that got the results that FB should have: git status within seconds.
Facebook didn't use mercurial because of big O, they used it because of hubris and a bad disk config.
Half-remembering a blog post I read - the git maintainers also wouldn't give Facebook the time of day on code changes to accommodate FBs requirements. Mercurial was more amenable. This also disproves the "Facebook has a fork of evertyhing, because the attempted to upstream the changes they wanted)
Anyways:
1. Github benchmark: https://github.blog/engineering/infrastructure/improve-git-m...
2. The original email thread: https://public-inbox.org/git/CB04005C.2C669%25joshua.redston...
3. There's another email thread that gets linked everywhere - but in light of the prior thread, the numbers don't track: https://public-inbox.org/git/CB5074CF.3AD7A%25joshua.redston...
I recall there being a message from someone either at AirBnB or Uber who mentioned that they have a similar monorepo but without the slow git status, but can't seem to find it now - it's likely on one of the other mailing list archives but didn't make it to this one.
Point being that painting this as "the community was hostile" or "git is too slow for FB" is just disingenuous. The FB engineer barely communicated with the git team (at least publicly) and when there was communication, it was pushing a single benchmark that was deeply flawed, and then ignoring feedback on how to both improve the performance of slow blame, commit by repacking checkpoint packfiles (a one-off effort) and also ignoring feedback that the benchmark numbers didn't make sense in absolute terms.
Plenty of other customers with the same magnitude problems as Meta are using Git perfectly fine.
The few things that don't have forks are usually the open source projects like React or PyTorch, but even those have some custom features added to make it work with FB internals.
Google also maintains a monorepo with "forks" of all software that they use. History diverges, but is occasionally synchronized for things like security updates etc.
zeus likewise.
I assume all of the big tech companies host internal mirrors of every single code dependency + tooling. Otherwise they could not guarantee that they can build all of their code.
I interned thrice as phd student at FB. your friend isn't entirely wrong but also just doesn't have enough experience to judge. all enormous companies are like this. FB is far and away better than almost all such companies (probably only with the exception of Google/Netflix).
Netflix would like to have a word.
Apologies if this response is delayed, 6 posts today is "too fast."
https://github.com/Clay-Ferguson/quantizr
I'm thinking that Jupyter might still not be "Tree Based" but that would be a heck of a leap in capability if they "fix" that.
Couldn't find any link in the open source site: https://opensource.fb.com/ nor the ELI5: https://developers.facebook.com/blog/post/2021/09/20/eli5-be...
But it has some cool features that notebook developers can take inspiration from.
If anyone's on the fence about applying, that could be enough to nudge them in the direction. If anyone's worked in similar areas, could be worth applying and looking at the team, etc.
I will confess that I found Mathematica kind of neat back in the day. I never got as good with it as peers did. I'm curious if that would be different for me today.
VS code notebooks also support LSPs with refactoring, typing etc. Black is supported. Step by step debugging is supported. Venv is built in.
There are so many conveniennces in VS Code that whenever I have to use Jupyter Lab I feel a lot of stuff is missing.
My only complaint is how white space heavy the VSCode layout is by default. Probably can be customized, but I have never dug into it.
Notebooks are usually not inherently slow — I use Jupyter in VS Code running off a remote server and it’s snappy.
I have a MacBook Pro 2020.