A "specific compiler implementation issue" when said compiler is the compiler that 99% of Go users use, can just as well be called a Go issue.
Whether "the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler" is basically irrelevant in praxtice, since people using/interested in Go predominantly mean and use a specific compiler (unlike with C++ where they might use one of several available compilers equally likely).
>To equate gc and Go as being one and the same would be quite faulty.
No, it would be the most pragmatic thing to do. De jure and de facto and all that.
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?
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.
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.
>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.
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?
Obviously? Not of the above rings obvious to me.
A "specific compiler implementation issue" when said compiler is the compiler that 99% of Go users use, can just as well be called a Go issue.
Whether "the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler" is basically irrelevant in praxtice, since people using/interested in Go predominantly mean and use a specific compiler (unlike with C++ where they might use one of several available compilers equally likely).
>To equate gc and Go as being one and the same would be quite faulty.
No, it would be the most pragmatic thing to do. De jure and de facto and all that.