4 ms·

With both approaches you have to remember some sort of mapping technique for date formatting. What I claim that Go's approach is far superior and easier to rem

by divan 4y ago

With both approaches you have to remember some sort of mapping technique for date formatting. What I claim that Go's approach is far superior and easier to remember and use. Leaving aside "oh, but we used to letters" thing, one of the problems with letters is that it's just o much stuff to remember and it only grows as you use more than one languages on a daily basis. I sometimes switch between 4 languages during the day, and this alphabet juggling goes out of hand very quickly. Like it's unusable without constantly opening documentation pages for strfime-like functions. I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement.

masklinn 4y ago
> What I claim that Go's approach is far superior and easier to remember and use. [...] I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement. The Go approach is barely "more efficient" if your only consideration is exclusively US-centric, it's outright hell everywhere else, because US date formats make even less sense than their units. Go's datetime format is gimmicky, gimpy (it's missing a good fifth of the TR35 fields, to say nothing of the field formats), inextensible, and localisation-hostiles. It's also telling that while Go made up this nonsense with date formats, they retained the significantly worse and more error prone printf formats for, well, printf, in case mixing the two might have been an option (as it is in python for instance).
- divan 4y ago
  > is exclusively US-centric It's literally not a problem at all. It's just one bit of information to remember in your head (I explained in a sibling comment how common US-style date in software, so for anyone who used computer longer than their last iPhone, it's just one bit of information - either date in US style or not). But with Go formatting it's even simpler - you literally never think about it. You just remember that it's "January 2nd" and that's it. I'm so surprised that people trying to present it as a huge problem, let alone "insane" or "bizzare".
  - masklinn 4y ago
    > It's literally not a problem at all. It's just one bit of information to remember in your head Your assertions do not make that a reality. > But with Go formatting it's even simpler - you literally never think about it. True, because you quickly learn to use something else.
    - divan 4y ago
      > Your assertions do not make that a reality What reality? I write Go almost daily for 9 years and was running Golang meetups in two countries for years. I think I have pretty good grasp of what actual problem real people have with dates in Go. Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem. This problem exists only in HN comments of people used to other approaches.
      - fsociety 4y ago
        That’s cool. I constantly get tripped up with day/month ordering. Maybe I am dumb, but it is a silly design to defend in my opinion.
        divan 4y ago
        Can you elaborate in details how exactly you tripped by this? Like, when you need to present current date so it looks like "11 December, 2022" - where your issue starts with Go's approach? Can you walk me through your thought process here? I'm genuinly curious.
      - fcarraldo 4y ago
        > Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem I mean, you literally got it wrong in this comment, so maybe it’s worth considering whether such a simple mistake might be hard to catch and thus cause real production issues?
        Smaug123 4y ago
deleted 4y ago
[deleted]
kaba0 4y ago
I mean, how often do you have to parse that part of the code? If it is everywhere, you should start writing helper functions or some other abstraction. In my opinion this is typically a very static part of code bases, it is written correctly once (where you can look at the documentation all day long) and possibly never ever looked back on.

by divan 4y ago

masklinn 4y ago

> What I claim that Go's approach is far superior and easier to remember and use. [...] I mean, I get the attachment part, but I believe that more efficient approaches should get recognition, not punishement. The Go approach is barely "more efficient" if your only consideration is exclusively US-centric, it's outright hell everywhere else, because US date formats make even less sense than their units. Go's datetime format is gimmicky, gimpy (it's missing a good fifth of the TR35 fields, to say nothing of the field formats), inextensible, and localisation-hostiles. It's also telling that while Go made up this nonsense with date formats, they retained the significantly worse and more error prone printf formats for, well, printf, in case mixing the two might have been an option (as it is in python for instance).

divan 4y ago
> is exclusively US-centric It's literally not a problem at all. It's just one bit of information to remember in your head (I explained in a sibling comment how common US-style date in software, so for anyone who used computer longer than their last iPhone, it's just one bit of information - either date in US style or not). But with Go formatting it's even simpler - you literally never think about it. You just remember that it's "January 2nd" and that's it. I'm so surprised that people trying to present it as a huge problem, let alone "insane" or "bizzare".
- masklinn 4y ago
  > It's literally not a problem at all. It's just one bit of information to remember in your head Your assertions do not make that a reality. > But with Go formatting it's even simpler - you literally never think about it. True, because you quickly learn to use something else.
  - divan 4y ago
    > Your assertions do not make that a reality What reality? I write Go almost daily for 9 years and was running Golang meetups in two countries for years. I think I have pretty good grasp of what actual problem real people have with dates in Go. Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem. This problem exists only in HN comments of people used to other approaches.
    - fsociety 4y ago
      That’s cool. I constantly get tripped up with day/month ordering. Maybe I am dumb, but it is a silly design to defend in my opinion.
      - divan 4y ago
        Can you elaborate in details how exactly you tripped by this? Like, when you need to present current date so it looks like "11 December, 2022" - where your issue starts with Go's approach? Can you walk me through your thought process here? I'm genuinly curious.
    - fcarraldo 4y ago
      > Order of day-month in mnemonic ("Jan 2nd" vs "Feb 1st") is literally not a problem I mean, you literally got it wrong in this comment, so maybe it’s worth considering whether such a simple mistake might be hard to catch and thus cause real production issues?
      - Smaug123 4y ago

deleted 4y ago

[deleted]

kaba0 4y ago

I mean, how often do you have to parse that part of the code? If it is everywhere, you should start writing helper functions or some other abstraction. In my opinion this is typically a very static part of code bases, it is written correctly once (where you can look at the documentation all day long) and possibly never ever looked back on.