Ergo: Erlang-inspired event driven actor framework in Go

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-...

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.

"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"

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

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?

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

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.

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

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.

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.

I guarantee you it is even worse with preprocessor spaghetti, than build tools.

I think we're talking past each other.

Build constraints with "//go:build" already exist, I'm not making them up or proposing something new: https://pkg.go.dev/go/build#hdr-Build_Constraints

This has nothing to do with preprocessor spaghetti, which is impossible in Go. Either a file is included or it is excluded. Neither with file naming nor "//go:build" can you cause only portions of a file to be compiled.

Really, the _tag.go mechanism is just a very simple kind of build constraint, equivalent to "//go:build tag". The problem is that it relies on a magic list of known build tags, and the contents of that list change over time. Apart from _test.go, which is a little too convenient to give up in my opinion, the rest of the tags could be pushed into build constraints, or at the very least, the list of known build tags could be frozen in its current state.

Build contraints are the version of Go's preprocessor spaghetti, when those conditions get so complex, that one needs pen and paper to understand what is actually included.

Well, then it ought to go the other way. If you create foo_bar.go and bar is not a known build tag, you should get a compiler error.

Uh, which ones would you like to compare? C++ std regex vs rust’s regex crate?