Hacker News Reader

Comment by jordanab | Hacker News Reader

While the implementation certainly seems very nice, the ideas behind Prism 2 aren't particularly new, or unique for that matter. For example the .NET ecosystem already has (for a long time) most of the stuff that is presented as being uniquely offered by Prism: generated database clients (LINQ-to-SQL, Entity Framework), generated data models (EF POCO's), type-safe queries (LINQ) etc.

View on HN

Some of the ideas we've built into Prisma are certainly inspired by tools in other languages and we've looked a lot at LINQ and the C# ecosystem in general as we designed Prisma!

However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se!

For example, we're already working on Prisma Client for Golang which is already available in alpha!

[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...

[2] https://github.com/prisma/prisma-client-go

What exactly does your "query engine"/planner actually do? I understand the role that, for example, the Postgres query planner does.

Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?

I'm assuming that it's basically a port of GraphQL+DataLoader, so basically using recursive descent to manage hash joins.

Assuming something in the same vein as fizx with the addition that it's probably very similar to what Join Monster tries to solve: https://github.com/join-monster/join-monster

Everything is being reinvented from scratch in the JS world. The insistence on unifying into one language means that a lot of tried tested and true has been tossed aside and it's all being rebuilt sometimes with dubious benefit.

And perhaps detriment. Nodejs apps are notoriously more difficult to keep secure because of how many npm dependencies are needed for a project and how often vulnerabilities are discovered in those dependencies.

And at the end of the day all we do is select, insert, update and delete in some database.

True true

Same thing happened with Python for data science in 2023-2015. ie reinvent SQL using Python DSL.

Have you tried jupyter notebook + pandas dataframes? You just import a csv and you can explore, clean, manipulate data and make any sort of calculation using a real programming language. On top of that you can use something like seaborn and create visualizations. Then you click print pdf and you're ready. It almost feels like cheating.

You can say all you want about how fast,optimized and superior SQL is, but the python experience is way better for almost any time you need to make sense of some data.

Not the OP, but I have.

I've spent years doing the work that you specify above, and pandas & notebooks are probably one of the least good tools for it. SQL is super fast and useful (and everyone understands it, at least in the data world), while dplyr and ggplot2 are basically a DSL for this work, while pandas is an irritatingly bad clone of base-R which manages to keep the bad parts of both Python and R, while having the good parts of neither.

I really feel like you should try Rmd with R if you like the notebook flow, as it's similar but much much better.

If you really want to stick with Python, then org-mode is a much better notebook than anything else.

I have a significant amount of experience with both of them. For pandas, it is fine for initial exploratory analysis (input, plot, reshape and export, etc). However, it's API has inconsistencies and subtle "features" around silent data coercion that make it hard to use in production. Seaborn is much nicer to work with than matplotlib and Jupyter is useful for making interactive presentations. So I believe Pandas/Jupyter have a place, but then there was a tendency to create a Pandas-like wrapper for all data retrieval such as:

https://github.com/ibis-project/ibis https://github.com/blaze/blaze

This is why we are focusing on the Node and Go ecosystems first :-)

If you liked the developer experience in the .NET ecosystem but find yourself needing to work with JavaScript or Go, you'll probably like Prisma.

Is this a bad thing? Are we only interested in funding brand new ideas?

Reply on news.ycombinator.com