3 ms·

I appreciate your dedication to reminding us that your original comment was posted without any research or thought, but it remains that the Go project itself, a

I appreciate your dedication to reminding us that your original comment was posted without any research or thought, but it remains that the Go project itself, along with other third-parties, provide different FFI solutions so that you can pick the one that best suits your circumstances. There is no one-size-fits-all solution. 99% of Go users don't need an FFI story at all. They can choose a compiler on different merits. If you have an FFI story to consider, then it is logical that you will need to evaluate your choices on different attributes and very well might find that the compiler 99% of users with different problems won't match your own. gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing. What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for?

aragilar 3y ago
But 99% (probably 100%) of scientific computing users do need FFI, hence why there's no overlap. While there may be other compilers, my impression is most Go devs, and hence most Go libraries, assume you're using the standard golang compiler, and so FFI remains a problem for expanding the Go ecosystem to specific use-cases. I'm not suggesting Go has support scientific computing (in fact, it's likely better for everyone if it doesn't), but it's likely Go will continue to be a non-entity in scientific computing landscape, absent someone throwing loads of money at a specific use-case and effectively locking people in. It's worth noting that other new languages (e.g. Rust) are being adopted, because they have an reasonable FFI story.
- randomdata 3y ago
  99% of scientific computing tasks are script in nature, so Go is not a good fit anyway. It is decidedly a systems langue, not a scripting language. Different tools for different jobs. Yes, obviously you can write scripts in a systems language, and systems in a scripting language, but you will have a better time if you write systems in systems languages, and scripts in scripting languages. There is good reason why we make a distinction between the two. The scientists are almost certainly using Python. If not Python, R or Julia. And that is in large part because these are scripting languages. It is true that amongst the 1% that are systems, Rust has found a place, but it too will never make any serious headway into the scripting realm. It is also a systems language. Different tools for different jobs.
coldtea 3y ago
>I appreciate your dedication to reminding us that your original comment was posted without any research or thought I, on the other hand, don't appreciate the ad hominem. What happened, have manners gone out of style? Also, what exactly fault do you find with my original comment: that Go isn't really a player in scientific computing. Does your "research or though" suggest otherwise? >99% of Go users don't need an FFI story at all. They can choose a compiler on different merits. Users of X don't need Y is a self-fullfilling prophecy when X doesn't offer Y. Languages without Y don't tend to attract users who need Y. We're also talking about users doing scientific computing here, where the vast majority does need an FFI story. >gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing. And gc is 99% of what people understand and use as Go - not gccgo. Unless gc has a good support for certain features, scientific computing ain't gonna happen. People aren't going to heavily invest in building scientific programming libs interop with Go, when those would just work fast enough in a different less used go compiler as opposed to the mainstream one. >What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for? Yeah, because a different version of a compiler doesn't come with different maturity, different technical tradeoffs, different community using it, different support story, and so on, it's just like "picking another item from a menu". If that's your understanding of the situation, I can see how your argument would make sense in your mind ("just change the compiler, it's easy"). Using another language as an example: If CPython didn't have a good interop story with scientific libraries, even if PyPy did, "Python" would have gone nowhere in that domain. And people who can't understand this, would talk all day getting blue in the face about how "it's not a Python problem, it's a CPython problem", as if that would change anything.
- randomdata 3y ago
  > What happened, have manners gone out of style? Manners are for engagement between people. Forum-going is a solitary activity. Maybe there is a human out there twisting nobs and pulling levers to make the software work, but if so, that's just an implementation detail hidden from the user. If that were replaced with software, I wouldn't notice, or care. > what exactly fault do you find with my original comment: that Go isn't really a player in scientific computing. The original contextual comment, not first comment ever written... > People aren't going to heavily invest in building scientific programming libs interop with Go They aren't going to invest anyway, as the vast majority of scientific computing tasks are script in nature. Go is decidedly not a scripting language. It isn't trying to be, and doesn't want to be. There were already a number of good languages in the scripting space before Go came along. This is like lamenting that wrenches aren't winning the race in nail driving dominance. Who cares?

aragilar 3y ago

But 99% (probably 100%) of scientific computing users do need FFI, hence why there's no overlap. While there may be other compilers, my impression is most Go devs, and hence most Go libraries, assume you're using the standard golang compiler, and so FFI remains a problem for expanding the Go ecosystem to specific use-cases. I'm not suggesting Go has support scientific computing (in fact, it's likely better for everyone if it doesn't), but it's likely Go will continue to be a non-entity in scientific computing landscape, absent someone throwing loads of money at a specific use-case and effectively locking people in. It's worth noting that other new languages (e.g. Rust) are being adopted, because they have an reasonable FFI story.

randomdata 3y ago
99% of scientific computing tasks are script in nature, so Go is not a good fit anyway. It is decidedly a systems langue, not a scripting language. Different tools for different jobs. Yes, obviously you can write scripts in a systems language, and systems in a scripting language, but you will have a better time if you write systems in systems languages, and scripts in scripting languages. There is good reason why we make a distinction between the two. The scientists are almost certainly using Python. If not Python, R or Julia. And that is in large part because these are scripting languages. It is true that amongst the 1% that are systems, Rust has found a place, but it too will never make any serious headway into the scripting realm. It is also a systems language. Different tools for different jobs.

coldtea 3y ago

>I appreciate your dedication to reminding us that your original comment was posted without any research or thought I, on the other hand, don't appreciate the ad hominem. What happened, have manners gone out of style? Also, what exactly fault do you find with my original comment: that Go isn't really a player in scientific computing. Does your "research or though" suggest otherwise? >99% of Go users don't need an FFI story at all. They can choose a compiler on different merits. Users of X don't need Y is a self-fullfilling prophecy when X doesn't offer Y. Languages without Y don't tend to attract users who need Y. We're also talking about users doing scientific computing here, where the vast majority does need an FFI story. >gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing. And gc is 99% of what people understand and use as Go - not gccgo. Unless gc has a good support for certain features, scientific computing ain't gonna happen. People aren't going to heavily invest in building scientific programming libs interop with Go, when those would just work fast enough in a different less used go compiler as opposed to the mainstream one. >What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for? Yeah, because a different version of a compiler doesn't come with different maturity, different technical tradeoffs, different community using it, different support story, and so on, it's just like "picking another item from a menu". If that's your understanding of the situation, I can see how your argument would make sense in your mind ("just change the compiler, it's easy"). Using another language as an example: If CPython didn't have a good interop story with scientific libraries, even if PyPy did, "Python" would have gone nowhere in that domain. And people who can't understand this, would talk all day getting blue in the face about how "it's not a Python problem, it's a CPython problem", as if that would change anything.

randomdata 3y ago
> What happened, have manners gone out of style? Manners are for engagement between people. Forum-going is a solitary activity. Maybe there is a human out there twisting nobs and pulling levers to make the software work, but if so, that's just an implementation detail hidden from the user. If that were replaced with software, I wouldn't notice, or care. > what exactly fault do you find with my original comment: that Go isn't really a player in scientific computing. The original contextual comment, not first comment ever written... > People aren't going to heavily invest in building scientific programming libs interop with Go They aren't going to invest anyway, as the vast majority of scientific computing tasks are script in nature. Go is decidedly not a scripting language. It isn't trying to be, and doesn't want to be. There were already a number of good languages in the scripting space before Go came along. This is like lamenting that wrenches aren't winning the race in nail driving dominance. Who cares?