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

101–110 of 275 posts

Re: Node.js needs a virtual file system

#101

Post by austin-cheney »

dotancohen wrote: post #94
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?

Whether it is an object, array, something else, or a combination thereof is a design decision. It is not so much about the design of the structure, which should be determined by execution performance considerations, but how information is added, removed and retrieved. Gathering one or more records from a JSON object, or array index, by value of some child property somewhere in a descendant structure of the instance index always feels like a one-off based upon the shape of the data. That could just be a query which is more elegant to read and yet still achieves superior execution performance compared to a bunch of nested loops or string of function array methods.

The more structures you have in a given application and the larger those structures become in their schemas the more valuable a uniform storage and retrieval solution becomes.

Re: Node.js needs a virtual file system

#102

Post by zadikian »

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.

DBMS vendor providing the client is nice. At least if you're using pg-native in Node, that's just a wrapper around the Postgres-owned libpq, but I've run into small breaking updates before that I don't feel would've happened if Postgres maintained both.

Re: Node.js needs a virtual file system

#103

Post by epolanski »

exe34 wrote: post #96
epolanski wrote: post #78

Earlier quoted context omitted.

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!

Imagine if every profession reasoned liked that when doing something they don't enjoy.

Re: Node.js needs a virtual file system

#104

Post by tracker1 »

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.

TBF, most of the AI code I've reviewed isn't significantly different than code I've seen from people... in fact, I've seen significantly worse from real people.

The fact is, it's useful as a tool, but you still should review what's going on/in. That isn't always easy though, and I get that. I've been working on a TS/JS driver for MS-SQL so I can use some features not in other libraries, mostly bridging a Rust driver (first Tiberious, then mssql-client), the clean abstraction made the switch pretty quick... a fairly thorough test suite for Deno/Node/Bun kapt the sanity in check. Rust C-style library with FFI access in TS/JS server environment.

My hardest part, is actually having to setup a Windows Server to test the passswordless auth path (basically a connection string with integrated windows auth). I've got about 80 hours of real time into this project so far. And I'll probably be doing 2 followups.. one with be a generic ODBC adapter with a similar set of interfaces. And a final third adapter that will privide the same methods, but using the native SQLite underneath but smothing over the differences.

I'm leveraging using/dispose (async) instead of explicit close/rollback patterns, similar to .Net as well as Dapper-like methods for "Typed" results, though no actual type validation... I'd considered trying to adapt Zod to check at least the first record or all records, and may still add the option.

All said though, I wouldn't have been able to do so much with so relatively little time without the use of AI. You don't have to sacrifice quality to gain efficiency with AI, but you do need to take the time to do it.

Re: Node.js needs a virtual file system

#105

Post by zadikian »

mike_hearn wrote: post #97
LunaSea wrote: post #60

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. 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?

Well that's only because Oracle happens to own both Java and Oracle DB. Suppose you're not using that DB.

Re: Node.js needs a virtual file system

#108

Post by monocularvision »

charcircuit wrote: post #70
crote wrote: post #65

Earlier quoted context omitted.

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…

The two main points are that: 1. Copyright cannot be assigned to an AI agent. 2. Copyrighted works require human creativity to be applied in order to be copyrighted. For point 2 this would apply to times were AI one shots a generic prompt. But for these large PRs where multiple prompts are used and a human has decided what the design should be and how the API should look you get the human creativity required for copy…

That indemnity clause is only for Team, Enterprise and API users. Do you know what was used here?

Also the commercial version is limited to “…Customer and its personnel, successors, and assigns…”. I am very much not a lawyer and couldn’t find definitions of these in the agreement but I am not sure how transferable this indemnity would be to an open source project.

Re: Node.js needs a virtual file system

#109

Post by torginus »

Why do people keep reinventing OS features?

There's Docker, OverlayFS, FUSE, ZFS or Btrfs snapshots?

Do you not trust your OS to do this correctly, or do you think you can do better?

A lot of this stuff existed 5, 10, 15 years ago...

Somehow there's been a trend for every effing program to grow and absorb the features and responsibilities of every other program.

Actually, I have a brilliant idea, what if we used nodejs, and added html display capabilities, and browser features? After all Cursor has already proven you can vibecode a browser, why not just do it?

I'm just tired at this point

Re: Node.js needs a virtual file system

#110

Post by curtisblaine »

dotancohen wrote: post #94
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?

sorted maps with log(n) access.
Post reply on HN