The standard of evidence is what I see when I use the language at work. And so far, I don't see much that validates the golang designers' claims to be honest.
> One point would be Go's faster compile times
I'm looking for more substantive points, as frankly, this doesn't cut it. I just posted this in a different comment on this thread:
> Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well).
I worked at an employer that heavily uses golang, and I'll tell you that build times for actual large scale projects (pulling many dependencies) were not much better (if at all) than Java's.
> The standard of evidence is what I see when I use the language at work. And so far, I don't see much that validates the golang designers' claims to be honest.
Either we're talking past each other or you're being deliberately obtuse.
The claim is that Go was designed to be a language in service to software engineering, for programming in the large. The evidence for this claim is that the designers claim it, that's totally sufficient. The fact that your experience of the language doesn't sync with this claim is irrelevant, because it has no bearing on the design of the thing. If you want to claim that the designers have failed at this goal, that's a totally separate argument.
> The evidence for this claim is that the designers claim it, that's totally sufficient
My argument is exactly that, their claim is unsubstantiated, and people's experiences in practice contradict their claims. Not to mention that some of their design decisions are objectively bad, and go against their claim in the first place: https://github.com/golang/go/issues/16474
If I say I designed X with principal Y in mind, that claim cannot be contradicted or considered unsubstantiated by other people's experience of using X. It's a statement of intent, not of consequence.
> Not to mention that some of their design decisions are objectively bad
Oh, you're just grinding axes. I'm sorry for engaging.
I'd say you weren't exactly engaging in good faith, either. It's pretty clear that their point could be summarised as something like: Go's designers tried or intended to design the language for programming in the large, but they failed (perhaps partially), so therefore Go isn't (after the fact) designed for programming in the large.
You can argue about whether they really failed or not, but your pedantic take on it wasn't helpful for a discussion.
> One point would be Go's faster compile times
I'm looking for more substantive points, as frankly, this doesn't cut it. I just posted this in a different comment on this thread:
> Not much faster than C# or Java in practice, especially when using a build system that caches your build so you don't have to rebuild everything every time. The difference actually gets smaller the larger the program is. Furthermore, it's (unit/functional/integration) tests that usually take the longer time to run anyway, which you have to execute before submitting your diffs (and caching helps there as well).
I worked at an employer that heavily uses golang, and I'll tell you that build times for actual large scale projects (pulling many dependencies) were not much better (if at all) than Java's.