Equiet

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.

I'd argue the opposite.

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.

I'm Jakub, CEO of Deepnote.

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!

Thanks for the feedback Simon!

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.

Comparing to Node it seems to be at about the same rate: https://star-history.com/#denoland/deno&nodejs/node&Date. It's actually quite impressive how close it is.

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

But not Germany.

According to the official announcement the wework locations will remain operational https://www.wework.com/newsroom/wework-takes-strategic-actio...

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

Europe is definitely safer than the US.

A missed opportunity to break it up into 40

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.

I saw your roadmap includes sync with Jira, how will that look like?

Deepnote (YC S19) is working on this (I'm the founder).

https://deepnote.com/

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?

This is the Czech equivalent of the Social Security Administration and it still works like this. Video: https://www.novinky.cz/domaci/clanek/devet-tisic-supliku-obs... (in Czech)

Hey, the founder of Deepnote here. Happy to chat about this.

It took 30 years, but literate programming paradigm is now very commonly referenced when working with notebooks, even though it's not what Knuth was going for in the first place and the original intent was different.

Notebooks are a direct evolution of REPLs and at the time of writing (Knuth published his paper on literate programming in 1984), REPLs have been well known (they had been around since 1970s). Yet there is not a single mention of them in the original paper, nor any prediction how literate-programming-capable notebooks could look like. At the time, these were two different concepts each serving its own need (documentation vs exploratory programming).

We tried Logtail in early beta and the experience was mind bending.

We used both ELK and Datadog before and over time I somehow stopped questioning why the logs are so slow. I thought we are simply hitting the theoretical limits of how fast searching in logs can be and unless there is a significant leap in hardware this is what we have to deal with. Then we tried Logtail and now we are migrating everything we can.

There's a video which shows how you look like to a UV camera when you put sunscreen on. Also glasses with UV filters: https://www.youtube.com/watch?v=o9BqrSAHbTc

Looks really good, but how is this different from PyPI? Is it just the design or are there more features planned?

When we look at data scientists, there is a wide spectrum in their background, skillset, workflow, etc. When we look at the users of data science notebooks specifically, there are many people who don't want to deal with the hassle of running their own infrastructure (possibly even more than those who do). I agree with you that the ability to use your own servers is important for lots of use cases, but it's not a hard requirement for us to get the product out to the public and ask for feedback. So we don't have on prem or GPUs at the moment, but it's something that we are working on.

Hey, just saw that, great work!

Not right now. This is something we'd like to do, but connecting to other clusters/architectures would bring a lot of additional complexity into the product. As a startup, we need to balance a lot of things and while we're in beta the development speed has the highest priority.

Got it. I can't speak of Gradient's roadmap, but as of right now they are using Jupyter as a notebook and focusing on infrastructure around it. We are innovating on the notebook itself.

Huge part of it is simply the UX. There's a wide range of what kind of work a data scientist does. Some train models that go into production, some analyze the datasets and build reports. Probably best to try both products with your workload and see what works better.

Paperspace is doing a great job providing infrastructure for data science workloads and mlops. The target users are data scientists/engineers. The ability to share with non-technical users is quite limited.

We built Deepnote so that the work you do as a data scientist can be shared with both engineers and non-technical folks. We're not really an mlops platform. We make a really good notebook that integrates with other platforms.

At the moment we have GitHub integration, so you can easily commit changes like you're used to. We also have project history (so you can see all the actions that lead to the current state of the project and review what happened while you were away).

But I'd like to improve on this experience. There are many ways how to do it (great job btw), but we want to explore how a versioning system native to notebooks would look like. We're still iterating on that.