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?
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.
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.
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).
But that's not specific to golang. You can use the same approach in Java, Kotlin, C#, etc
The first one is a lot of boilerplate, the second one is not always possible.
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.
And me thinking the Go culture is against languages that tend to come with IDEs...
I prefer to use an editor/IDE and don't think it's pleasant to work with any language (including Go) without them.
"Well obviously you need a proper IDE to protect you from Go's fuckups"
Cool.
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?
> 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!)
Are you intentionaly trying to misrepresent that clause of "regrettable error" or didn't read carefully?
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".
January 2nd?
or
January 2?
or
2 January?
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.
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 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?
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.
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).
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.
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.
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.
(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.
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.
So... why did they provide a terrible time formatting routine in the first place if it's not a solution to use cases?
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.
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).
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".
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.
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.
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.
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?
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.
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..)
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.
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?
Here, why ISO 8601 support was dropped (spoiler: it's an unparsable mess) https://github.com/golang/go/issues/734
Design mistake )))
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.
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.
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.
https://survey.stackoverflow.co/2022/#section-most-loved-dre...
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
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).
But don’t rely too much on cultural assimilation, because DOW is not the Sunday / 0 you might then expect.
...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.