17 ms·

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?
  - DinaCoder99 3y ago
    > Okay, sure, you have to bend to C to some degree, but that's true of every language that wants to integrate with C. Most of the languages I'm aware of integrate with the C runtime much more naturally than go is capable of. Go has its own type of stack, which means it's a pain in the ass to embed into the C runtime and it's a pain in the ass to embed the C runtime into it. > gccgo and tinygo Does anyone use these implementations? I honestly had no idea either project existed.
    - randomdata 3y ago
      > Most of the languages I'm aware of integrate with the C runtime much more naturally than go is capable of. In what way? Is it because you call `C.function_name` instead of `function_name`, the latter of which some other languages will allow? I don't see how that is a meaningful difference. Especially when Go developers are already accustomed to referencing pure Go functions in the same way. > Go has its own type of stack gc brings its own type of stack, but that's not a feature of Go. Let's not confuse an implementation with a language. Go says nothing about stack layout. > which means it's a pain in the ass to embed into the C runtime and it's a pain in the ass to embed the C runtime into it. There might be a pain in the ass for the gc maintainers, but that's not you. You will never notice or care. It is fully abstracted away. There is some overhead cost to that, but it has shrunk so dramatically over the years, you're not going to notice it anymore either. Protip: Don't use version 1.5 like the previous link is talking about. That was 17 major versions ago. > I honestly had no idea either project existed. How'd you miss gccgo, at least? It's maintained by the official Go team. It is the second compiler they always talk about – the one they use to ensure that the standard isn't defined by an implementation.
      - DinaCoder99 3y ago
        > Is it because you call `C.function_name` instead of `function_name`, the latter of which some other languages will allow? No, it's because they use completely different stacks. It has nothing to do with the aesthetics of the language. > You will never notice or care. It is fully abstracted away. I mean... aesthetically, sure. How the runtime works still matters a lot.

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?
- DinaCoder99 3y ago
  > Okay, sure, you have to bend to C to some degree, but that's true of every language that wants to integrate with C. Most of the languages I'm aware of integrate with the C runtime much more naturally than go is capable of. Go has its own type of stack, which means it's a pain in the ass to embed into the C runtime and it's a pain in the ass to embed the C runtime into it. > gccgo and tinygo Does anyone use these implementations? I honestly had no idea either project existed.
  - randomdata 3y ago
    > Most of the languages I'm aware of integrate with the C runtime much more naturally than go is capable of. In what way? Is it because you call `C.function_name` instead of `function_name`, the latter of which some other languages will allow? I don't see how that is a meaningful difference. Especially when Go developers are already accustomed to referencing pure Go functions in the same way. > Go has its own type of stack gc brings its own type of stack, but that's not a feature of Go. Let's not confuse an implementation with a language. Go says nothing about stack layout. > which means it's a pain in the ass to embed into the C runtime and it's a pain in the ass to embed the C runtime into it. There might be a pain in the ass for the gc maintainers, but that's not you. You will never notice or care. It is fully abstracted away. There is some overhead cost to that, but it has shrunk so dramatically over the years, you're not going to notice it anymore either. Protip: Don't use version 1.5 like the previous link is talking about. That was 17 major versions ago. > I honestly had no idea either project existed. How'd you miss gccgo, at least? It's maintained by the official Go team. It is the second compiler they always talk about – the one they use to ensure that the standard isn't defined by an implementation.
    - DinaCoder99 3y ago
      > Is it because you call `C.function_name` instead of `function_name`, the latter of which some other languages will allow? No, it's because they use completely different stacks. It has nothing to do with the aesthetics of the language. > You will never notice or care. It is fully abstracted away. I mean... aesthetically, sure. How the runtime works still matters a lot.