191–200 of 243 posts
Earlier quoted context omitted.
Most people can remember "January 2nd" and don't think about US-date vs non-US date.
Well... 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.
Earlier quoted context omitted.
> 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…
> 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
The first one is a lot of boilerplate, the second one is not always possible.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
The biggest mystery to me is how poorly designed Go is considering its illustrious creators. Thompson and Pike are living legends. They had absolutely nothing left to prove. Yet they came together for another major project, backed by the most powerful technology corporation in the world, and they produced... this? Go feels like a random hodgepodge of ideas from three or four computer science undergraduates – not like…
The parallels to Java are so fascinating on multiple levels. Did you know that Guy Steele was behind it too? At one point it was a revelation to me that the Java designers were not rookies, they just made a conscious decision to dumb things down. And in hindsight and after 15 years of cleaning up the mess we know that they just needlessly made a generation of developers suffer through primitive abstractions.
And Java is not a badly designed language at all, it did make several tradeoffs at places for various reasons, but it had a clear design goal and I think it did live up to it.
Years and years of discussions about Go's poor and verbose error handling, with multiple sensible proposals being rejected, and this is the improvement that finally makes it into a release? What Go demonstrates above all else is how successful a poorly designed language can be if it has a great compiler, an amazing standard library, and high-quality official tooling. Many "features" of Go are borderline insane (date…
Go explicitly prioritizes productivity in large Eng orgs with a range of programmer experience. This is often at the expense of what language enthusiasts this is important/new/cool You may not agree, but they are doing what they said they would from the start, and it’s been fairly effective.
Earlier quoted context omitted.
> 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)…
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.
Here, why ISO 8601 support was dropped (spoiler: it's an unparsable mess) https://github.com/golang/go/issues/734
Design mistake )))
Earlier quoted context omitted.
> 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)…
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.
I once liked Go a lot, then over time got frustrated by few things and moved on. Now I'm all about "Rust is the best thing since sliced bread!" I find it a bit hard to understand why people are critizing Go "yaddayadda oh how wrong this decision is yaddayadda" . Like, who cares. Let them do how they like it. Nobody is forcing anyone to use the language. Go's design decisions are not a universally applicable law or an…
Except when your employer does
Earlier quoted context omitted.
Isn't this line of argument somewhat self-defeating? It sounds as if these language design decisions that cause a vocal minority to complain loudly have only a marginal impact on actual productivity (or at least the perception of it). If so, that would be quite a good justification for not complicating the language by, e.g., adding enums, a non-nil pointer type, etc. etc.
I think that what you’re talking about might even be the killer feature that is often ignored: the forced simplicity. It’s a simple enough language that you can drop into a codebase and read without having to look up much syntax, assuming you have some familiarity with c-family languages. Yes, there are some weird bits that you have to learn, but the learning curve is very short compared to a lot of other languages.
Abstraction is the only reason we can write any complex program.
Earlier quoted context omitted.
I feel a lot of that has to do with Googlers not daring to question the famous authors, and the same authors seem to have been asleep for the last three decades in terms of modern programming language developments. I geared up to learn Go one day, got the book and everything, and after just a few hours of trying to write and rewrite error-handling code, I was wondering how this ever got out of the Request for Proposa…
Coming from Python I appreciated that there were no exceptions. I much prefer the explicit error returns instead of exceptions being used for flow control.
A loud exception is way better.