2 ms·

I'm in agreement, but it's even simpler than you're making it. If Go is slow in a certain context, I would want to know what that context is. If there's a cert

I'm in agreement, but it's even simpler than you're making it. If Go is slow in a certain context, I would want to know what that context is. If there's a certain task that takes a few more ms in goroutines due to some implementation detail, I would know not to use Go if that task needed to be 100,000 times. Perhaps I need to rethink the task itself, or maybe that's not possible for an organizational reason. It wouldn't be a "random internet benchmark" unless I didn't understand the context. What's random is saying this >It seems C# suffers the same problem as real-world benchmarks often show it to be slower than Go when performing FFI, even if it should be theoretically faster How is this better than asking for code examples?

randomdata 2y ago
> If Go is slow in a certain context, I would want to know what that context is. You'll know as soon as you measure it. Not exactly rocket science, just plain old engineering. Measuring is what engineers do. You wouldn't build a bridge without first measuring the properties of the materials, and you wouldn't build a program without measuring the properties of its 'materials'. You make a good point that it is strange we don't get better datasheets from 'material manufacturers' about the base measurements. That wouldn't fly in any other engineering discipline, but I guess that's the nature of software still being young. As unfortunate as that may be, you can't fight the state of affairs, you're just going to have to roll up your sleeves. Such is life. > How is this better than asking for code examples? Cunningham's law explains why it is better.
- Capricorn2481 2y ago
  > Cunningham's law explains why it is better. That's better for YOU if you are trying to get answers, but for me the reader, you made up something about C# in the hopes of being corrected, and then lectured people asking for receipts.
  - randomdata 2y ago
    > That's better for YOU if you are trying to get answers Indeed. No sense in breaking the law. > but for me the reader I bet they wrote a song about you – or at least, as the song goes, so you think. > you made up something about C# in the hopes of being corrected It wasn't made up. The FFI benchmarks I looked at truly did show that. I did not verify exactly what was the cause for the slowness, though – and I clearly maintained the doubt in the original comment in recognition of that. Speculation isn't quite the same as what you are postulating. Nice execution of Cunningham's law, by the way. Now you're getting it. Welcome to the internet! You're going to like it here.

randomdata 2y ago

> If Go is slow in a certain context, I would want to know what that context is. You'll know as soon as you measure it. Not exactly rocket science, just plain old engineering. Measuring is what engineers do. You wouldn't build a bridge without first measuring the properties of the materials, and you wouldn't build a program without measuring the properties of its 'materials'. You make a good point that it is strange we don't get better datasheets from 'material manufacturers' about the base measurements. That wouldn't fly in any other engineering discipline, but I guess that's the nature of software still being young. As unfortunate as that may be, you can't fight the state of affairs, you're just going to have to roll up your sleeves. Such is life. > How is this better than asking for code examples? Cunningham's law explains why it is better.

Capricorn2481 2y ago
> Cunningham's law explains why it is better. That's better for YOU if you are trying to get answers, but for me the reader, you made up something about C# in the hopes of being corrected, and then lectured people asking for receipts.
- randomdata 2y ago
  > That's better for YOU if you are trying to get answers Indeed. No sense in breaking the law. > but for me the reader I bet they wrote a song about you – or at least, as the song goes, so you think. > you made up something about C# in the hopes of being corrected It wasn't made up. The FFI benchmarks I looked at truly did show that. I did not verify exactly what was the cause for the slowness, though – and I clearly maintained the doubt in the original comment in recognition of that. Speculation isn't quite the same as what you are postulating. Nice execution of Cunningham's law, by the way. Now you're getting it. Welcome to the internet! You're going to like it here.