I, for one, deeply appreciate any project which isn't afraid to do things differently when they decide there's a better way. I see it similar to iOS not supporting Flash, or Angular 2.0 rethinking things.
You can't change everything, but it's what you do differently that gives your project value.
Sure, but date formatting? That's where Go is going to differentiate itself? Even though it still uses a C-like format string? This seems like exactly the kind of area where leveraging the existing conventions would be a no-brainer.
It isn't the format string syntax that is the problem that they're trying to solve. I see this as being an iterative, backwards-incompatible improvement on the existing format convention. Changes in convention don't have to be all or nothing.
Comments
I, for one, deeply appreciate any project which isn't afraid to do things differently when they decide there's a better way. I see it similar to iOS not supporting Flash, or Angular 2.0 rethinking things.
You can't change everything, but it's what you do differently that gives your project value.
Sure, but date formatting? That's where Go is going to differentiate itself? Even though it still uses a C-like format string? This seems like exactly the kind of area where leveraging the existing conventions would be a no-brainer.
It isn't the format string syntax that is the problem that they're trying to solve. I see this as being an iterative, backwards-incompatible improvement on the existing format convention. Changes in convention don't have to be all or nothing.