Repository navigation
Let's have a real conversation #6
Description
Just a note: I've been banned from Ayo.js for no reason specified other than my comments (but this was not even directly said to me) and find this entire situation extremely ironic considering the entire purpose of this Ayo.js fork to begin with was from bureaucracy in the Node.js community. The point of my proposal was because you intended on doing a fork and seemed like a good opportunity to ask for some MUCH needed design changes at the compiler level. Instead you ask me to "pick another language" when Javascript is literally embedded in our browsers... That kind of thinking is absurd. I wish I could boycott this especially given how community members act... But look at me now I'm on a browser...
I'm sure many of us use Node.js day to day due to obligations work related.
But let's actually solve problems with the core language design itself and not build off of the mediocre at best cost abstractions Javascript originated from.
-
Dynamic Type Inference
It's no surprise that types are god awful in Node.js. Whether you are casting from String to Integer and so forth. We don't even have the option between integers or unsigned integers. I think a simple pragmatic solution is to adopt a model similar to Golang where the compiler computes the type intelligently and we can also verbosely define types. Typescript kind of amplifies the problem with types by explicitly defining things asnumberorstringas opposed to more granular types that are given in other languages. -
Threading... beyond barely usable mutex like functionality.
I don't even think it's possible to utilize semaphore like primitives in Node.js. I believe there are some GYP implementations in the NPM ecosystem... However, proper threading management is pretty damn important. Especially if we want to build robust frameworks. Perhaps we can even adopt compiler logic like Erlang's or Rust's where we automatically utilize all threads for any computation. -
Atomic Operations
Another huge problem with Node.js is the inability to utilize Atomic Operations. These are pretty important for critical computations. And Node.js kind of throws the entire idea of atomic computations out the window. This is a big reason why a viable database can't be built in Node.js due to lack of atomicity and inability to adhere to ACID compliance. -
Improving bad cost abstractions
This goes beyond the async model in general... But rather... A lot of the core design of Javascript itself. For example we can't even utilize stacks or heaps in the native standard library. I could go on. But this can be improved by orders of magnitude to where it is now. Would be interesting to adopt data structures like Ring Buffers, Linked Lists and Double Ended Queues in the native library. Especially if we optimized abstractions in the assembly logic. I would be especially happy if we can utilize a lot of different graph techniques in the standard library... But that may be veering off more into a MATLAB approach to language design, but worth discussing anyway.
Activity
hashseed commentedon Aug 23, 2017
Chances are pretty slim for these proposal to make into V8 if they are not made part of ECMA262 standard through TC39. I'm pretty sure this applies to ChakraCore too.
It sounds like you want a different language with other design goals. How about Java, Go, or Dart?
ChrisCates commentedon Aug 23, 2017
@hashseed "I'm sure many of us use Node.js day to day due to obligations work related."
Go and Java are pretty solid. Dart is awesome too, but kind of defeats the purpose of my statement.
Seems like more bureaucratic bullshit is required in order to get any shit done in the Open Source world. Good thing I don't really participate in any of it, thought this would be an opportunity to write something meaningful for the community. Thanks for informing me though.
hashseed commentedon Aug 23, 2017
V8 is open source, so you can definitely fork it too. I'm just saying that you won't be able to get these changes into upstream V8.
ChrisCates commentedon Aug 23, 2017
@hashseed then what is the point of even forking it if no one else is going to use it. I'd rather just use Elixir and C/++ at that point. I don't even have 100 followers on Github and not even 1k followers on Facebook. Not sure how anything I produce would gain any traction whatsoever. Just kind of reality you know?
I've spent enough time doing similar things living in my own bubble. No need to spend time engineering things that don't really benefit me (but could benefit a lot of other people... technically the entire internet... but hey... Politics is politics).
hashseed commentedon Aug 23, 2017
Remember the days when every browser had its own flavor of JavaScript? That's what you are proposing, essentially.
ChrisCates commentedon Aug 23, 2017
@hashseed I proposed it to be the new standard. That's a little different. However, no one wants it to be a standard. Therefore, I have no interest in pursuing it, because I would literally be living in my own bubble. You're part of the core Chromium and V8 team so you know how the political system works there. Pretty sure I won't be able to get anything meaningful done for the project if this is the kind of response I get.
ansuz commentedon Aug 23, 2017
🤣
addaleax commentedon Aug 23, 2017
Fwiw, threading in the form of standard (Web)Workers is something I’ve been wanting to approach anyway in Node.js.
Also, while I agree with what @hashseed is saying here, I think it’s also worth mentioning that the amount of technical work required to affect language features is huge compared to the work just going on working on Node; so: If you want to change the language via forking, it’s likely better to start with a fork of a JS engine, not a fork of Node.
Fishrock123 commentedon Aug 23, 2017
@ChrisCates The repo was locked down for 24h due to spam in some other threads, as far as I can tell what you are saying in this edit is not the case.
Qard commentedon Aug 25, 2017
Adding dynamic type inference to the language would be an enormous amount of work. Like tens of thousands of human hours. It's not really reasonable to expect a small team of people just using a JS virtual machine to have the capacity to make this change on their own. You could take it to TC39 or try to build it yourself.
Threading is reasonably possible, though still quite a bit of work. There was prior effort to get web workers into Node.js, so we could probably take that and finish it.
I get what you're saying about atomic operations and low-level data structures, but those are systems-y things, and JS is just not meant for that. JS and ayo are intended more for app development purposes than systems development.
test: allow tests to pass without internet
test: allow tests to pass without internet