4 ms·
Oh yes, great example. It's literally "1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone" Clever mnemonic tecnhique which is much e
by divan 4y ago
Oh yes, great example.
It's literally "1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone"
Clever mnemonic tecnhique which is much easier to use and memorize. Most people can remember "January 2nd 2006" and "15:04:05" easily, and then crafting date/time format strings becomes a toy.
While with more widespread and common "HH/MM/SS" approach, which has bunch of incompatible implementations in different languages, you have to constantly do mental gymnastics remembering if "MM" means minutes or months, and whether "Y" or "yyyy" represents full year.
Format string "D m y", for example, produces:
- 'Tue 05 22' in PHP
- '05/31/22 05 22' in Ruby and Rust
- 'D 40 22' in .Net
- '151 23 2022' in Dart and Swift
I have no idea how such a messy and suboptimal approach to date formatting even makes sense to people. But of course, many people are bashing Go date formatting simply because it's not what they used to in other languages.
- aniforprez 4y agoIt's a really dumb date because it's so easy to just pick a date that was greater than 12 to easily make out that something is a date and not a month. As it is, 01-02 could literally be anything. I much prefer strftime formats to Go's inane date formatting thing. I find it MUCH easier to simply remember "dd-mm-YYYY" (which is about the only format I use almost 99% of the time) than the specific date they're looking for. I don't really care if something is different in other languages. I'm already context switching and it's easy to look this up
- dragonwriter 4y ago> 1st month, 2nd day, 3rd hour, 4th minute, 5th second, 6th year, 7th timezone Which, would be intuitive and easy to remember if month-day-hour-minute-second-year-timezone was a sane logical ordering. > Format string "D m y", for example, produces: > - '05/31/22 05 22' in Ruby and Rust How are you doing that in Ruby? The standard Ruby DateTime formatting method is DateTime#strftime() which uses approximately (mostly, fixing the locale-dependent options because the method is not locale sensitive) POSIX strftime format strings, which that is not. Did you mean “%D %m %y”? Then that's right for Ruby/Rust. But that doesn't seem to produce the results you list for other languages (some of which also have a POSIX-ish strftime, though, e.g., it is deprecated in PHP.)
- noisy_boy 4y agoOr that they are used to simple things being kept simple in other languages. Case in point - String enums in Go: const ( Summer Season = iota Autumn Winter Spring ) func (s Season) String() string { switch s { case Summer: return "Summer" case Autumn: return "Autumn" case Winter: return "Winter" case Spring: return "Spring" } return "Unknown" } Same in Java (invalid values would raise an exception): enum Season { Summer, Autumn, Winter, Spring } Newcomer friendly indeed.
- divan 4y agoObviously Go code shown here doesn't show string enums. It's an integer enum with function that converts integer value to the string representation (by implementing Stringer interface). Which makes total sense (not every int enum needs String conversion). I assume your Java example has some magic (aka conventions) in how to convert values into string. Without reading Java manuals, how do I know what's the magic's conversion function? With single words it's usually easy, but try two words "LeapYear" or text with non-Unicode chars - how the magic will work then? Go tries to minimize amount of hidden magic. Also, should not Java enums be capitalized? I mean, sure, Go enums can be improved, and there are few proposals (none of them yet passed, and that's usually for a reason), but this comparison is just incorrect.
- noisy_boy 4y ago> Obviously Go code shown here doesn't show string enums. It's an integer enum with function that converts integer value to the string representation (by implementing Stringer interface). Which makes total sense (not every int enum needs String conversion). Considering your robust defence of Go, maybe you can demonstrate the simplicity of Go's string enums? > I assume your Java example has some magic (aka conventions) in how to convert values into string. Without reading Java manuals, how do I know what's the magic's conversion function? There is no magic - .toString() produces an equivalent string. The point is to keep simple things simple - most of the time, the enum value and its string representation is same and the snippet in my previous post automatically gets us there. > With single words it's usually easy, but try two words "LeapYear" or text with non-Unicode chars - how the magic will work then? Go tries to minimize amount of hidden magic. Thanks for acknowledging that it is atleast easy in Java for single words. Words with spaces or unicode (I think thats what you meant when you said non-Unicode) isn't terrible either: enum Season { SUMMER("S U M M E R "), AUTUMN("A U T M N "), WINTER("W I N T E R "), SPRING( "S P R I N G "); private String value; private Season(String value) { this.value = value; } public String toString() { return this.value; } } I had to introduce a variable and couple of one-line methods which isn't super simple but still a win over a switch statement that requires listing out every representation. For shits and giggles, this is how I can enumerate over the enum values in Java: for (Season s : Season.values()) { System.out.println(s); } Feel free to show how you would do it in Golang with iota magic... PS: seems like the unicode strings that I pasted didn't carry over to HNs code snippet. The same is available on pastebin: https://pastebin.com/Yw0jyGDE https://pastebin.com/Yw0jyGDE