6 ms·

[flagged]

blibble 1y ago
> Golang makes it easy to do the dumb, wrong, incorrect thing that looks like it works 99.7% of the time. How can that be wrong? It works in almost all cases! my favorite example of this was the go authors refusing to add monotonic time into the standard library because they confidently misunderstood its necessity (presumably because clocks at google don't ever step) then after some huge outages (due to leap seconds) they finally added it now the libraries are a complete a mess because the original clock/time abstractions weren't built with the concept of multiple clocks and every go program written is littered with terrible bugs due to use of the wrong clock https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914 (https://github.com/golang/go/issues/12914#issuecomment-150754067 https://github.com/golang/go/issues/12914#issuecomment-15075... might qualify for the worst comment ever)
- 0cf8612b2e1e 1y ago
  This issue is probably my favorite Goism. Real issue identified and the feedback is, “You shouldn’t run hardware that way. Run servers like Google does without time jumping.” Similar with the original stance to code versioning. Just run a monorepo!
jen20 1y ago
I can count on fewer hands the number of times I've been bitten by such things in over 10 years of professional Go vs bitten just in the last three weeks by half-assed Java.
- deleted 1y ago
  [deleted]
- gf000 1y ago
  There is a lot to say about Java, but the libraries (both standard lib and popular third-party ones) are goddamn battle-hardened, so I have a hard time believing your claim.
  - jen20 1y ago
    You can believe what you like, of course, but "battle tested" does not mean "isn't easy to abuse".
  - p2detar 1y ago
    They might very well be, because time-handling in Java almost always sucked. In the beginning there was java.util.Date and it was very poorly designed. Sun tried to fix that with java.util.Calendar. That worked for a while but it was still cumbersome, Calendar.getInstance() anyone? After that someone sat down and wrote Joda-Time, which was really really cool and IMO the basis of JSR-310 and the new java.time API. So you're kind of right, but it only took them 15 years to make it right.
    - gf000 1y ago
      At the time of Date's "reign", were there any other language with a better library? And Calendar is not a replacement for Date so it's a bit out of the picture. Joda time is an excellent library and indeed it was basically the basis for java's time API, and.. for pretty much any modern language's time API, but given the history - Java basically always had the best time library available at the time.
      - p2detar 1y ago
        I’m sorry but I do not agree at all. That “reign” continued forever if you count when java.time got introduced and no, Calendar was not much better in the mean time. Python already had datetime in 2002 or 2003 and VB6 was miles ahead back when Java had just util.Date.
  - tom_m 1y ago
    ROFL really?
- stouset 1y ago
  Is golang better than Java? Sure, fine, maybe. I'm not a Java expert so I don't have a dog in the race. Should and could golang have been so much better than it is? Would golang have been better if Pike and co. had considered use-cases outside of Google, or looked outward for inspiration even just a little? Unambiguously yes, and none of the changes would have needed it to sacrifice its priorities of language simplicity, compilation speed, etc. It is absolutely okay to feel that go is a better language than some of its predecessors while at the same time being utterly frustrated at the the very low-hanging, comparatively obvious, missed opportunities for it to have been drastically better.
0x696C6961 1y ago
[flagged]
- jack_h 1y ago
  It’s not about making zero mistakes, it’s about learning from previous languages which made mistakes and not repeating them. I decided against using go pretty early on because I recognized just how many mistakes they were repeating that would end up haunting maintainers.
  - 0x696C6961 1y ago
    [flagged]
    - achierius 1y ago
      This isn't an issue of intelligence, and GP didn't imply that it was.
      - 0x696C6961 1y ago
        They very much did imply that.
yehyehboi 1y ago
[flagged]

[flagged]

> Golang makes it easy to do the dumb, wrong, incorrect thing that looks like it works 99.7% of the time. How can that be wrong? It works in almost all cases! my favorite example of this was the go authors refusing to add monotonic time into the standard library because they confidently misunderstood its necessity (presumably because clocks at google don't ever step) then after some huge outages (due to leap seconds) they finally added it now the libraries are a complete a mess because the original clock/time abstractions weren't built with the concept of multiple clocks and every go program written is littered with terrible bugs due to use of the wrong clock https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914 (https://github.com/golang/go/issues/12914#issuecomment-150754067 https://github.com/golang/go/issues/12914#issuecomment-15075... might qualify for the worst comment ever)

0cf8612b2e1e 1y ago
This issue is probably my favorite Goism. Real issue identified and the feedback is, “You shouldn’t run hardware that way. Run servers like Google does without time jumping.” Similar with the original stance to code versioning. Just run a monorepo!

jen20 1y ago

I can count on fewer hands the number of times I've been bitten by such things in over 10 years of professional Go vs bitten just in the last three weeks by half-assed Java.

deleted 1y ago
[deleted]
gf000 1y ago
There is a lot to say about Java, but the libraries (both standard lib and popular third-party ones) are goddamn battle-hardened, so I have a hard time believing your claim.
- jen20 1y ago
  You can believe what you like, of course, but "battle tested" does not mean "isn't easy to abuse".
- p2detar 1y ago
  They might very well be, because time-handling in Java almost always sucked. In the beginning there was java.util.Date and it was very poorly designed. Sun tried to fix that with java.util.Calendar. That worked for a while but it was still cumbersome, Calendar.getInstance() anyone? After that someone sat down and wrote Joda-Time, which was really really cool and IMO the basis of JSR-310 and the new java.time API. So you're kind of right, but it only took them 15 years to make it right.
  - gf000 1y ago
    At the time of Date's "reign", were there any other language with a better library? And Calendar is not a replacement for Date so it's a bit out of the picture. Joda time is an excellent library and indeed it was basically the basis for java's time API, and.. for pretty much any modern language's time API, but given the history - Java basically always had the best time library available at the time.
    - p2detar 1y ago
      I’m sorry but I do not agree at all. That “reign” continued forever if you count when java.time got introduced and no, Calendar was not much better in the mean time. Python already had datetime in 2002 or 2003 and VB6 was miles ahead back when Java had just util.Date.
- tom_m 1y ago
  ROFL really?
stouset 1y ago
Is golang better than Java? Sure, fine, maybe. I'm not a Java expert so I don't have a dog in the race. Should and could golang have been so much better than it is? Would golang have been better if Pike and co. had considered use-cases outside of Google, or looked outward for inspiration even just a little? Unambiguously yes, and none of the changes would have needed it to sacrifice its priorities of language simplicity, compilation speed, etc. It is absolutely okay to feel that go is a better language than some of its predecessors while at the same time being utterly frustrated at the the very low-hanging, comparatively obvious, missed opportunities for it to have been drastically better.

0x696C6961 1y ago

[flagged]

jack_h 1y ago
It’s not about making zero mistakes, it’s about learning from previous languages which made mistakes and not repeating them. I decided against using go pretty early on because I recognized just how many mistakes they were repeating that would end up haunting maintainers.
- 0x696C6961 1y ago
  [flagged]
  - achierius 1y ago
    This isn't an issue of intelligence, and GP didn't imply that it was.
    - 0x696C6961 1y ago
      They very much did imply that.

yehyehboi 1y ago

[flagged]