7 ms·

Comparing apples and oranges. Java and C# are verbose because of libraries and frameworks in the ecosystem not because the languages are inherently flawed. Not

Comparing apples and oranges. Java and C# are verbose because of libraries and frameworks in the ecosystem not because the languages are inherently flawed. Not sure what your point about the runtimes is? We shouldn't use or build highly optimized runtimes? Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?

bogomipz 8y ago
>"Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?" Could you elaborate on what the shortcomings of the original runtime were? Might you have any link regarding this? Thanks.
- weberc2 8y ago
  I think he's remarking about how the first version of anything is almost always suboptimal compared to later versions. I.e., it "sucked" compared to later versions, almost by definition.
- jerf 8y ago
  The original runtime had far, far worse GC pauses. They concentrated on making sure they could make a good one later rather than getting a perfect one out the door immediately. There was also a series of crashing bugs of varying severity in the first couple of versions. Even then you had to go a bit out of your way to find one, but they're a lot harder to come by now. Nothing that surprising, really. If you look at Go's release note history: https://golang.org/doc/devel/release.html https://golang.org/doc/devel/release.html look towards the first few releases for the bugs they mention. For instance, here's a 1.1 fix: https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b57d741ed00f0b0cd https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b... One of the advantages of not mutating the language too much is that there aren't very many things like this in the last few releases. I would expect the first 2.0 release to have a few rough edges even in the first non-beta release.
weberc2 8y ago
You're conflating "optimized" with "optimizing". The observation is that Java and C# depend on a _very_ sophisticated runtime (including a JIT compiler) to perform comparably to Go which has a comparably simple runtime. I don't know that the point is a strong one; I'm just trying to clarify the conversation.
- pjmlp 8y ago
  You mean outperforming Go, actually. https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query https://www.techempower.com/benchmarks/#section=data-r17&hw=...
  - hu3 8y ago
    Not to contradict your point but be careful on putting too much weight on microbenchmarks for they are implementation sensitive. For example, here you can see Go on par, if not faster, than other stacks: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=... I consider a good number of modern platforms fast enough for most uses. When tight requirements arise, which is rare, I resort to PoC implementations rather than microbenchmarks. There's a lot to more to consider than raw performance.
  - weberc2 8y ago
    I don't, actually. One microbenchmark isn't conclusive (never mind that Go is outperforming C# according to The Fine Microbenchmark).
    - pjmlp 8y ago
      Go looses against Java in all of them, which was also mentioned by you. And there are plenty of variations to chose from.
      - stcredzero 8y ago
        https://www.quora.com/Is-he-looses-an-arrow-grammatically-correct https://www.quora.com/Is-he-looses-an-arrow-grammatically-co...

bogomipz 8y ago

>"Go's original runtime sucked and there's been a lot of work put into making it better too, I guess they should have just stuck with it?" Could you elaborate on what the shortcomings of the original runtime were? Might you have any link regarding this? Thanks.

weberc2 8y ago
I think he's remarking about how the first version of anything is almost always suboptimal compared to later versions. I.e., it "sucked" compared to later versions, almost by definition.
jerf 8y ago
The original runtime had far, far worse GC pauses. They concentrated on making sure they could make a good one later rather than getting a perfect one out the door immediately. There was also a series of crashing bugs of varying severity in the first couple of versions. Even then you had to go a bit out of your way to find one, but they're a lot harder to come by now. Nothing that surprising, really. If you look at Go's release note history: https://golang.org/doc/devel/release.html https://golang.org/doc/devel/release.html look towards the first few releases for the bugs they mention. For instance, here's a 1.1 fix: https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b57d741ed00f0b0cd https://github.com/golang/go/commit/d72c550f1c7e13c323f4507b... One of the advantages of not mutating the language too much is that there aren't very many things like this in the last few releases. I would expect the first 2.0 release to have a few rough edges even in the first non-beta release.

weberc2 8y ago

You're conflating "optimized" with "optimizing". The observation is that Java and C# depend on a _very_ sophisticated runtime (including a JIT compiler) to perform comparably to Go which has a comparably simple runtime. I don't know that the point is a strong one; I'm just trying to clarify the conversation.

pjmlp 8y ago
You mean outperforming Go, actually. https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=query https://www.techempower.com/benchmarks/#section=data-r17&hw=...
- hu3 8y ago
  Not to contradict your point but be careful on putting too much weight on microbenchmarks for they are implementation sensitive. For example, here you can see Go on par, if not faster, than other stacks: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r17&hw=... I consider a good number of modern platforms fast enough for most uses. When tight requirements arise, which is rare, I resort to PoC implementations rather than microbenchmarks. There's a lot to more to consider than raw performance.
- weberc2 8y ago
  I don't, actually. One microbenchmark isn't conclusive (never mind that Go is outperforming C# according to The Fine Microbenchmark).
  - pjmlp 8y ago
    Go looses against Java in all of them, which was also mentioned by you. And there are plenty of variations to chose from.
    - stcredzero 8y ago
      https://www.quora.com/Is-he-looses-an-arrow-grammatically-correct https://www.quora.com/Is-he-looses-an-arrow-grammatically-co...