Bento: Jupyter Notebooks at Meta

Original Article ↗ Hacker News Discussion ↗

Meta’s in-house Jupyter-based notebook system, Bento, draws mixed reactions: some praise its tight integration with Meta’s massive data and infra stack, while others describe the broader internal tooling ecosystem as fragmented, under-documented, and hard to use. Commenters note that Bento is not open source and that its real value is deeply tied to Meta’s proprietary frameworks, limiting relevance for outsiders beyond serving as design inspiration. The thread broadens into a comparison of big-tech internal tools, debates over monorepos and custom forks of common software, and contrasting views on the usability of notebooks versus alternatives like VS Code notebooks and marimo.

Meta’s Internal Tooling: Powerful but Frustrating

  • Some describe Meta’s internal tools as an impressive, tightly integrated ecosystem that makes working with massive systems and data very effective.
  • Others report the opposite: many tools feel brittle, poorly documented, abandoned by original teams, and hard to debug without reading source.
  • A recurring complaint is duplicated effort: people build new systems or pipelines only to discover later that equivalent internal solutions already existed but were hard to discover.
  • Culture around “just read the code or submit a fix” is seen by some as empowering, by others as unreasonable overhead on top of regular work.

Bento Itself and Availability

  • Bento is viewed as valuable mainly because of deep integration with Meta’s data and infrastructure stack: easy path from raw data to cleaned tables to analysis and sharing.
  • It is not open source and likely hard to extract due to dependencies on Hack and internal frameworks.
  • Some note that public Jupyter-like tools (e.g., JupyterLite, Colab, marimo) give a similar experience minus Meta’s internal integrations.

Scale, Forking, and Monorepo Choices

  • Meta heavily forks or reimplements tools (e.g., Mercurial/Sapling instead of Git, forks of PHP, ZooKeeper, etc.) to handle extreme scale (huge monorepo, very high commit rates).
  • There is disagreement on why Git was rejected: one side cites algorithmic/Big-O issues at Meta’s scale; another blames misconfiguration, poor benchmarking, and social friction with Git maintainers.
  • Large monorepos at this scale are described as rare and inherently hard; some argue Git can be made to work, others say it fundamentally doesn’t fit “massive.”

Big-Tech Tooling Culture and Comparisons

  • Commenters claim Meta, Google, and Netflix all have advanced but complex internal stacks, often much better than typical large enterprises yet still painful to use.
  • Internal “platform” or tooling projects can become empires, with incentives to fork and maintain bespoke systems.
  • Some praise Google’s internal tools and Colab as more polished; others say all big companies’ internal tools are “bad” in predictable ways.

Notebooks and Alternatives

  • Opinions on notebooks are polarized: some see them as indispensable, others find them slow, awkward, or “abominations.”
  • VS Code notebooks, Colab, and marimo are repeatedly mentioned as more pleasant or powerful than vanilla Jupyter.