Hacker News Reader

Comment by divan | Hacker News Reader

> 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.

View on HN

> 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?

> 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.

> Or just use any of the popular Go code editors/plugins which give you a "show me all implementations".

And me thinking the Go culture is against languages that tend to come with IDEs...

You don't need an IDE to do that. More or les anything that can hook up with the Go language server will do the job.

So somehow needing a language server to work around language design flaws is alright for Go then.

Sarcasm aside, I do think it’s fair to assume that someone writing code in a modern programming language in 2022 has access to basic language-aware editor tooling. That’s the beauty of the language server. You can look up the implementations of an interface from vim, or some other minimalist development environment, if that’s your bag.

"Go is so simple you don't need an IDE to write it, unlike java"

"Well obviously you need a proper IDE to protect you from Go's fuckups"

Cool.

You don’t need an IDE, as I explained in my two preceding posts in this thread. Please at least try to respond to someone who is actually making the arguments that you take yourself to be refuting.

Go culture, like any other, is diverse.

I prefer to use an editor/IDE and don't think it's pleasant to work with any language (including Go) without them.

Not to mention how slow it becomes in large projects

> The language has static type-checking.

No it does not, at least not completely. When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time.

> Or just use any of the popular Go code editors/plugins which give you a "show me all implementations".

Does not work all the time, hence my use of the ‶rickety″ adjective.

> This makes understanding what a piece of code is doing much easier, while simplifying mocking as well.

That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them.

>When you carry around pointers to struct implementing interfaces, it does not check for anything at compile time.

What exactly do you mean here? You can't assign a value that doesn't implement an interface Foo to a variable of type Foo. That will cause a compile time error.

> That's a design problem, not an interface problem. Split you giant 30-methods interface into smaller ones if need be, that the whole point of interfaces: not be a 1-1 mapping to methods, but a semantic (sub)group of them.

It really isn't. This way it becomes a guessing game "Which methods will be used with which other ones?".

Even if I have a KVStore interface with 4 methods: Get, Set, List and Delete, it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete.

The other commenter already responded to your static typing assertion, so leaving that for there (it absolutely does check it).

> it's a huge value to future code readers if my new structure only accepts an interface with List and Get, or List and Delete.

But that's not specific to golang. You can use the same approach in Java, Kotlin, C#, etc

Unless I'm missing something, you then have to write wrappers that translate between the big and the small interfaces, or explicitly mark all interfaces as implemented at the original type definition point.

The first one is a lot of boilerplate, the second one is not always possible.

> 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.

Language servers are a thing nowadays, and the standard go one will find all implementations before you finish blinking. Why is this considered harder than whatever you are using to find implementations in your language of choice?

> 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.

So like every other language with interfaces then? But why are you even compiling in prod at 3AM in the first place?

The insane bit about date formatting is recognised to be insane by the Golang team themselves. To quote 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!)

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?

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".

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?

It's not common in any software I've written or touched in my entire career.

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.

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.

> This "bizzare" US order (month-day-year) is SO COMMON in software that it's very familiar.

I've been using computers since 1986, and I've used many many software packages.

Which software package uses month-day-year outside of the US? Every package uses the locale, so the 94% of the population outside of the US literally never sees this format.

Here, quick example from today. Working with an R-script and needed to check date functions [1] and you got mm/dd/yyyy literally in the docs. Good luck figuring out what "%a" or "%D" means, btw.

Another recent example - I had to fight for two hours with yet another javascript date/time picker to present date in localizaiton of a browser. Turns out this popular picker didn't have proper support for localization and set US one by default.

The same issue I had with Flutter time picker, btw. Not sure if it's been fixed by now, but making proper localization support can be quite challenging even in 2022.

Sure, localization support is getting better each decade, but it's far from perfect. And if you've used software since 1986, then you should remember that at that time the concept of localization DIDN'T EVEN EXIST and majority of the software (including DOS!) used US format (there were "localized" versions of DOS, ofc, but those were even branded differently and the best you could get is codepage, keyboard and printer support).

[1] https://www.statmethods.net/input/dates.html

> it's definitely not "insane" and not "bizzare". Why would anyone even claim that?

Pretty sure it's just anti-American signalling/globalist cultural imperialism. Asian/8601 date format makes a lot more "logical" sense, but nothing beats what you grew up using, at least for me, in a non-technical context.

Obviously your software should present dates in a locale-aware manner, just as it should (where possible) present localised text. But if it's anti-American signalling to expect reference documentation and technical features for non-localised systems (such as the Go programming language) to use the internationally accepted standards for the presentation of non-localised data, then… sure, I guess I'm happy to signal anti-American?

But I am one of Those People who goes around $WORK's internal wiki (which has users in the USA and GB) telling people off for failing to use 8601 in their meeting minutes, so perhaps take with a pinch of salt.

To be clear, I meant it as a general phenomenon and wasn't directed at you. I see a lot of the same thing on reddit, etc. Metric vs imperial is an almost-daily comment chain in the Oxygen Not Included subreddit, for example. It just gets a bit tiring to see the same discussion again and again.

(edit) I'm perfectly fine using 8601 in technical contexts, or anywhere really, but describing American cultural practices as "insane" and "bizarre" is exactly what I'm talking about.

Then ditch letter mapping and use named parameters: "{day} {month} {year}" etc. The Golang approach already requires complicated string parsing, so a formatting language isn't going to be more complicated, but then the documentation can just tell you exactly what you need to write to get the desired output, rather then debugging whether you got an invisible implied order wrong (with a failure mode of either giving random output, or just literals).

But why? It's so handy in practice!

I work a lot with times (not just dates) and having strings like "15:04" make it immediately recognizible, consise and just right.

What I actually lack in Go's time is ability to work with time only without timezone (like, event starts at "12:00", regardless of timezone). But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others. So I just spent 10 minutes and wrote my own type for that and use it happily along with time.Time.

> But here is the thing - Go is a programming language, and not "framework with solutions for every use case" as many others.

So... why did they provide a terrible time formatting routine in the first place if it's not a solution to use cases?

OP was talking about an issue unrelated to time formatting in the part you quote (the lack of a timezoneless time type).

Because they're not that smart as HN commenters, obviously. Be compassionate.

> slight inconvenience for non-US citizens

So, 96% of the world's population?

And even in the US, science and engineering projects commonly use ISO dates.

Go's date formatting is as if a random American had taken a quick glance at a paper calendar pinned to the side of their fridge, and decided "yeah, let's do it like that".

Most people can remember "January 2nd" and don't think about US-date vs non-US date.

Or "the second of January", as it may map better to your language ("El dos de Enero")

Or “le deuxième de janvier”, or “der zweite Januar”, or…

Well...

January 2nd?

January 2?

2 January?

Just remember the date and use it in your date formatting string.

If you want today to be printed as "December 11" put "January 2" in your Format() call. If you want "11 December", put "2 January". No need to remember any alphabet mappings anymore, it's way simpler.

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.

> 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).

> 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".

> 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.

> 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.

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.

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.

> 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?

(The GP was using the US convention to refer to the two dates 01/02 and 02/01, not trying to use two conventions to refer to a different date each.)

Ah, I see. Apologies to GP, but I believe the point is still reinforced - the biggest enemy of an engineer when it comes to dates is ambiguity.

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.

> 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..)

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.

“Jan 2006” and short month, short month, minutes?

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?

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.

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

Design mistake )))

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.

Isn't Go more positioned as a language for web services, rather than systems programming?

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.

And yet Go is much more popular than Rust.

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.

… 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-dre...

Describing that as "2% more" instead of "20% more" is a bit misleading when comparing just two items.

Sorry, I intended to say "2% more of the respondents". That was what I had in my mind when I wrote it. (In general, my opinion is that Relative Statistics Considered Harmful, they're like absolute statistics but with all the context removed, and I never intend to give them.)

> compared to its most direct competitor, Rust.

No, no, no and no. How on Earth people come to this conclusion? Go is closer to node.js than to Rust. Like, it is not even a competition they are so far apart. One is a “zero-cost abstraction, low-level language”, the other is a “managed language with a GC like million others, which is as badly expressive as C”. To mention some positive as well, virtual threads are cool.

But the two is nothing alike and this sentiment is just utterly stupid and I see it everywhere for God knows why.

> How on Earth people come to this conclusion?

1. Because they were first unveiled around the same time, as AOT natively-compiled languages with drastically different takes and directions.

2. Because when the authors of Go first released it, they called it a systems language. By which they meant, unlike anyone else, a language to write systems with. Like… programs.

3. Because when first unveiled, Rust was a very different language, much more similar to Go. It always had a much more functional and type-heavy bent, but it had a runtime and scheduler, userland threads, kinda-sorta a GC in potential (“GC’d pointers” though no GC was ever implemented for real). As noted in (1) it looked a bit on a completely different take on a similar niche. It was brought downstack over time as the community saw its potential as an “innovative” breath of fresh air for low-level uses: higher levels of the stack already had memory-safe and type-heavy programming languages if they wanted those.

> (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

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).

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.

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.

What is 1234567 anyway? Why 1 is month? From which clue should I remember that?

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.

Reply on news.ycombinator.com