5 ms·
LINQ, PRQL, Kusto has all preceeded this. While LINQ is mostly restricted to .NET, PRQL is not. https://prql-lang.org/ https://prql-lang.org/ It's a welcome c
by tehlike 2y ago
LINQ, PRQL, Kusto has all preceeded this.
While LINQ is mostly restricted to .NET, PRQL is not.
https://prql-lang.org/ https://prql-lang.org/
It's a welcome change in the industry.
I made this prediction a couple years back:
https://x.com/tehlike/status/1517533067497201666 https://x.com/tehlike/status/1517533067497201666
- andrewguy9 2y agoI’m a big kusto user, and it’s wonderful to have pipes in a query language. If you haven’t tried it, it’s great!
- tehlike 2y agoI have not tried it, but I used to be a .net developer and worked a lot with LINQ (and contributed a bit to NHibernate and its Linq provider) and I am a big fan of the approach. Kusto does seem interesting too, and i think some of the stuff i want to build will find a use for it!
- Salgat 2y agoLINQ is so incredibly intuitive. I wonder if this will make creating C# LINQ providers for databases that support this syntax easier.
- kbouck 2y agoIndeed. Elastic has also recently released a piped query language called ES|QL. Feels similar to Kusto. I find piped queries both easier to write, and read.
- numbsafari 2y agoThe paper directly references PRQL and Kusto. The main goal here is to take lessons learned from earlier efforts and try and find a syntax that works inside and alongside the existing SQL grammar, rather than as a wholly separate language.
- hn_throwaway_99 2y agoI've been following PRQL for some time now since it first got good traction on HN and I like it a lot, but I'm really hoping this pipe syntax from Google takes off for a couple of reasons: 1. Similar to what you mention, while I think PRQL is pretty easy to learn if you know SQL, it still "feels" like a brand new language. This piped SQL syntax immediately felt awesome to me - it mapped how my brain likes to think about queries (essentially putting data through a chain of sieves and transforms), but all my knowledge of SQL felt like it just transferred over as-is. 2. I feel like I'm old enough now to know that the most critical thing for adoption of new technologies that are incremental improvements over existing technologies is to make the upgrade path as easy as possible. I shouldn't have to overhaul everything at once, but I just want to be able to take in small pieces a chunk at a time. While not 100% the same thing, if you look at the famously abysmal uptake of things like IPv6 and the pain it takes to use ES module-only distributions from NPM, the biggest pain point was these technologies made you do "all or nothing" migrations - they didn't have an easy, simple way to get from point A to point B. The thing I like about this piped SQL syntax is that in a large, existing code base I could easily just start adding this in new queries, but I wouldn't really feel the need to overhaul everything at once. With PRQL I'd feel a lot less enthusiastic about using that in existing projects where I'd have a mix of SQL and PRQL.
- lupire 2y agoIt's wild that the enterprise and connected world has moved on from forcing COBOL compatibility for modern projects, but still insists on SQL compatibility.
- oaiey 2y agoIs "from" keyword originating from .NET (Framework 3.5 in 2007) or is this pre-existing somewhere in research?
- anonzzzies 2y agoNot having LINQ is a terrible inconvenience everywhere. Most languages have libs that try to hack something similar, but it usually simply isn't.
- mrits 2y agoIt's a lot easier to design a good DSL when it doesn't have to be compatible with anything
- anonzzzies 2y agoWell, .NET was already used a lot when it was built in a few decades ago.