5 ms·
> Assembly is faster, Go isn't. Ok, let's use assembly then. That's pretty flawed logic. It can be used to dismiss any valid statement. "B is better than A at
by shurcooL 13y ago
> Assembly is faster, Go isn't. Ok, let's use assembly then.
That's pretty flawed logic. It can be used to dismiss any valid statement. "B is better than A at property C." "Z is better than B at property C; let's ignore the valid A vs B comparison."
What matters is how much better something is at a given property, how valuable that property is (to you/your tasks), and what the cost that improvement is - in the context of the big picture.
I like and use Go not because of any single aspect, but because I enjoy the entire package. It has some good parts and some weak parts (e.g., I wish the `go build import/path` command would be consistent in generating/not generating output in cwd regardless whether the target package is a command or library - that way it could be reliably used to test if a package builds without potentially generating files in cwd).
- rdtsc 13y ago> That's pretty flawed logic. Exactly. I was replying to his message and mocking his way of conduction a conversation. That should be viewed with that in mind. > "B is better than A at property C." "Z is better than B at property C; let's ignore the valid A vs B comparison." Yes. I think you probably want to direct that at gp post, not my post ;-) You also probably want to use different capitalization for properties than to entities (or at least letters from the other end of the alphabet), like say B is better than A at property x > I like and use Go not because of any single aspect, but because I enjoy the entire package Yeah Go is great I like it too!
- coldtea 13y ago>That's pretty flawed logic. To show that it was "flawed logic" was the whole purpose of his remark.
- rvirding 13y agoYes, it is flawed logic, but you were using so I don't see why you should object to it. And his goal was to show that.