5 ms·

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

by krylon 9y ago

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.

iends 9y ago
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.
- weberc2 9y ago
  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". :)
- acover 9y ago
  Node's fs library changed within the last 2 years. I copy pasted code and it failed.
  - iends 9y ago
    I guess you’re talking about well published changes resulting in new major versions being released?
  - the_common_man 9y ago
    Usually those things are pretty solid especially wrt backwards compat. I am curious as to what you copy/pasted and how it failed.
  - always_good 9y ago
    Example?
    - deleted 9y ago
      [deleted]
  - mmcnl 9y ago
    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.
    - acover 9y ago
      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.
- chimeracoder 9y ago
  > 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.
  - iends 9y ago
    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.
- pier25 9y ago
  > 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
marcusramberg 9y ago
If you liked POE you might enjoy Mojolicious :) http://mojolicious.org/ http://mojolicious.org/
- petre 9y ago
  Writing async Mojo::IOLoop code is so much less verbose, easier than POE. It's possibly the most elegant Perl event loop. Thank you.
- krylon 9y ago
  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!

by krylon 9y ago

iends 9y ago

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.

weberc2 9y ago
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". :)
acover 9y ago
Node's fs library changed within the last 2 years. I copy pasted code and it failed.
- iends 9y ago
  I guess you’re talking about well published changes resulting in new major versions being released?
- the_common_man 9y ago
  Usually those things are pretty solid especially wrt backwards compat. I am curious as to what you copy/pasted and how it failed.
- always_good 9y ago
  Example?
  - deleted 9y ago
    [deleted]
- mmcnl 9y ago
  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.
  - acover 9y ago
    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.
chimeracoder 9y ago
> 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.
- iends 9y ago
  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.
pier25 9y ago
> 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

marcusramberg 9y ago

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

petre 9y ago
Writing async Mojo::IOLoop code is so much less verbose, easier than POE. It's possibly the most elegant Perl event loop. Thank you.
krylon 9y ago
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!