We seriously considered this, but decided against this. While elegant for demo projects, it doesn't scale for serious deployments. You still need to deal with secrets, metadata (lots of it), backwards-compatibility, and extensibility (we have 23 block types today, many more to come).
All standards are ultimately controlled by private companies. Even non-profits require funding.
Open source always depended on a viable business model (of one or many companies) that can sustain not just the release, but also an ongoing maintenance of the standard.
There is plenty of AI extensions, but the experience matters. The depth of integration matters. When you execute queries against production warehouses and you make decisions based on the results of AI-generated code, accuracy matters. We had our first demo of an AI agent running in 2 days, it took us another 2 years to build the infrastructure to test it, monitor it, and integrate it into the existing data source.
You'd be surprised how many people collaborate together. Software engineering is solitary, collaboration happens in GitHub. But data analysis is collaborative. We frequently have 300+ people looking at the same notebook at the same time.
.py never worked for data exploration. You need to mix code, text, charts, interactive elements. And then you need to add metadata: comments, references to integrations, auth secrets. There are notebooks that are several pages long with 0 code. We are building a computational medium of the future and that goes beyond a plaintext file, no matter how much we love the simplicity of a plaintext file.
Didn't expect to see this trending here! We worked hard to execute on our vision of a data notebook and I'm glad we finally got a chance to open source it. We stand on the shoulders of giants. AMA!
You’re saying vector DBs are the wrong abstraction, but companies keep throwing money at them. Why? Are they just slow to catch on, or are there legit cases where vectors actually make sense?
Hey there, CEO of Deepnote here. It looks like we are thinking about this very similarly, as all 3 points are something that we are already doing or will be shipping in the coming weeks. Either way, good luck with Briefer and happy to chat about our learnings building all of these things.
$50 for 50GB seems like a fair offer for the US market, especially given the possibility of coverage in remote locations.
But keep in mind that US market is unique, as it's extremely overpriced with very poor quality/coverage. Looks like average price in the US is $6.00/GB. Compare this to countries like Israel ($0.02/GB) or Colombia ($0.20/GB). Whenever I travel, I usually have a better coverage and faster connection in a jungle than downtown SF.
We looked into many of these issues with Deepnote (YC S19) [https://deepnote.com/]. What we found is that these are not necessarily problems of the underlying medium (a notebook), but more of the specific implementation (Jupyter). We've seen a lot of progress in the Jupyter ecosystem, but unfortunately almost none in the areas you mentioned.
Lots of comments about relative safety of US vs European cities.
Looking at the data, you need to scroll past 9 US cities (all big cities) until you find the first European city (relatively small city you never have a reason to go to) in this crime ranking: https://www.numbeo.com/crime/rankings.jsp
Even if you can't use Deno in your project today, it's hard not be excited about the future that Deno is pushing towards (and dragging the Node ecosystem with it).
When ES6 came out but wasn't yet widely supported it became pretty common to add a build step to transpile the backend code to. This brought a whole bunch of issues that transpilation brought with it but was seen as a temporary evil worth the tradeoff because the new language features brought so many productivity improvements, but stuck for so long it became pretty standard. And when TypeScript became popular, it felt like we'll just never get rid of this complexity explosion that build systems bring. And then Deno came.
Just imagine the amount of config files you'll be able to delete once you no longer need to build your backend codebase.
It's surprising how seemingly difficult it is to build a good on-call scheduling system. Everything I tried so far (not naming the companies here) felt like the UX was the last thing on the developers' minds. Which is tolerable during business hours but really annoying at 2am.
Is there some hidden complexity or is it just a consequence of engineers building a product for other engineers? Also, any tips what worked for you?