Discussion: v8 / nodejs relationship - The way to constant improvment #100
Comments
|
Huh? I think you're 11 days too late. |
|
@refack this isn't really far along enough to bring to the CTC. Please feel free to follow the process on https://github.com/nodejs/node-eps if you are serious about this. I recommend that you consider that many collaborators have been working together to get node running on various vms... it would seem like a step backwards to maintain our own. While I can appreciate your enthusiasm I think it might be better directed at the abi-stable-node project
Also, if you are trying to rally up support for an effort of this magnitude you are going to have an awfully hard time getting it by saying stuff like `decide we're big boys now`. Gender / binary stuff aside, it demeans the work that we are currently doing.
|
|
The people working on blink have contributed heavily to WebKit for years prior to the fork. If forking V8 is indeed a long-term option to consider, I suggest starting to contribute to V8. Otherwise the fork will simply stagnate. |
|
@refrack, We won't be forking V8 now or at any point in the foreseeable future. It simply is not something that is worth our time. The current efforts to work in close collaboration with both the fantastic V8 and ChakraCore demonstrate that there is absolutely zero need to even remotely consider the idea in any serious way. That said, the suggestion of what to do vis a vis V8 aside, the content of your post here is rather unacceptable per our conduct guidelines. We are most certainly not "big boys now". It is quite possible to raise discussion topics around the future of V8 in Node.js without genderizing the discussion. Please do so in the future. |
|
This issue is meant as a discussion starter. I do have my own opinion but I really would rather hear y'all's opinion, and make sure this was given serious thought. |
@MylesBorins Again me with my foot in my mouth 😔. I meant it as "Decide we are a mature enough project, with enough dev power" I changed the wording, but now I feel ganged up upon...
IMHO "safe and welcoming environment for all" should cover me too. The phrase "I'm a big boy now" has been used frequently in family friendly culture products, and has been considered benign by most. Anyway I'm sorry if I offended anyone.
|
refack
changed the title
|
I would like to get back to the original discussion:
@MylesBorins I thought this was more political/organizational discussion rather than an EPS, even I'm not sure it's an Enhancement
@mscdex in what sense? ChakraCore-wize?
@hashseed That's a point I agree with strongly. Do we have enough devs with hand-on V8 experience? If not, maybe that should be a CTC goal (recruiting / encouraging people to take part)?
@jasnell I feel your comment was a little dismissive of my original point. Is there really "zero need to even remotely consider the idea in any serious way", IMHO it should be something to be seriously considered constantly, and then acted upon according to our best interests (which probably are not not fork). That was exactly my original intention, to be convinced this was a conscious, logic choice. and not a default. |
|
@refack I think the simple summary in regards to this thought experiment is that "we have nothing to gain". Implementing and managing the VM would take quite a bit of effort and resources. With our current path towards vendor neutral support on VMs managing our own fork would prove a waste of resources imho. Taking the current discussions around TF + I, it is pretty clear that the V8 team is willing to collaborate with us, so I'm not sure why we would need to go thermonuclear on the relationship. What clear benefits do you think a fork would offer? |
I'm not convinced that "vendor neutral" is a benefit in itself, unless we help break the "monopoly" of V8 and help "open the market" for VMs, where they strive to outdo each other, thus benefiting all.
I'm not suggesting to go "thermonuclear", AFAIK blink has contributed to webkit, and the spin-off was done in good spirits. If you look at my original points relationship with Google is obviously a consideration. But I do think we are on par with V8 (in terms of market significance, and obviously not with the whole of Google), and should not think of ourselves as "just another client of V8". It's was actually #99 (and words like "willing to collaborate") that made me think of raising this issue. Your wording made me feel like we are chasing them, and have had the need to figure out how to accommodate their timeline, and adapt to their decisions e.g. nodejs/node##12243)
I'm don't have anything clear but maybe all the points I raised together have enough weight:
|
@jasnell that seems a little strong/abrupt/final. I agree that it seems very unlikely, but I think we should at least give reasons. IMHO: Basically for a change of that size we'd need at least:
The way to start would be to start by forking V8 and getting something working that had advantages over V8. The next step would probably be to simply contribute said changes back to V8, it's an open-source project... The only reason I could see for maintaining a fork of V8 is that there were changes that the V8 team were unwilling or unable to accept that would really benefit Node.js, so maybe if there was some key difference between Node workloads and browser workloads that meant we could get some really big wins or something.
There is work to make Node less coupled to a specific V8 version, see n-api and chakracore, which should make it easier for people to try other JS engines going forward. tl;dr if anyone thinks that there are improvements to be gained from forking V8, then fork it and we'll find out, that's the point of open-source! |
|
TBH the time we chose to launch TF+I was with Node.js' LTS in mind. The original assumption was that Node 8 does not want the new pipeline, which is part of the reason why we waited till 5.9. V8 5.8 is the perfect candidate for a last release with the old pipeline. Issues brought up in #99 only surfaced later, which is why the discussion is taking place. It's not as simple as "Node chasing V8". The current situation may be owed to some miscommunication and wrong expectations, but we are improving on that. |
As a newcomer to the "inner-circle" that was exactly my trigger. Can we afford to be sensitive to "miscommunication and wrong expectations" with such a critical part of our platform? |
|
@refack I'm missing to see the pattern in the listed pr's / issues. Yes things may have broken over time... but there is no guarantee that if we manage a VM it would be bug free. |
|
I'd be willing to bet that Google spends more money and time on v8 than the node foundation will be able to even come close to supporting. |
Trying to point out "miscommunication and wrong expectations".
@ljharb I'm not so sure (not to belittle their effort), I'd estimate it's on par... |
refack
changed the title
|
I think we can all agree that "miscommunication and wrong expectations" are bane of most software projects, how do we manage this in relation to v8? |
|
Re-titled and added interim conclusions into description. |
|
I think that we should stop the discussion on here if we are pivoting towards a general discussion of the relationship. Tldr, it is better than it ever has been. If you have particular thoughts or concerns around it we can discuss this in a new issue on the main repo, although I'm not really sure what the goal of the discussion would be |
|
@refack The communication and expectation-setting between Node.js and V8 is vastly improved over past years and getting better.
I (and others, no doubt) could go on. But basically, I'm pretty pleased with the trend of the relationship and communication between Node.js and V8. It's not perfect. But it's pretty good and getting better. Past friction and challenges have definitely not gone ignored. There are definitely external projects/entities with which I wish we had a better relationship and better communication. But V8 isn't anywhere near the top of that list. |
|
(Also, just to be clear: @refack Totally understandable that you might not know a lot or even all of the stuff in my previous comment. There's a ton of stuff to keep track of in Node.js and no one can track it all. It's especially hard for people relatively new to the project to know about stuff that has been evolving over many years.) |
refack
changed the title
|
I'm going to be explicit here. I don't think that the continuation of this discussion will result in anything positive. I've locked the issue.
|
|
Oy... My apologies. I'm currently quite a bit distracted this week with new employer business and I've missed a great deal of this conservation. My initial comments were not meant to be dismissive in any way, they were just rushed, and for that I apologize. I forgot to couch the language in terms that made it clear that I was simply offering my own personal opinion and I forgot to reread and self edit for tone. Please do accept my apology on that. Let's get the conversation back on track. The technical challenges around forking a project like V8 are immense. The level of technical expertise required in compilation, optimization, garbage collection, and so on is tremendous. We do have people working on core (my amazing former colleagues from IBM for example) who absolutely have this depth of knowledge, but there would be extremely little or no real benefit that I can see to forking V8 or any separate VM effort given the amount of work that would be involved -- given the history, and given the relationship we've built with the existing VM teams, it's far more effective (in terms of cost, time, benefit, and ecosystem stability) to continue working with and within these existing teams while focusing other efforts on stuff like the stable add-ons API. Sure, things like the mismatched shipping schedule give headaches, but they're manageable given the benefits. Regarding the suggestion that we work to give higher priority to working with the V8 team, I'd just like to point out that we already have extensive connections built with both the V8 and ChakraCore teams at several levels throughout the project. The open and productive communication channels are there, and both teams are quite responsive and willing to work with anyone of us here. Again, I apologize for the abrupt tone in my previous message. |
|
I have a question, actually two:
|
Yes, and to some degree we already expose that. Depending on what exactly you want, nodejs/node#11842 might be what you are looking for. :)
No, it’s not exposed through V8’s public API. |
|
Aside from size and content, caching bytecode is not much different than caching unoptimized JIT code. The cache data is platform-dependent in both cases because it contains more than just code/bytecode. V8 will probably never expose the AST in the API, since it's an implementation detail. You don't want to worry about API/ABI compatibility when you change the parser. |
What your saying obviously makes sense. But nodejs/node#11842 also makes sense.
IMHO that's something you (all) could reconsider. Maybe even splitting the 2 (or 3 parser-compiler-VM) into lightly dependent products, like javac/JRE, C#/CLR, JQuery/sizzle, and the list goes on. Obviously the transpiler ecosystem would rejoice, and also this may lead to independent optimizations or enhancements. Found a respectable reference PEP511 |
|
Writing a JS parser is a manageable task, and many already exist. Tools that do source-level transformations also exist, e.g. Uglify. Personally I don't think AST-level optimizations are as powerful as for example on an SSA. And making the compiler extensible to third-party extensions is certainly a non-goal. V8 is not LLVM. A big difference is that parsing/compiling happens at runtime, on the critical path to execution. |
No judgment, I totally understand your POV, but IMHO this is a node/v8 goal disparity. (feeeew I feel relieved we found one 😌 now I know my original premise wasn't totally off base) |
I'm assuming V8 does it better, and is de-facto spearheading language innovation. All those tools would greatly benefit from opening this API, not having to play catch up. |
It seems to me like userland tools are usually ahead of the JS implementations, and based on my understanding of the TC39 process that’s both by design and unavoidable: Language features are usually implemented using tools like Babel before the engines do that. |
🤔that is true... I need to think about what it means... |
|
Discussion point: Maybe nodejs should embed |
|
Hey all. I'd like to suggest that we open another thread to discuss this, I for one have been thinking for a while about more standardization around AST / intermediate representation and would be glad to discuss |
|
|
|
Can we call it "AST, IR, bytecode and friends"? 😉 |
|
nodejs/ctc should be fine |
|
I wanted to ask the
Thank you. |
|
@refack That might be easier to discuss on the corresponding issues? (For source map support that’s nodejs/node#6471, btw) |
I thought the general agreement was that we could use this as a tracking issue 🤔. |
|
@refack in general for new ideas it is better to start new threads... reopening large threads with lots of embedded context makes it easy to be distracted |
|
Gotcha 👍 |
With the knowledge that "miscommunication and wrong expectations" (e.g. The Software Crisis) is the bane of most software projects, how do we keep improving our relationship with the
v8team?My previous thought, that we should consider spinning off v8 has been rejected. So I'd like to suggest we higher-prioritize the communication channel with the v8 team. I would like this thread to be a place to raise ideas, and share experiences with the goal of achieving a more fruitful collaboration.
The text was updated successfully, but these errors were encountered: