Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js needs a virtual file system

blog.platformatic.dev

Post reply on HN
Print view View original

91–100 of 275 posts

Re: Node.js needs a virtual file system

#91

Post by dotancohen »

goalieca wrote: post #62
digikata wrote: post #53

Earlier quoted context omitted.

Large PRs could follow the practices that the Linux kernel dev lists follow. Sometimes large subsystem changes could be carried separately for a while by the submitter for testing and maintenance before being accepted in theory, reviewed, and if ready, then merged. While the large code changes were maintained, they were often split up into a set of semantically meaningful commits for purposes of review and maintenanc…

> With AI blowing up the line counts on PRs, Well, the process you’re describing is mature and intentionally slows things down. The LLM push has almost the opposite philosophy. Everyone talks about going faster and no one believes it is about higher quality.

  > Everyone talks about going faster and no one believes it is about higher quality.
Go Fast And Break Things was considered a virtue in the JavaScript community long before LLMs became widely available.

Re: Node.js needs a virtual file system

#92

Post by hrmtst93837 »

pverheggen wrote: post #80
PaulHoule wrote: post #5

Would be nice if node packages could be packed up in ZIP files so to avoid the security/metadata tax for small file access on Windows.

You can always use virtualized Linux to avoid the NTFS penalty (WSL2, VS Code dev containers, etc.)

[flagged]

Re: Node.js needs a virtual file system

#94

Post by dotancohen »

austin-cheney wrote: post #10

Most of the 4 justifications mentioned sound like mitigations of otherwise bad design decisions. JavaScript in the browser went down this path for the longest time where new standards were introduced only to solve for stupid people instead of actually introducing new capabilities that were otherwise unachievable. I do see some original benefits to a VFS though, bad application decisions aside, but they are exceedingl…

  > I think JavaScript would benefit from an in-memory database.
That database would probably look a lot like a JSON object. What are you suggesting, that a global JSON object does not solve?

Re: Node.js needs a virtual file system

#95

Post by dakiol »

digikata wrote: post #53
indutny wrote: post #29

Taking the question of whether this would be a useful addition to Node.js core or aside, it must be noted that this 19k LoC PR was mostly generated by Claude Code and manually reviewed by the submitter which in my opinion is against the spirit of the project and directly violates the terms of Developer's Certificate of Origin set in the project's CONTRIBUTING.md

Large PRs could follow the practices that the Linux kernel dev lists follow. Sometimes large subsystem changes could be carried separately for a while by the submitter for testing and maintenance before being accepted in theory, reviewed, and if ready, then merged. While the large code changes were maintained, they were often split up into a set of semantically meaningful commits for purposes of review and maintenanc…

Nobody wants to review AI-generated code (unless we are paid for doing so). Open source is fun, that's why people do it for free... adding AI to the mix is just insulting to some, and boring to others.

Like, why on earth would I spent hours reviewing your PR that you/Claude took 5 minutes to write? I couldn't care less if it improves (best case scenario) my open source codebase, I simply don't enjoy the imbalance.

Re: Node.js needs a virtual file system

#96

Post by exe34 »

epolanski wrote: post #78
indutny wrote: post #36

Earlier quoted context omitted.

As someone who was a part of the aforementioned security team I'm not sure I'd be interested in reviewing such volume of machine generated code, expecting trap at every corner. The implicit assumption that I observed at many OSS projects I've been involved with is that first time contributions are rarely accepted if they are too large in volume, and "core contributor" designation exists to signal "I put effort into t…

For free, you can decide to do what you want, if it's your job, it's a bit different and you may have to do so, especially considering Collina, is one of the largest contributors of the project and member of the technical committee.

> if it's your job, it's a bit different and you may have to do so

Oh I'd use an llm to generate large amounts of feedback and request changes!

Re: Node.js needs a virtual file system

#97

Post by mike_hearn »

LunaSea wrote: post #60
mike_hearn wrote: post #50

Earlier quoted context omitted.

Most obviously, Java has JDBC. I think .NET has an equivalent. Drivers are needed but they're often first party, coming directly from the DB vendor itself. Java also has a JIT compiling JS engine that can be sandboxed and given a VFS: https://www.graalvm.org/latest/security-guide/sandboxing/ N.B. there's a NodeJS compatible mode, but you can't use VFS+sandboxing and NodeJS compatibility together because the NodeJS mo…

> Most obviously, Java has JDBC. I think .NET has an equivalent. Drivers are needed but they're often first party, coming directly from the DB vendor itself. So it's an external dependency that is not part of Java. It doesn't really matter if the code comes from the vendor or not. Especially for OpenSource databases.

Well in the case of Oracle you can get the language, runtime, DB and driver all from the same organization under unified support contracts.

If you don't value that, why would you want your programming language implementors to also implement database drivers?

Re: Node.js needs a virtual file system

#98

Post by phendrenad2 »

crote wrote: post #65
charcircuit wrote: post #57

Earlier quoted context omitted.

It would be considered (a) since the author would own the copyright on the code.

Citation needed. Whether AI output can fall under copyright at all is still up for debate - with some early rulings indicating that the fact that you prompted the AI does not automatically grant you authorship. Even if it does, it hasn't been settled yet what the impact of your AI having been trained on copyrighted material is on its output. You can make a not-completely-unreasonable argument that AI inference output…

Why write open-source software at all, when the government could outlaw open-source entirely? What if an asteroid destroys Earth and there are no humans left to enjoy your work? At some point, you have to agree that a risk isn't worth worrying about. And your "worst possible outcome" is just the arbitrary outcome that you think has some subjective risk threshold. And it's certainly not one I agree with. Furthermore, calling it a "nuke" is a bad analogy because that implies that it can't be put back in the bottle once opened. In reality, we're dealing with legal definitions, which can be redefined as easily as defined.

Re: Node.js needs a virtual file system

#99

Post by phendrenad2 »

Normal_gaussian wrote: post #45
wccrawford wrote: post #13

I'm not convinced that allowing Node to import "code generated at runtime" is actually a good thing. I think it should have to go through the hoops to get loaded, for security reasons. I like the idea of it mocking the file system for tests, but I feel like that should probably be part of the test suite, not Node. The example towards the end that stores data in a sqlite provider and then saves it as a JSON file is mi…

node -e "new Function('console.log(\"hi\")')()" or more to the point node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c => new Function(c + 'console.log(exports.say({ text: \"like this\"}))')())" that one is particularly bad, because umd messes with the global object - so this works node -e "fetch('https://unpkg.com/cowsay/build/cowsay.umd.js').then((r) => r.text()).then(c =>…

Well there you have it.

I had to laugh, because the post you're replying to STRONGLY reminds me of this story, https://news.ycombinator.com/item?id=31778490 , in which some people on the GNOME project objected to thumbnails in the file-open dialog box because it might be a "Security issue" (even though thumbnails were available in the normal file browser, something those commenters probably should have known about, but didn't, but they just had to chime in anyway).

Post reply on HN