You're comparing core libraries of Go with non-core libraries of Node.js. Since Go libraries are not versioned without a tool like dep, you're putting trust that master doesn't have breaking changes vs hoping the maintainer follows SemVer correctly. In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.

This seems to be a commonly-misunderstood point, so I would like to clarify a few things for readers. Go's tooling isn't great, but to characterize it as "trusting master" is inaccurate. Besides tools like `dep`, you can also vendor your dependencies manually or use submodules to pin to a known-good version of your dependencies. There are also tools like Nix which give you fully-reproducible builds. Just because Go has historically punted on the problem doesn't mean there aren't lots of better solutions than "trusting master". :)

> In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.

The Go team has no problem with this; /x/ packages are explicitly not covered by the backwards compatibility guarantee, and in fact they may be considered to disappear at any point.

I’m specifically talking about things not under the Go 1.0 compatibility guarantee because those things are obviously reverted. Different Go packages from the Go team have different guarantees, for example being compatible with the with the last two Go releases only. I’m on mobile so I can get you examples later after thanksgiving festivities are over but this definitely happens, but you wouldn’t notice unless you read a lot of the Go commits or run into the issue yourself.

> You're comparing core libraries of Go with non-core libraries of Node.js

OTOH Node.js is much more dependant on third party libraries than Go

Node's fs library changed within the last 2 years. I copy pasted code and it failed.

To be fair, you shouldn't be copy pasting code anyway. But I do understand your feelings, any tutorial from before 2016 probably isn't relevant anymore.

I remember the error now. I was using an older version of node (installed via apt) but the current version of the documentation.

Stupid mistake. Please ignore.

Usually those things are pretty solid especially wrt backwards compat. I am curious as to what you copy/pasted and how it failed.

I guess you’re talking about well published changes resulting in new major versions being released?

Example?

If you liked POE you might enjoy Mojolicious :) http://mojolicious.org/

Thanks for the hint, it looks very interesting.

Most (well, all) Perl programming I do these days is simple scripts for automating tedious tasks, reporting, etc., and the odd CGI script.

Funny story, though: during my training I spent some time in a team doing in-house Perl development, and I sat next to Sebastian Riedel's desk! :-) It's a small world!

Writing async Mojo::IOLoop code is so much less verbose, easier than POE. It's possibly the most elegant Perl event loop. Thank you.