Node v8.5.0 | Hacker News Reader

Node v8.5.0

nodejs.org

195 pointsbpierre51 comments

> add fs.copyFile and fs.copyFileSync which allows for more efficient copying of files.

FINALLY. I don;t know how long we could have come with this still being a thing you need a module for, or you have to code yourself.

Hopefully we get `fs.mkdirp` and `fs.remrf` somewhere down the line.

> Add support for ESM. This is currently behind the `--experimental-modules` flag and requires the `.mjs` extension.

I don't like the `.mjs` extension, but I understand the need for it, and I'm just glad that modules are finally here.

I like .mjs because this is a good example of exactly what file extensions are meant for.

I probably don't understand what I'm looking at. I would like sendFile/sendFileSync - which would abstract over TransferFile on Windows.

The reason you're unlikely to see that in the node binary is presumably the same reason copyFile has taken so long: node aims to have a small core that enables a rich userspace.

There's gotta be a very good reason to bog down the core with more stuff, since that equals less other stuff and more bugs. Some of the few valid reasons are ubiquity (which HTTP is, but Windows and sending files are not), or things that were impossible before (like no overhead file copy).

>node aims to have a small core that enables a rich userspace

So, dogma?

Because copying a file fits right in any kind of "small core" -- and helps create a more dependable and usable "rich userspace" which doesn't need to reinvent the wheel 200 times for basic stuff.

The problem isn't the .mjs extension, but the unfortunate ability to import CommonJS modules, when that can already be done via require().

Dependency edges out of module land should be explicit, because those aren't going to work on the web, and the web matters more than node.

I asked about the import syntax[0] and got an answer on GitHub.

[0]: https://github.com/nodejs/node/pull/14369#issuecomment-32903...

I think this decision is also short-sighted since ES Modules are now JS and CommonJS should be phased out over time, but now CommonJS is the default and holds the .js extension just complicating everything for short-term ease of use.

They should have left requiring for CJS modules and let things be crappy for a while as requires and CJS are phased out. Eventually only ESM would remain except for in some abandoned packages, which could still be required.

But now CJS is going to live forever because it's the default and ESM is opt in.

Wiuldnt implementing those be trivial? They are hardly going to be "too slow" like file copy might be, and with the JS love of small packages this should already be a solved problem.

There most certainly are already packages that do this, as well as countless projects with a util.js file implementing a hodgepodge of such functions that are standards in many languages. But as a programmer I would say my biggest complaint against JS is the miserably small standard library. Thus every project has its own set of dependencies that have their own APIs. Two projects from different JS ecosystems are as different as projects in different languages altogether.

There are trade offs to be sure, but I prefer the languages (and in this case platforms) that have batteries included.

> Thus every project has its own set of dependencies that have their own APIs.

Yes, this means that if your project depends on ten other projects, and all ten projects implement their own copy-file routine, your project will end up with ten copy-file routines.

As Larry Wall said, "Easy things should be easy."

When working on a project and you need to copy something for the first time, you shouldn't have to do:

  * Ok I need to copy...  What npm package does that again?
  * search NPM for copy
  * figure out which package is "best"
  * npm i some-copy-package
  * require("some-copy-packge")
  * do thing

The first 4 steps should be unnecessary.

I'll buy it if you remove just third step.

or just

fs.createReadStream('file.txt').pipe(fs.createWriteStream('new-file.txt'))

Streams are too slow you say?

fs.writeFileSync('new-file.txt', fs.readFileSync('file.txt'))

I've never had a problem with no explicit copy, but I am very happy it has been added...

Are streams really considered "slow"? Would your second example be faster in practice for most files?

For the first one, what about error handling? You have to handle errors by both the read and write stream, and also most people will want a callback when everything is done, so you have to handle that event, too.

I'm not sure how fs.copyFile is implemented, but file copying is not the same as reading the contents of file and then writing it into another file, which is easy to implement. There are also permissions, extended attributes, access control lists, etc. And then there are CoW file systems such as APFL that can optimize copying referencing the original data instead of physically copying it.

In macOS libc there's a copyfile(3) function: https://developer.apple.com/legacy/library/documentation/Dar...

>I don't like the `.mjs` extension, but I understand the need for it, and I'm just glad that modules are finally here.

I read that a lot. Why do people don't like the new extensions?

Seems like the most elegant and programmatically more performant and less hassle free, solution to the issue.

Everything else looks like a terrible kludge.

> I read that a lot. Why do people don't like the new extensions?

Probably because you'll end up with .mts, .mjsx, .mts, .mtsx.

So? If they are different types, it makes sense to have different extensions (e.g. if mts implies typescript module).

> mts implies typescript module

Or mpeg transport stream:

https://en.m.wikipedia.org/wiki/MPEG_transport_stream

They usually use .ts extension, or .tsv, .tsa according to the wiki article you just linked.

.mts is unheard of.

Ive seen it in the wild. May not be that common though.

my camera (Lumix GH2) produces MTS files

Well, they can coordinate that like we coordinate mime types.

I've chanced upon the "same extension for the same thing" as a problem maybe 2-3 times in 30+ years.

I like that better than having to open a file and read its source to figure out what type of module it exports...

"Import" was already decided to help the parser performing static analysis versus "require". Now "mjs" is introduced to make detecting if we are in front of a commonjs or module "faster". I'm sure the people who decided this are very bright, but the main goal was how to be nice with v8, and not how to be easy for developers.

Changing from js to ts is an inconvenience sufficiently big enough to adopt flowtype instead.

Does enable async stack traces mean useful stack traces?

Node has been a frustrating language to switch to from C# from the perspective of stack traces. It seems in node they devolve into relative meaninglessness beyond the first line or two. I have fond memories of juicy stack traces like homing beacons.

I'm secretly hoping somebody will jump in to tell me I'm just reading them wrong or something...

Yes, this update will make async stack traces appear within its called context... allows for much better debugging. https://medium.com/the-node-js-collection/node-js-8-big-impr...

Any updates about the Node leadership disaster news from the 10 days ago? That left a bad taste in my mouth about node.

Do you have a link so I can read about this?

https://www.theregister.co.uk/2017/08/24/nodejs_forks_ayo_co...

tl;dr

> On Tuesday, the thirteen-member steering committee came together to vote on whether to remove Rod Vagg, a TSC member and Node.js contributor, over his controversial statements on Twitter and GitHub that prompted complaints. They also voted on whether to ask Vagg to resign.

I am always curious about what the statement was. When it comes to SJWs they usually do not want to display that because it is often such silly things.

IDK what they were but I find it irritating that having unpopular ideas can get you in trouble like this. His views are probably opposite of my ones, but still, I cant stand the hypocrisy in these situations and how easily these supposedly smart people are successfully pushed to go witch-hunting.

So basically social justice warriors tried to start a COC-based witch-hunt to get someone removed from nodejs, they failed, and now they are bitter about the whole affair, and forked node into a irrelevant nonofficial repo?

That's it? I'm happy. The toxic SJWs are out. Sounds good for the project as a whole.

There were several links posted on HN a few weeks ago. I didn't notice any that were inflammatory, but all were "flagged" and taken down regardless.

In most cultural matters, this community tilts quite progressive. However, "Codes of Conduct" are an exception case, in which the community's libertarian streak clearly dominates. I do not believe that the moderators approve of that deviation. It would not surprise me if this entire thread were likewise flagged and removed if this subject draws too much conversation.

Who cares? SJW left and the programmers stayed. Nothing will change from the release/code perspective.

More a controversy than a disaster. The last commits [0] are only about governance model, discord link... There are some rebase but that's it. Nothing will probably come from this fork.

[0] https://github.com/ayojs/ayo/commits/master

I find it ironical that people who take up pitch forks and accuse others of being a hazard to the health and growth of a project would, in lieu of having their demands met, do one of the worst actions possible against what they were "protecting": splitting the code base and the community with a fork.

How is forking the codebase "the worst possible thing"?

The open source landscape is filled with forks of projects that diverged for a variety of reasons.

A fork means the people involved are still contributing code and it can potentially be merged upstream.

The alternative is they don't fork, and contribute nothing because they're unhappy with the original project.

What disaster?

Just some ranting person(s) taking their marbles and going home. Let's hope the door didn't hit them on their way out.

Otherwise, Node looks totally non-impacted and business as usual.

> Just some ranting person(s) taking their marbles and going home

You mean four out of the 13 CTC members leave to make a fork and the project is "totally non-impacted"?

It's probably even better without those members on board.

This is from the Ayo "GitHub":

"For the time being, simply by mirroring them to preserve drop-in-ability. Eventually, I have no interest in retaining compatibility with Node Core at all, because that would involve participating in and interacting with a community with deeply dysfunctional governance."

Yeah, good luck with that.

switching between nodejs and laravel multiple times already, now I need try nodejs again.

What are you looking for that you're not finding?

Laravel borrows a lot from Ruby on Rails, so maybe that might be more your cup of tea. A lot of Rails developers are trying Elixir & Phoenix which is an awesome functional programming setup. PHP has also been trying to become more like C# it seems. So maybe .Net Core & C# are worth a try? If you go the C# route, I suggest using Visual Studio (the full IDE) as I find most of my joy typing C# comes from the IDE. Whereas a language like Elixir the joy is the language itself.

Everyone busy with iPhone X bad day for such important post

I think you could find plenty of people who couldn't care less about the iPhone X (you're speaking with one of them). I took one quick look, saw nothing of major interest, and moved on with my day.

Moving back to the linked story, are there any long running issues with Node that are still not yet addressed? Are nearly all common issues resolved?

Which long running issues?

All common issues are quickly resolved, almost by definition, in a long-running successful project like node. Lots of people depend on that being the case.

It's just not always resolved in core (which is why npm/yarn/webpack and a hundred other awesome derived works exist).

>All common issues are quickly resolved, almost by definition, in a long-running successful project like node. Lots of people depend on that being the case.

Not sure about Node, but regarding other "long running successful projects" you'd be surprised.

Not sure what that even means. I watched the keynote, decided I'll probably buy it when it comes out, had a few minutes of banter here on HN, and that was it. Then back to real life for the other 22.5 hours of today. :-)

Reply on news.ycombinator.com