4 ms·

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal wi

by dilap 10y ago

Nah. I like Go because the language itself is minimal yet powerful, and because the quality of engineering is extremely high. I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools; Go minimizes that. An excellent example is the handling of this bug report(§): https://github.com/golang/go/issues/12914 https://github.com/golang/go/issues/12914 which resulted in this language-change proposal: https://github.com/golang/proposal/blob/master/design/12914-monotonic.md https://github.com/golang/proposal/blob/master/design/12914-... And then these commits: https://go-review.googlesource.com/#/c/36255/ https://go-review.googlesource.com/#/c/36255/ I feel like any other language I've used would've just added a "monotonicTime" function and called it a day; the Go solution is impressive, elegant, and shows an exceedingly high level of care for the end-outcome results for the users of the language. To me, that's what makes Go special. (§After a rocky start; it took the core devs a bit to realize it was a real issue because within Google's special environment it isn't.)

Groxx 10y ago
I dunno... in some ways, the problem is that they didn't think it through to begin with, and chose something widely-known-to-be-ambiguous-and-problematic like "time.Now()", instead of choosing unambiguous names / structures from the start. It's kinda the equivalent of making a new language (nowadays) and not defining what encoding your native strings use. Of course it's going to cause problems. Except the timer issue has been around much longer than the standardization on utf-8.
- dilap 10y ago
  Fair point! And I certainly don't claim that the Go devs don't make mistakes. They started with the theory that the problem should solved as Google does, by arranging that clocks don't run backwards. When it become clear that wasn't reasonable, they moved towards a new solution in a way that I felt was impressive.
  - Groxx 10y ago
    It's mostly-impressively backwards compatible, I'll definitely agree there. It's clever, and in many cases it'll do the right thing automatically. Since it seems that's their goal, they achieved it quite elegantly, and that's a tricky thing to do. (edit: and quite quickly! seriously, this is an example of a healthy community at its best) But personally I don't agree with the decision - it adds surprises when you try to convert times to other types and then compare things. Or convert to something else and then back to a time instance. I've watched things like this become the source of bugs many, many times - this will only make that worse, since now a "time" is two values but you can really only access one of them (the one that's equivalent to wall-clock, which is causing the problems). And they're particularly painful bugs, because the cause lies in implicit conversions and behavior. That seems to run counter to the "minimal surprises" that Go seems to prioritize.
    - dilap 10y ago
      There's no denying it's at least flirting with "too clever" territory. What saves it for me is (1) the analysis of a large body of code that seemed to show only positive impact (2) that the behavior is well-documented and (3) anytime you're converting between types, you should always be thinking, "what is the range of these types? what information might get lost?", which with (2), should leave you alright. But, I could easily see looking back in 2 years and realizing you were right.
      - Groxx 10y ago
        "Should", definitely :) Easier said than done. But I'm happy to wait and see, it's not like this would make Go the only language with weird time handling. As it stands they're probably in a better place than most people are used to. That code-corpus-analysis is pretty neat, I hadn't looked through in detail before. Thanks for pointing it out! --- Sorta as an aside, it seems the proposal can lead to: t1 = time.Now() ... t2 = time.Now() diff = t2.Sub(t1) t1.Add(diff) != t2 Times are hard :|
        10y ago
jwilk 10y ago
Clever? Sure. Elegant? Hell, no. It's an ugly hack.
solipsism 10y ago
I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools Seems to be some cognitive dissonance (in the modern erroneous sense of the word) going on. This was a hack necessary because the design of the library wasn't fully thought out. Imagining the world would one day become Google is not thinking things out.
- geodel 10y ago
  > This was a hack necessary because the design of the library wasn't fully thought out. Easy to say 'not fully thought out'. It took Java from version 1.2 to 1.8 to fix its date/time library.
  - AdieuToLogic 10y ago
    It took Java from version 1.2 to 1.8 to fix its date/time library. That is incorrect[0]. When spreading FUD[1], expect assertions such as these to be fact checked by others. 0 - http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22joda-time%22%20AND%20a%3A%22joda-time%22 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22joda-time... 1 - https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
- dilap 10y ago
  It was something not in the library because it wasn't in their sphere of consideration. When that expanded, due to feedback from the outside world, they responded in an impressive way. And that's just an example that was intended to illustrative. You'll just have to take my word for it that my experience of the Go ecosystem, tools, and standard library has been more solid than the various other things I've used over the years (python, C# + unity, c++, fucking maven, boost...). If I'm missing out on something even better, let me know. ;-)

by dilap 10y ago

Groxx 10y ago

I dunno... in some ways, the problem is that they didn't think it through to begin with, and chose something widely-known-to-be-ambiguous-and-problematic like "time.Now()", instead of choosing unambiguous names / structures from the start. It's kinda the equivalent of making a new language (nowadays) and not defining what encoding your native strings use. Of course it's going to cause problems. Except the timer issue has been around much longer than the standardization on utf-8.

dilap 10y ago
Fair point! And I certainly don't claim that the Go devs don't make mistakes. They started with the theory that the problem should solved as Google does, by arranging that clocks don't run backwards. When it become clear that wasn't reasonable, they moved towards a new solution in a way that I felt was impressive.
- Groxx 10y ago
  It's mostly-impressively backwards compatible, I'll definitely agree there. It's clever, and in many cases it'll do the right thing automatically. Since it seems that's their goal, they achieved it quite elegantly, and that's a tricky thing to do. (edit: and quite quickly! seriously, this is an example of a healthy community at its best) But personally I don't agree with the decision - it adds surprises when you try to convert times to other types and then compare things. Or convert to something else and then back to a time instance. I've watched things like this become the source of bugs many, many times - this will only make that worse, since now a "time" is two values but you can really only access one of them (the one that's equivalent to wall-clock, which is causing the problems). And they're particularly painful bugs, because the cause lies in implicit conversions and behavior. That seems to run counter to the "minimal surprises" that Go seems to prioritize.
  - dilap 10y ago
    There's no denying it's at least flirting with "too clever" territory. What saves it for me is (1) the analysis of a large body of code that seemed to show only positive impact (2) that the behavior is well-documented and (3) anytime you're converting between types, you should always be thinking, "what is the range of these types? what information might get lost?", which with (2), should leave you alright. But, I could easily see looking back in 2 years and realizing you were right.
    - Groxx 10y ago
      "Should", definitely :) Easier said than done. But I'm happy to wait and see, it's not like this would make Go the only language with weird time handling. As it stands they're probably in a better place than most people are used to. That code-corpus-analysis is pretty neat, I hadn't looked through in detail before. Thanks for pointing it out! --- Sorta as an aside, it seems the proposal can lead to: t1 = time.Now() ... t2 = time.Now() diff = t2.Sub(t1) t1.Add(diff) != t2 Times are hard :|
      - 10y ago

jwilk 10y ago

Clever? Sure. Elegant? Hell, no. It's an ugly hack.

solipsism 10y ago

I am so tired of having to deal with bullshit because of poorly-thought-out and poorly-engineered tools Seems to be some cognitive dissonance (in the modern erroneous sense of the word) going on. This was a hack necessary because the design of the library wasn't fully thought out. Imagining the world would one day become Google is not thinking things out.

geodel 10y ago
> This was a hack necessary because the design of the library wasn't fully thought out. Easy to say 'not fully thought out'. It took Java from version 1.2 to 1.8 to fix its date/time library.
- AdieuToLogic 10y ago
  It took Java from version 1.2 to 1.8 to fix its date/time library. That is incorrect[0]. When spreading FUD[1], expect assertions such as these to be fact checked by others. 0 - http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22joda-time%22%20AND%20a%3A%22joda-time%22 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22joda-time... 1 - https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
dilap 10y ago
It was something not in the library because it wasn't in their sphere of consideration. When that expanded, due to feedback from the outside world, they responded in an impressive way. And that's just an example that was intended to illustrative. You'll just have to take my word for it that my experience of the Go ecosystem, tools, and standard library has been more solid than the various other things I've used over the years (python, C# + unity, c++, fucking maven, boost...). If I'm missing out on something even better, let me know. ;-)