Hacker News Reader

Comment by krylon | Hacker News Reader

So, I am not a big fan of Javascript. I do not despise it or anything, I just never got to like it. I guess.

I did really love POE, though, so when I heard of Node.JS, I thought I will probably like this very much.

I am not sure what happened. I think it was the tutorials being always out of date. Node.js seem so be such a fast-moving target. I do not mind asynchronous, callback-driven code. But when a tutorial that was written three months ago fails to run because some library had a breaking API change in between, that tends to drive me away.

Think of Go what you want, but its policy towards backward compatibility is a big plus.

View on HN

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.

Reply on news.ycombinator.com