3 ms·

> 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 integr

> 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.
  - randomdata 3y ago
    > 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.

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.
- randomdata 3y ago
  > 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.