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?
> 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.
> 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.
> it's because they use completely different stacks.
1. Again, that's implementation dependent, not a constraint of Go. The language says absolutely nothing about stacks. tinygo, for instance, uses a C stack.
2. Even in the case of gc, where the stack is unusual, it doesn't really matter. Once upon a time there was some meaningful latency introduced because of it, but that's not true anymore.
What is still something to think about, albeit unrelated to the stack, is if you want to statically link a cross-compiled C library. Cross-compiling C programs a really hard problem. Of course, that is a hard problem no matter what. It is no less easy to cross-compile a C library for a Python program, but the static linking adds an additional complication.
But, at the same time, you don't have to statically link libraries. You can opt to dynamically load libraries, thereby having no cross-compilation issues (assuming the shared library is already compiled for your target platform). This is how most of those other languages we've talked about are doing it to get around the linking challenges where cross-platform execution is pertinent. You can do the same in Go. Go binaries normally being statically linked end-to-end is generally considered a nice feature, but if you're willing to accept dynamic linking in another language...
Naturally, if you never build for systems outside of the system you are using, that's moot. Compiling and linking a C target that matches the platform it is being performed on is easy.
> How the runtime works still matters a lot.
Not really. Anything that might matter is abstracted away – at least to the same extent as other languages. Not your problem.
Interfacing with C is a first-class feature of Go. I don't know where you got the idea that it isn't. There are a lot of good reasons to keep all of your code in the same language (true of Go and every other language in existence), but it is hardly the end of the world if you have a solid reason to turn elsewhere.
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?