4 ms·

What's the reason to go for this over PRQL?

zhiboz 3y ago
I had the exact same question when I saw the post.
IshKebab 3y ago
Looks like PRQL doesn't have a Go library so I guess they just really wanted something in Go? I would guess they didn't wrap the main PRQL library (which is written in Rust) because Go code is a lot easier to deal with when it's pure Go. And they probably didn't just write a Go version of PRQL because that would be a mountain of work. Still I think that's a mistake. PRQL is a far more mature project and has things like IDE support and an online playground which they are never going to do... Better just to bite the bullet and wrap the Rust library.
- tstack 3y ago
  > Looks like PRQL doesn't have a Go library so I guess they just really wanted something in Go? There's some C bindings and the example in the README shows integration with Go: https://github.com/PRQL/prql/tree/main/prqlc/bindings/prqlc-c https://github.com/PRQL/prql/tree/main/prqlc/bindings/prqlc-...
  - IshKebab 3y ago
    Ah yeah I wonder why they don't mention that in their docs.
- pkolaczk 3y ago
  It’s not the problem with binding to Rust. Python can do it, Zig can do it, C can do it, even JS can do. It is Go which doesn’t integrate well with anything that isn’t Go.
  - randomdata 3y ago
    Where did you dream up that idea? PRQL integrates with Go just fine. The project even provides an example in Go.
    - IshKebab 3y ago
      He said it doesn't integrate well, and he's right. Go works best when you only have Go. (Ok that's true of most languages but it's especially true of Go.) This article has some details: https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go Note that this isn't true of languages like Python (CPython) or Rust which are much more closely tied to C than Go is. Go is a "from scratch as if C never existed" language which is great because it doesn't have any C baggage but it does make integrating with C more awkward.
      - randomdata 3y ago
        > This article has some details Couldn't find your own words? The details don't say much. Sure, you have to bend to C to some degree, but that's true of every language that wants to integrate with C. Go integrates no less well than any other language on that front. And it's not even really all that accurate. Consider "Performance will always be an issue" – gccgo and tinygo have shown that you don't have to have any call overhead. They can call C functions as fast as C can. That is in no way a limitation of Go. That is only a limitation of gc, and even then the overhead is only a few nanoseconds these days. You're never going to notice. These may have been concerns in 2016 – indeed, overhead was a lot higher back then – but time marches forward. Things change. The link is fast approaching being a decade old by this point. At least give us something from 2024, about the current release that is 17 versions newer than the one referred to in the link, if you really don't know how to formulate your own thoughts. But you should be formulating your own thoughts if you want to participate in a discussion. Outsourcing thoughts to other people is nonsensical. If those other people want to participate in the discussion, they can write their own comments, but that is for them to do. > or Rust PRQL is written in Rust, so it would be quite strange if it wasn't true of Rust. Interestingly, the Javascript bindings use a WASM target. Go could also use the WASM target if there was some reason to avoid more traditional linking. It is curious that you didn't mention that. Again, reason to use your own brain. If you have to outsource discussion, why bother participating at all?
caust1c 3y ago
The simple answer is that it's too distinct from where we're trying to meet our users. We're not anti-PRQL, but our users (folks in security) coming from Kusto, Splunk, SumoLogic, LogScale, and others have expressed that they have a preference for this syntax over PRQL syntax. I wouldn't be surprised if we end up supporting both and letting folks choose the one they're most happy with using.
memset 3y ago
The big advantage of this project in my opinion is that it will pass functions it doesn’t recognize to the underlying DB. With prql, if they don’t support your favorite operator then you’re out of luck.
- beeskip 3y ago
  https://prql-lang.org/book/reference/syntax/s-strings.html https://prql-lang.org/book/reference/syntax/s-strings.html
  - memset 3y ago
    Did not know about that!

I had the exact same question when I saw the post.

Looks like PRQL doesn't have a Go library so I guess they just really wanted something in Go? I would guess they didn't wrap the main PRQL library (which is written in Rust) because Go code is a lot easier to deal with when it's pure Go. And they probably didn't just write a Go version of PRQL because that would be a mountain of work. Still I think that's a mistake. PRQL is a far more mature project and has things like IDE support and an online playground which they are never going to do... Better just to bite the bullet and wrap the Rust library.

tstack 3y ago
> Looks like PRQL doesn't have a Go library so I guess they just really wanted something in Go? There's some C bindings and the example in the README shows integration with Go: https://github.com/PRQL/prql/tree/main/prqlc/bindings/prqlc-c https://github.com/PRQL/prql/tree/main/prqlc/bindings/prqlc-...
- IshKebab 3y ago
  Ah yeah I wonder why they don't mention that in their docs.
pkolaczk 3y ago
It’s not the problem with binding to Rust. Python can do it, Zig can do it, C can do it, even JS can do. It is Go which doesn’t integrate well with anything that isn’t Go.
- randomdata 3y ago
  Where did you dream up that idea? PRQL integrates with Go just fine. The project even provides an example in Go.
  - IshKebab 3y ago
    He said it doesn't integrate well, and he's right. Go works best when you only have Go. (Ok that's true of most languages but it's especially true of Go.) This article has some details: https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go Note that this isn't true of languages like Python (CPython) or Rust which are much more closely tied to C than Go is. Go is a "from scratch as if C never existed" language which is great because it doesn't have any C baggage but it does make integrating with C more awkward.
    - randomdata 3y ago
      > This article has some details Couldn't find your own words? The details don't say much. Sure, you have to bend to C to some degree, but that's true of every language that wants to integrate with C. Go integrates no less well than any other language on that front. And it's not even really all that accurate. Consider "Performance will always be an issue" – gccgo and tinygo have shown that you don't have to have any call overhead. They can call C functions as fast as C can. That is in no way a limitation of Go. That is only a limitation of gc, and even then the overhead is only a few nanoseconds these days. You're never going to notice. These may have been concerns in 2016 – indeed, overhead was a lot higher back then – but time marches forward. Things change. The link is fast approaching being a decade old by this point. At least give us something from 2024, about the current release that is 17 versions newer than the one referred to in the link, if you really don't know how to formulate your own thoughts. But you should be formulating your own thoughts if you want to participate in a discussion. Outsourcing thoughts to other people is nonsensical. If those other people want to participate in the discussion, they can write their own comments, but that is for them to do. > or Rust PRQL is written in Rust, so it would be quite strange if it wasn't true of Rust. Interestingly, the Javascript bindings use a WASM target. Go could also use the WASM target if there was some reason to avoid more traditional linking. It is curious that you didn't mention that. Again, reason to use your own brain. If you have to outsource discussion, why bother participating at all?

caust1c 3y ago

The simple answer is that it's too distinct from where we're trying to meet our users. We're not anti-PRQL, but our users (folks in security) coming from Kusto, Splunk, SumoLogic, LogScale, and others have expressed that they have a preference for this syntax over PRQL syntax. I wouldn't be surprised if we end up supporting both and letting folks choose the one they're most happy with using.

memset 3y ago

The big advantage of this project in my opinion is that it will pass functions it doesn’t recognize to the underlying DB. With prql, if they don’t support your favorite operator then you’re out of luck.

beeskip 3y ago
https://prql-lang.org/book/reference/syntax/s-strings.html https://prql-lang.org/book/reference/syntax/s-strings.html
- memset 3y ago
  Did not know about that!