5 ms·

It’s a tradeoff. Do you prefer to be stuck with bad built-in file and time APIs, or a robust ecosystem of external crates? https://fasterthanli.me/articles/i-w

It’s a tradeoff. Do you prefer to be stuck with bad built-in file and time APIs, or a robust ecosystem of external crates? https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

hu3 2y ago
So your argument is that an ecosystem of external crates which are created and maintained mostly by individual contributors is on average better than the standard library backed and dogfooded by trillion dollar company and used by other giants of the industry? Can't say I agree. Not to mention nothing prevents anyone from using or writing their own library only for the parts that need specialization. You're free to do that and many have. And standard libraries can be versioned and deprecated too.
- everforward 2y ago
  I actually wouldn’t be surprised, if only because the standard library is so much harder to make backwards-incompatible changes to. I would generally expect that the average quality of the third party libs is lower, but the top 1% is probably better than stdlib. Eg I don’t find the stdlib logging library particularly great; not bad, but not impressive. Ditto for the stdlib errors package before they added error wrapping
- iknowstuff 2y ago
  Uh, which ones would you like to compare? C++ std regex vs rust’s regex crate?
mijamo 2y ago
"robust ecosystem" is a rather optimistic view of the rust situation... I would have said "a bunch of 0.x libraries that do 80% of the work and let you figure you the hard 20% while being slightly incompatible with each other, and that will be painful to glue together because of the rules for traits"
pjmlp 2y ago
I rather have something that works everywhere there is a full implementation of the platform, instead of whatever third parties decided to support.
kbolino 2y ago
The file API is mostly fine. Opening with that is the wrong approach to me; the comparison with Rust doesn't really illustrate any serious issues. All of the complaints could be addressed with better documentation. The time API, on the other hand, is that bad, and worse. Besides the bizarre monotonic time implementation, there's also the bloated size of the time.Time struct, and the lack of actual "dates" (YYYY-MM-DD) and "times" (HH:MM:SS) that you can do arithmetic on. You can't really roll your own robustly either because time.Time isn't a great foundation to build on and //go:linkname is getting locked down. Thankfully, build constraints are much better now, since they just use regular boolean operators, e.g.: //go:build windows && (i386 || amd64) I agree that there shouldn't be any _buildtag.go magic, and I think they ought to remove that "feature" entirely in a future version of Go (which can be done so that it doesn't affect older or unversioned code). It seems they added a "unix" build tag too. Also, one of my personal gripes is that the standard library exposes no guaranteed way to access the system CSPRNG. Any code can replace (crypto/rand).Reader with another implementation and compromise cryptographic operations. It's a trivial supply-chain attack vector, and even in non-malicious scenarios, it can be done mistakenly and break things all over the place in a subtle but dangerous way. The language developers have so far refused to fix it too. Then there's log/slog with no TRACE or FATAL levels built-in; yeah, you can roll your own levels, but why should you have to?
- pjmlp 2y ago
  Anyone with enough experience in C derived languages large scale preprocessor spaghetti, welcomes _buildtag.extension alternative. This is actually one of the few things I fully agree with Go designers.
  - kbolino 2y ago
    Is the file foo_bar.go (no build tag line) compiled or not? If your Go version doesn't know of such a build tag as "bar", then foo_bar.go is unconditionally compiled. If Go in a later version adds "bar" as a known build tag, then foo_bar.go becomes conditionally compiled. Better hope you know this is how things work (reality: lots of Go devs don't). Build tag lines don't have this problem. They always specify compilation conditions, even if the build tag is not already known to the compiler. They also apply to the whole file, the same as _tag in the name; there's no preprocessor spaghetti possible.
Thaxll 2y ago
Rust has multiple http server and async framework which creates a lot of confusion.
metadat 2y ago
Great example, and more of a horror show than I anticipated. It would have been interesting if the author had a suggestion on what the Golang team should've / could've done instead, beyond correctly communicating the nature of the breaking change in the Go 1.9 release notes.

hu3 2y ago

So your argument is that an ecosystem of external crates which are created and maintained mostly by individual contributors is on average better than the standard library backed and dogfooded by trillion dollar company and used by other giants of the industry? Can't say I agree. Not to mention nothing prevents anyone from using or writing their own library only for the parts that need specialization. You're free to do that and many have. And standard libraries can be versioned and deprecated too.

everforward 2y ago
I actually wouldn’t be surprised, if only because the standard library is so much harder to make backwards-incompatible changes to. I would generally expect that the average quality of the third party libs is lower, but the top 1% is probably better than stdlib. Eg I don’t find the stdlib logging library particularly great; not bad, but not impressive. Ditto for the stdlib errors package before they added error wrapping
iknowstuff 2y ago
Uh, which ones would you like to compare? C++ std regex vs rust’s regex crate?

mijamo 2y ago

"robust ecosystem" is a rather optimistic view of the rust situation... I would have said "a bunch of 0.x libraries that do 80% of the work and let you figure you the hard 20% while being slightly incompatible with each other, and that will be painful to glue together because of the rules for traits"

pjmlp 2y ago

I rather have something that works everywhere there is a full implementation of the platform, instead of whatever third parties decided to support.

kbolino 2y ago

The file API is mostly fine. Opening with that is the wrong approach to me; the comparison with Rust doesn't really illustrate any serious issues. All of the complaints could be addressed with better documentation. The time API, on the other hand, is that bad, and worse. Besides the bizarre monotonic time implementation, there's also the bloated size of the time.Time struct, and the lack of actual "dates" (YYYY-MM-DD) and "times" (HH:MM:SS) that you can do arithmetic on. You can't really roll your own robustly either because time.Time isn't a great foundation to build on and //go:linkname is getting locked down. Thankfully, build constraints are much better now, since they just use regular boolean operators, e.g.: //go:build windows && (i386 || amd64) I agree that there shouldn't be any _buildtag.go magic, and I think they ought to remove that "feature" entirely in a future version of Go (which can be done so that it doesn't affect older or unversioned code). It seems they added a "unix" build tag too. Also, one of my personal gripes is that the standard library exposes no guaranteed way to access the system CSPRNG. Any code can replace (crypto/rand).Reader with another implementation and compromise cryptographic operations. It's a trivial supply-chain attack vector, and even in non-malicious scenarios, it can be done mistakenly and break things all over the place in a subtle but dangerous way. The language developers have so far refused to fix it too. Then there's log/slog with no TRACE or FATAL levels built-in; yeah, you can roll your own levels, but why should you have to?

pjmlp 2y ago
Anyone with enough experience in C derived languages large scale preprocessor spaghetti, welcomes _buildtag.extension alternative. This is actually one of the few things I fully agree with Go designers.
- kbolino 2y ago
  Is the file foo_bar.go (no build tag line) compiled or not? If your Go version doesn't know of such a build tag as "bar", then foo_bar.go is unconditionally compiled. If Go in a later version adds "bar" as a known build tag, then foo_bar.go becomes conditionally compiled. Better hope you know this is how things work (reality: lots of Go devs don't). Build tag lines don't have this problem. They always specify compilation conditions, even if the build tag is not already known to the compiler. They also apply to the whole file, the same as _tag in the name; there's no preprocessor spaghetti possible.

Thaxll 2y ago

Rust has multiple http server and async framework which creates a lot of confusion.

metadat 2y ago

Great example, and more of a horror show than I anticipated. It would have been interesting if the author had a suggestion on what the Golang team should've / could've done instead, beyond correctly communicating the nature of the breaking change in the Go 1.9 release notes.