3 ms·

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 tha

by 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

by iends 9y ago

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