8 ms·

> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual

by divan 4y ago

> Years and years of discussions about Go's poor and verbose error handling ...with majority of users saying that it's actually great and simple, unlike "usual" approaches... > Many "features" of Go are borderline insane ...which start make sense as long as you use them and put some thought behind the reasons of the design, instead of sticking to "what I used to is the only right way" mentality... > (date formatting) Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages. Without knowing the language, guess what will be printed by "15:04 Jan 2 2006" and by "MM:ss mmm D YYYY"? > were recognized as mistakes decades ago (nil pointers) ...by popular urban myth and people who love reductions of the complex ideas into simple black-and-white statements... It's funny how people can believe that great compiler, an amazing standard library, and high-quality official tooling can be a result of a bad design :) Good luck in spending so much energy in communicating your lack of intent to understand Go design from fundamental principles instead of comparing to the mainstream languages.

Smaug123 4y ago
The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time https://pkg.go.dev/time: > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it even remotely memorable that the canonical order is month, day, hour, minute, second, year, timezone? That decision is just… really bad!)
- divan 4y ago
  This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?
  - Smaug123 4y ago
    Do you have a source for that statement? (For all I know, you are a member of the team who wrote it, so you may know what it means! I certainly had nothing to do with its writing.) To me, the statement is obviously saying "yeah this order is just bizarre, why on earth did we put the two most significant digits around the outside of the rest, good luck".
    - divan 4y ago
      I'm not a member of a Go team. I can comment though as a non-US citizen. This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar. Like most of the software historically was born in US, and it's just a very common case where localization is not respected and you see american style dates every now and then. It's getting better, but still, not unusual. While it's different from european, it's definitely not "insane" and not "bizzare". Why would anyone even claim that?
      - OtomotO 4y ago
        It's not common in any software I've written or touched in my entire career.
        divan 4y ago
        Well, maybe subset of software you written or touched is much smaller than the whole set of software billions of other people wrote or touched.
        OtomotO 4y ago
        Oh, without a doubt. What I mean though: the US isn't the world, even though many people think it is. And the US date format is among the weirdest I ever encountered. Super happy I never had to support it. It was enough to support over a dozen different formats at one customer at one point.
      - lelanthran 4y ago
- 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".
      - 4y ago
p-e-w 4y ago
Well, the proof is in the pudding, and the pudding has spoken and found Go wanting, compared to its most direct competitor, Rust. Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much less popular.
- curling_grad 4y ago
  Isn't Go more positioned as a language for web services, rather than systems programming?
- zanderwohl 4y ago
  It's true... Go was supposed to be great for mission-critical stuff but the issues pop up quickly. I've seen several cases where someone migrates a Go service to Rust and like a bad dream the major problems disappear.
- Thaxll 4y ago
  And yet Go is much more popular than Rust.
  - shakow 4y ago
    And PHP is more popular than both of them, so it's not tomorrow that gauging the qualities of a language on the use the vulgum pecus makes of it will be a good idea.
  - Smaug123 4y ago
    … is it? For example, the Stack Overflow survey says Rust was loved by 86% of its users, while Go by 64%. Rust also beat Go on the percentage of respondents who wanted to use it. (But Golang was used by 2% more respondents than Rust, at 11.15% vs 9.32%.) https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages https://survey.stackoverflow.co/2022/#section-most-loved-dre...
masklinn 4y ago
> Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages. Very much so. The latter is at least portable between cultures, because a month is a month, unlike "1". And then of course you've got all the collisions like weekday (which for some reason does not follow the US standard either) or yearday, the ambiguities (like sub-seconds which can be either 0 or 9), and the outright missing fields (week numbers? week-years? No comprendo, señor..)
- divan 4y ago
  Very much so? Let's put it to the pragmatic challenge. What will be the output of Go's "Jan 2006" and of R's "%B %h %M" format strings? Don't google.
  - deleted 4y ago
    [deleted]
  - masklinn 4y ago
    “Jan 2006” and short month, short month, minutes?
    - divan 4y ago
      To be clear "Jan 2006" - is a format string. Current date would yield "Dec 2022", obviously. R example - it's "Long month, hour, decimal minute", so something like "December 15 35" So you got Go format style right, and alphabet-style wrong. But Go's format is worse, right?
shakow 4y ago
> which start make sense as long as you use them and put some thought behind the reasons of the design Hard disagree. I have been using Go at my company for years, and these features still make no sense to me. > lack of enums Not even talking about the eyesore that is the magical const/iota combination (oh yes, your constant definition are scope-dependent, remember to never screw up a copy/paste), go enums are basically C #define. And I think that the consensus has been, for decades, that having badly typed magical constants was not a good thing. > implicit interfaces Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. > by popular urban myth Tell me exactly who finds that nil pointers are a great thing in a high-level language?
- cube2222 4y ago
  > And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". In general, implicit interfaces let structures and functions require much less by defining their needed functionality subset, instead of requiring the whole "domain interface" from somewhere else. If you have a struct that only needs to list an S3 bucket, it's nice to accept an interface that only requires listing, and not the other 30 methods the AWS library "full" interface has. This makes understanding what a piece of code is doing much easier, while simplifying mocking as well. I do agree that enums, or even better, sum types, would be desirable. It's not a big issue in my day to day, though.
  - 4y ago
rmrfchik 4y ago
I thought it was a joke about mnemonic, until realized you're serious. This is NOT a mnemonic, because it lacks either rule like each next component gives more specific time, or external reference like poem or image. It can be easily substituted with 1st year, 2nd day, 3rd hour, 4th minute, 5th second, 6-th month, 7th timezone.
- divan 4y ago
  mnemonic is just a memory aid, it can be anything. if you prefer other term, feel free to use it, but the point still holds - it's a 1234567-based date that you remember once (most people can do it) and it helps remembering what should be in the format string.
  - rmrfchik 4y ago
    What is 1234567 anyway? Why 1 is month? From which clue should I remember that?
    - masklinn 4y ago
      From the cultural assimilation of being american for which it makes perfect sense that the month comes first and the year comes last. Apparently. That’s also why the timezone is a weird-ass US timezone (MST, Mountain Standard Time), and why you don’t get tzdata timezone names. But don’t rely too much on cultural assimilation, because DOW is not the Sunday / 0 you might then expect.
fcarraldo 4y ago
There is an ISO standard for date formatting. Go ignores it, which makes interop problematic. We do get RFC3339 support, as well as a few others, but if ISO dates are being used in data being read by a Go program it’s a huge headache to ensure it will be correct using the standard library. There’s no real debate here, it was a design mistake and admitted as such.
- divan 4y ago
  Why inventing things instead of googling them? Here, why ISO 8601 support was dropped (spoiler: it's an unparsable mess) https://github.com/golang/go/issues/734 https://github.com/golang/go/issues/734 Design mistake )))
saturn_vk 4y ago
> (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) Who was the bright spark that decided they the month of all things should go in first? This format makes almost as much sense as Sunday being the first day of the week
- masklinn 4y ago
  Well it’s Americans in both cases so… there you go. Also funnily enough Go does not use the field 0 for DOW, instead it uses 1 (Monday). Which makes no sense at any level, because it uses 2 for both month-day and year-day, but apparently week-day is not a day (and you can’t get the numerical week-day anyway, because who needs that).

by divan 4y ago

Smaug123 4y ago

The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote https://pkg.go.dev/time https://pkg.go.dev/time: > It is a regrettable historic error that the date uses the American convention of putting the numerical month before the day. Such a "historic error" is literally impossible if you use the "MMddyyyy crap": it's always clear from context what format is in use. (I mean, in what world is it even remotely memorable that the canonical order is month, day, hour, minute, second, year, timezone? That decision is just… really bad!)

divan 4y ago
This clause is just about slight inconvenience for non-US citizens to remember the order of month and day, and not about not using letter-mapping approach, which in some languages is using the whole alphabet. Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?
- Smaug123 4y ago
  Do you have a source for that statement? (For all I know, you are a member of the team who wrote it, so you may know what it means! I certainly had nothing to do with its writing.) To me, the statement is obviously saying "yeah this order is just bizarre, why on earth did we put the two most significant digits around the outside of the rest, good luck".
  - divan 4y ago
    I'm not a member of a Go team. I can comment though as a non-US citizen. This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar. Like most of the software historically was born in US, and it's just a very common case where localization is not respected and you see american style dates every now and then. It's getting better, but still, not unusual. While it's different from european, it's definitely not "insane" and not "bizzare". Why would anyone even claim that?
    - OtomotO 4y ago
      It's not common in any software I've written or touched in my entire career.
      - divan 4y ago
        Well, maybe subset of software you written or touched is much smaller than the whole set of software billions of other people wrote or touched.
        OtomotO 4y ago
        Oh, without a doubt. What I mean though: the US isn't the world, even though many people think it is. And the US date format is among the weirdest I ever encountered. Super happy I never had to support it. It was enough to support over a dozen different formats at one customer at one point.
    - lelanthran 4y ago
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".
    - 4y ago

p-e-w 4y ago

Well, the proof is in the pudding, and the pudding has spoken and found Go wanting, compared to its most direct competitor, Rust. Even though Go appeared earlier than Rust, and Go's creators are much more famous than Rust's, and the corporation behind Go is much more influential than that behind Rust, adoption of Rust is skyrocketing for mission critical systems while (apart from the container ecosystem) Go is much less popular.

curling_grad 4y ago
Isn't Go more positioned as a language for web services, rather than systems programming?
zanderwohl 4y ago
It's true... Go was supposed to be great for mission-critical stuff but the issues pop up quickly. I've seen several cases where someone migrates a Go service to Rust and like a bad dream the major problems disappear.
Thaxll 4y ago
And yet Go is much more popular than Rust.
- shakow 4y ago
  And PHP is more popular than both of them, so it's not tomorrow that gauging the qualities of a language on the use the vulgum pecus makes of it will be a good idea.
- Smaug123 4y ago
  … is it? For example, the Stack Overflow survey says Rust was loved by 86% of its users, while Go by 64%. Rust also beat Go on the percentage of respondents who wanted to use it. (But Golang was used by 2% more respondents than Rust, at 11.15% vs 9.32%.) https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages https://survey.stackoverflow.co/2022/#section-most-loved-dre...

masklinn 4y ago

> Of course, mnemonics 1-2-3-4-5-6-7 (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) is harder to remember than mmHHMMssSSYYyy crap that is different in different languages. Very much so. The latter is at least portable between cultures, because a month is a month, unlike "1". And then of course you've got all the collisions like weekday (which for some reason does not follow the US standard either) or yearday, the ambiguities (like sub-seconds which can be either 0 or 9), and the outright missing fields (week numbers? week-years? No comprendo, señor..)

divan 4y ago
Very much so? Let's put it to the pragmatic challenge. What will be the output of Go's "Jan 2006" and of R's "%B %h %M" format strings? Don't google.
- deleted 4y ago
  [deleted]
- masklinn 4y ago
  “Jan 2006” and short month, short month, minutes?
  - divan 4y ago
    To be clear "Jan 2006" - is a format string. Current date would yield "Dec 2022", obviously. R example - it's "Long month, hour, decimal minute", so something like "December 15 35" So you got Go format style right, and alphabet-style wrong. But Go's format is worse, right?

shakow 4y ago

> which start make sense as long as you use them and put some thought behind the reasons of the design Hard disagree. I have been using Go at my company for years, and these features still make no sense to me. > lack of enums Not even talking about the eyesore that is the magical const/iota combination (oh yes, your constant definition are scope-dependent, remember to never screw up a copy/paste), go enums are basically C #define. And I think that the consensus has been, for decades, that having badly typed magical constants was not a good thing. > implicit interfaces Implicit interfaces are OK when you want to cow-boy your way through through prototyping. When I go back to your code 3 years later, it's a huge obstacle. OK, so you have this function that takes a FooBar. Oh, FooBar is an interface. Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. > by popular urban myth Tell me exactly who finds that nil pointers are a great thing in a high-level language?

cube2222 4y ago
> And God forbid I needed to extend this interface and missed to add the new method to one of the 32 types implementing it, so that it blows on my face in prod at 3AM. The language has static type-checking. If to you it's a regular thing that something like this blows up in your face, maybe it's the code base doing too many things dynamically, and not the language? > Great, now I'll have to pull a rickety 3rd-package or ‶just grep bro″ through the whole code base to find what types implement this interface. Or just use any of the popular Go code editors/plugins which give you a "show me all implementations". In general, implicit interfaces let structures and functions require much less by defining their needed functionality subset, instead of requiring the whole "domain interface" from somewhere else. If you have a struct that only needs to list an S3 bucket, it's nice to accept an interface that only requires listing, and not the other 30 methods the AWS library "full" interface has. This makes understanding what a piece of code is doing much easier, while simplifying mocking as well. I do agree that enums, or even better, sum types, would be desirable. It's not a big issue in my day to day, though.
- 4y ago

rmrfchik 4y ago

I thought it was a joke about mnemonic, until realized you're serious. This is NOT a mnemonic, because it lacks either rule like each next component gives more specific time, or external reference like poem or image. It can be easily substituted with 1st year, 2nd day, 3rd hour, 4th minute, 5th second, 6-th month, 7th timezone.

divan 4y ago
mnemonic is just a memory aid, it can be anything. if you prefer other term, feel free to use it, but the point still holds - it's a 1234567-based date that you remember once (most people can do it) and it helps remembering what should be in the format string.
- rmrfchik 4y ago
  What is 1234567 anyway? Why 1 is month? From which clue should I remember that?
  - masklinn 4y ago
    From the cultural assimilation of being american for which it makes perfect sense that the month comes first and the year comes last. Apparently. That’s also why the timezone is a weird-ass US timezone (MST, Mountain Standard Time), and why you don’t get tzdata timezone names. But don’t rely too much on cultural assimilation, because DOW is not the Sunday / 0 you might then expect.

fcarraldo 4y ago

There is an ISO standard for date formatting. Go ignores it, which makes interop problematic. We do get RFC3339 support, as well as a few others, but if ISO dates are being used in data being read by a Go program it’s a huge headache to ensure it will be correct using the standard library. There’s no real debate here, it was a design mistake and admitted as such.

divan 4y ago
Why inventing things instead of googling them? Here, why ISO 8601 support was dropped (spoiler: it's an unparsable mess) https://github.com/golang/go/issues/734 https://github.com/golang/go/issues/734 Design mistake )))

saturn_vk 4y ago

> (1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6-th year, 7th timezone) Who was the bright spark that decided they the month of all things should go in first? This format makes almost as much sense as Sunday being the first day of the week

masklinn 4y ago
Well it’s Americans in both cases so… there you go. Also funnily enough Go does not use the field 0 for DOW, instead it uses 1 (Monday). Which makes no sense at any level, because it uses 2 for both month-day and year-day, but apparently week-day is not a day (and you can’t get the numerical week-day anyway, because who needs that).