- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
This can be easily solved by just specifying a custom format string instead of one of the predefined constants.
t.AppendFormat(l.bufStream[:0], "2005-01-02T15:04:05.999999999Z")
(the other WTF is Go's use of a "reference date" to specify a date format string, but I've grown to like it)
Admin
correction...
This can be easily solved by just specifying a custom format string instead of one of the predefined constants.
t.AppendFormat(l.bufStream[:0], "2006-01-02T15:04:05.000000000Z")
(the 0's at the end indicate fixed decimal places using trailing zeroes; nines would represent decimals with no trailing zeroes)
Edit Admin
Perhaps not, but it is very close to wrong, on the basis that one of the reasons for the success of things like Python (and others) is the amount of stuff you can do using just the standard library.
Admin
It's short for: Go build your own libraries!
Edit Admin
As a counterpoint: what ends up in the class library is harder to change and you can get trapped. Third parties have a harder time getting traction in domains where the standard library has an implementation, even if that implementation is bad. Time and dates prior to Java 8 are a good example, and the C++ STL is an evergreen case.
Admin
Go has
fmt.Sprintfthat can be used here. Instead ofstrconv.AppendInt,l.bufStream = append(l.bufStream, fmt.Sprintf("%06dZ", nanos))can be used instead to append the 6-digit nanos plus the Z in one call.Admin
Go has robust time formatting functions that would solve this problem perfectly. Throwing shade about the standard library while said standard library does actually have the solution to the issue is a look for sure...
Edit Admin
Counter-counterpoint: JavaScript. Half the reason for the plethora of libraries is that the base language is so tiny that you always need to write something to get what you want, and everyone writes their own thing, and then publishes it as a library.
(Okay, so the proliferation of UI frameworks is probably due to the low quality of JS devs (like me), but lodash and its ilk are purely due to the tiny standard library.)
Admin
Go has a classic printf function that supports width and zero padding.
That said, it is a design assumption of Go that the its users can and shall write simple code themselves. A busybody library becomes a crutch, and if you've been in front-end dev long enough you remember when "how do I add two numbers with jQuery" was the joke of the day.
Admin
Their comment says they're not using a custom format because it isn't as optimized as using the RFC3339 format and doing these extra steps. Those steps include multiple math operations, including exponentiation, and multiple casts, conversions, and function calls. Can anyone with knowledge of Go performance testing compare this to using the built-in custom formatter? It feels at least moderately unlikely to me that this is actually faster. I'd be curious if that was a tested assertion or just a feeling.
Edit Admin
If you are worried about which step in your CI/CD process takes the most nanoseconds, I think you may be on the wrong track entirely.
Admin
TRWTF is that Go standard library has an HTTP server, SQL interface and HTML templates as a result of "the explicit choice to keep the standard library as small as possible"