Temporary fork enables Node.js to optionally use the Chakra JavaScript engine • Hacker News Board

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#101

Post by kuschku » Fri, May 15, 2015, 3:07 PM UTC

pmontra wrote: post #91

kuschku wrote: post #72

Earlier quoted context omitted.

Unless you create file paths that are so long that they break the default tools of the OS. That’s the point where you went too far.

Or the OS went too short, so to say. There are two problems here. 1) Windows' limit of 260 characters per path name is incredibly small for a modern OS and that was true many years ago as well. 2) Npm approach relied on well behaved OSes and file systems allowing long path names. It's not future proof because you don't know on which OS and file system you'll need to run, maybe some limited embedded device. Ruby's rvm…

Exactly. Ruby’s solution will run even on FAT12 (which has only single-level directories), while npm isn’t really compatible.

In general, node does this quite often – their memory model also assumes they have infinite memory.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#102

Post by gsnedders » Fri, May 15, 2015, 4:08 PM UTC

dpe82 wrote: post #100

gsnedders wrote: post #55

Earlier quoted context omitted.

Well, there's one way in which the JS engine effects it: how efficiently one can call into C++ from JS. Mozilla have done a lot of work to reduce the cost of that in SpiderMonkey.

Sure, though in the grand scheme of things that penalty is pretty small when compared to the DOM operation itself. Eg. doing an appendChild() on an attached element and causing a reflow.

It depends a lot on what you're doing — if you're hitting fast-paths (esp. if you're dealing with out-of-tree nodes) it's entirely possible to end up with the JS/C++ trampoline being a significant part of the bottleneck, for much the same reasons as why Array.prototype.reduce can in several implementations.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#103

Post by efdee » Sat, May 16, 2015, 3:44 PM UTC

bryanlarsen wrote: post #99

efdee wrote: post #97

Earlier quoted context omitted.

No, it's a "bug". It is not required for loading specific versions -- those can be kept in a flat structure just as well. No need for the idiotic nesting.

IMO a flat structure would just be a confused mess. There would be hundreds of packages in that directory.

I'd rather have hundred of packages in a well sorted flat directory than the same number of packages in an "Alice In Wonderland"-style rabbit hole.

Re: Temporary fork enables Node.js to optionally use the Chakra JavaScript engine

#104

Post by pluma » Tue, May 19, 2015, 5:28 PM UTC

nivla wrote: post #80

pluma wrote: post #43

I know Microsoft apparently has changed, but just to play devil's advocate: [x] embrace [x] extend [ ] extinguish

To play the devil's advocate of the devil's advocate, how exactly would an [x]extinguish work in an open source world especially for something that is under a liberal licence (MIT vs GPL)? Isn't that the whole point of open source? That if even something gets abandoned or ignored, as long as there is still an active interest in it, it can still be used or improved upon?

You're probably aware I'm not considering it to be likely that this is Old Microsoft in action but to humour the thought experiment: I don't think they could succeed either. IE is still only barely recovering from Microsoft's history and Windows has largely been defeated by OSX both in the consumer and developer space. We're unlikely to see Microsoft Space Nazis descend upon us from a hidden moon base any time soon.

That said, there are plenty of examples of the extinguish phase not working out or resulting in less of a bang and more of a whimper. It's always been more of an infected blanket than nuclear warheads.