Imagine being a software engineer:
You invent a new CMS called "WordPress"
and you decide to store all internal links as complete URLs in the fucking database.
PEAK BRAIN USAGE

OOF

Seriously, we need JavaScript based operating systems and databases, graph databases have helped, but OS filesystems still lag behind

@lopu I hope you're joking 😄

@PonySlaystation absolutely not I'm deadly serious I think everything should be stored using circular JSON formats or graphs

I guess it was "easier" and "more uniform" to handle all links the same. Excellent pretext for laziness to handle different things the same way.

@lopu That's nonsense, and it smells like a JS dev who hasn't done enough actual low-level work to even know what an OS does. A language with automatic memory management for an OS, yeah sure.

The point of an OS is to abstract the hardware, and that implies that it has to deal with the hardware. JS in turn sits much higher up the abstraction chain and uses the abstractions from below. That's why it can't provide them.

@Fast-Nop
I recently started learning js , and man this language is definitely NOT good for os. Am also not well versed with os, but i guess its super fast because of all the verbose instructions written in c and assembly. If there was a js based os, half of the battery would go into running the insane js to assembly compiler

@StopWastingTime The main problem is that JS lacks anything that you need for making an OS. The automatic memory management alone is already a killer.

Though your last statement is somewhat self-contradicting - a compiler is meant to do the work once on the dev workstation, unlike a runtime interpreter on every target machine.

@lopu what does JS have to do with graph filesystems? (which are a thing btw, just never really matured enough or had a killer usecase over hierarchical systems). Filesystem organization is a logical structure implemented by the filesystem driver (or over fuse) and that structure can be done in any language. C/Rust/C++ etc. are astronomically better choices than JS for filesystems - you don't want your file accesses being slow.

@RememberMe think about it JavaScript runtime is basically a graph, a = {} a.a = a

@lopu so? Graphs are abstract structures, you can just as easily definite them in pretty much every other language. The ability to express graph edges is not unique to JS.

And no, the runtime isn't a graph, the runtime is a bunch of highly optimized C++ code manipulating internal data structures that you're using to build a graph here. That in itself should prove that you don't need JS for graphs.

(As a point of interest "classical" hierarchical systems are also graphs - they're trees. Filesystems with links (every major filesystem right now) are also restricted graphs)

@RememberMe why reinvent the wheel, JavaScript's object runtime system is solid and would grant many benefits over files and folders, a file is really just a string variable, would be cool if operating systems used objects instead

@lopu because it's slow as heck and eats up memory. I don't want V8 or SpiderMonkey with their incremental JIT compilers sitting pointlessly between my hardware driver and filesystem interface. And C/C++ graph implementations already exist and are fast as fuck. And they have much much much more scope for optimization.

If you'd said Go or D, now that's much more reasonable, even with the GC because they're well suited to low level programming.

Also it's much harder to validate and test JS code in a context like kernel programming.

Why don't you look up graph processing benchmarks (or any kind of benchmark really) between JS and C/C++? Native, that is, not library driven.

@Fast-Nop care to add anything here?

@RememberMe but V8 is C++ right?

@lopu V8 is a huge, complicated C++ program, yes. Plus, it's also what it's doing. Javascript interpretation and JIT compiling have significant overhead. *significant*.
Especially if you're talking about performance critical stuff like filesystems.

@lopu Guess the closest this possible to what you're asking for is Chrome OS?

@aggelalex chrome OS is a modified Gentoo or something if the sort anyway. No graph/JS based filesystems that I know of.

@RememberMe And that's still only the abstracted concepts that the OS needs to provide, i.e. implement it under the hood.

Writing to fixed memory addresses for memory mapped I/O isn't possible with JS. It doesn't even have an integer data type for register mapping. Interrupts (no, JS' events aren't the same), DMA, a bit of inline assembly for locks and semaphores, thread context switching, process isolation, and a whole bunch of other stuff.

I suggest that @lopu buy e.g. some Cortex-M eval board for 15 bucks or so and try to get it running without any library to get at least an idea of what's happening at bare metal level.

@Fast-Nop you _could_ implement just the filesystem driver in JS though. And you can wrap C functions for doing all the above in JS just for the lowest level stuff but still express the logic in JS.

And JS is technically a language, defined by the ECMA standard, not by an implementation, so it's entirely possible to create a suitable interpreter and low level programming framework that allows you to do all this.(ugh, stuff like TLB handler in js though. *Shudder*.)

Heck if I had the that kind of time I'd definitely try it, just for the heck of it.

So yeah. Speaking for just filesystems alone, you could of course make it in JS. It's possible, just not a great idea. imo, anyway. The pros are far outnumbered by the cons.

@Fast-Nop @RememberMe look guys I'm not saying to implement all rings of an OS in JavaScript but I think users would benefit from a GUI that uses more features of programming languages such as objects and arrays rather than just files and folders. And if that gui ran in a browser or in something like electron, you could edit all the html and css through the javacript gui.

You merge the idea of a filesystem with the idea of scopes in programming languages especially JavaScript, and yeah I know javascript doesn't have memory access and that sucks but I'm not too interested in the low-level stuff, just the idea that you can interact and shape JS/ON data structures, and link some object properties to html values, css values, the way js frameworks do atm. But you can edit those values in a gui that is the app itself.

So basically the program runtime is always on, and includes the editing tools in the program you're editing, meaning it can be edited instantly by anyone, shared instantly

@RememberMe Sure you could build all of that low level stuff in C/Assembly and call it from JS - which amounts to building the OS in C/Assembly and the application in JS. Right what we have. ^^

@lopu Just try an electron based editor vs. Notepad++ (written in C++), and you know why it would suck big time.