Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bento: Jupyter Notebooks at Meta

engineering.fb.com

Post reply on HN
Print view View original

81–90 of 134 posts

Re: Bento: Jupyter Notebooks at Meta

#81

Post by 3eb7988a1663 »

taeric wrote: post #60
Fraterkes wrote: post #26

A bit off-topic, but my problem with any notebook type of tool (ie you create a document that mixes code, the output of that code, and text/media) is that they always feel like they're meant to be these quick, off the cuff ways to present data. But when I try to use them they just feel awkward and slow. (I tried doing a jupyter notebook with the vscode plugin, and while everything was very polished, it feld like I wa…

I'm assuming you've seen https://www.youtube.com/watch?v=7jiPeIFXb6U&t=61s ? I know I found it far more amusing than I should have when it was released. 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.

That video cannot be seen without watching Jeremy Howard's rebuttal: I Like Notebooks. I also believe this was the video that got him kicked out of a conference(?) because it was too confrontational? Which was just ugly for a guy who clearly loves being an educator.

[0] https://www.youtube.com/watch?v=9Q6sLbz37gk

Re: Bento: Jupyter Notebooks at Meta

#82

Post by 3eb7988a1663 »

wenc wrote: post #40
lamename wrote: post #35

Earlier quoted context omitted.

IME notebooks in VS Code are even worse (but improving). Jupyter lab is faster...but that depends on how fast you prefer ;)

I have the exact opposite experience — VS Code notebooks are much snappier and are possibly the best Jupyter implementations I’ve ever used (better and more responsive than vanilla Jupyter or Jupyter labs). 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 J…

I agree with you that the VSCode experience feels superior. It integrates a lot of the other various IDE widgets into the notebook experience. Code formatting, variable definitions, spell checker, non-garbage tier code hints, etc. The little timer noting the time it takes to run a cell alone is a huge boon.

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.

Re: Bento: Jupyter Notebooks at Meta

#83

Post by dmurray »

adolph wrote: post #71
wenc wrote: post #40

Earlier quoted context omitted.

I have the exact opposite experience — VS Code notebooks are much snappier and are possibly the best Jupyter implementations I’ve ever used (better and more responsive than vanilla Jupyter or Jupyter labs). 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 J…

Killer feature of VS Code notebooks is Vim keybindings. It also manages movement between cells, so you have to be very aware of the current mode.

Hitting Escape in normal mode takes you out of editing the cell and into "notebook manipulation mode" instead. This is so counter to the way Vim normally works - Esc should leave you in normal mode no matter where you started - that I found it almost unusable until I realised I could just remap that binding. I made it Shift-Esc and am very happy with it now.

Re: Bento: Jupyter Notebooks at Meta

#84

Post by zeofig »

Fraterkes wrote: post #26

A bit off-topic, but my problem with any notebook type of tool (ie you create a document that mixes code, the output of that code, and text/media) is that they always feel like they're meant to be these quick, off the cuff ways to present data. But when I try to use them they just feel awkward and slow. (I tried doing a jupyter notebook with the vscode plugin, and while everything was very polished, it feld like I wa…

I have to admit that I hate them and view them as abominations. But that's just my personal opinion.

Re: Bento: Jupyter Notebooks at Meta

#86

Post by fsociety »

landedgentry wrote: post #51
extr wrote: post #8

Earlier quoted context omitted.

Yeah 100%. I found it immensely frustrating to be using tools with no community (except internally), so-so documentation, and features that were clearly broken in a way that would be unacceptable for a regular consumer product. If you have a question or error not covered by an internal search or documentation, good luck, you'll need it. Literally part of the reason I left the company.

Well, you're supposed to read the code and figure it out. And if you can't, you're not good enough an engineer. According to people at Meta.

Or you know, go chat with the tool maintainers because they want people using them for impact.

Re: Bento: Jupyter Notebooks at Meta

#87

Post by tru3_power »

extr wrote: post #58
landedgentry wrote: post #51

Earlier quoted context omitted.

Well, you're supposed to read the code and figure it out. And if you can't, you're not good enough an engineer. According to people at Meta.

People probably think you’re exaggerating but it’s true. Sometimes when I would get blocked the suggestion was to “read the source code” or “submit a fix” on some far flung internal project. Huge fucking waste of time and effort, completely unserious.

No matter what, tools will be broken. Having access to the source and being able to land a diff to fix the issue is awesome imo.

Re: Bento: Jupyter Notebooks at Meta

#88

Post by almostgotcaught »

crabbone wrote: post #12
web3aj wrote: post #2

The internal tools at Meta are incredible tbh. There’s an ecosystem of well-designed internal tools that talk to each other. That was my favorite part of working there.

A friend of mine is doing his PHD while being an intern at Meta. He does not share your excitement... at all. To summarize his complaints: a framework written a long while ago with design flaws that were cast in stone, that requires exorbitant effort to accomplish simple things (under the pretense of global integration that usually isn't needed, but even if was needed, would still not work).

> A friend of mine is doing his PHD while being an intern at Meta

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).

Re: Bento: Jupyter Notebooks at Meta

#89

Post by ElonChrist »

Random_BSD_Geek wrote: post #4
web3aj wrote: post #2

The internal tools at Meta are incredible tbh. There’s an ecosystem of well-designed internal tools that talk to each other. That was my favorite part of working there.

Polar opposite of my experience. To achieve the technical equivalent of changing a lightbulb, spend the entire day wrangling a dozen tools which are broken in different ways, maintained by teams that no longer exist or have completely rolled over, only to arrive at the finish line and discover we don't use those lightbulbs anymore. Move things and break fast.

[dead]

Re: Bento: Jupyter Notebooks at Meta

#90

Post by steventhedev »

kridsdale3 wrote: post #56
tqi wrote: post #28

Earlier quoted context omitted.

Facebook actually doesn't use git, they use mercurial ( https://graphite.dev/blog/why-facebook-doesnt-use-git ). 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.

Yes when I used to talk about this to interviewees, I described that every tool people commonly use is somewhere on the Big-O curves for scaling. Most of the time we don't really care if a tool is O(n) or O(10 n) or whatever. 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.

I'm gonna disagree with you there. The difference was with stat patterns, and the person at Facebook who ran the tests had something wrong with the disk setup that was causing it to run slowly. They ignored multiple responses that reproduced very different results.

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.

Post reply on HN