4 ms·

What is the main reason for not merging V8 and ChakraCore? It's really cool that teams from the big companies can learn tricks from each other, but as far as I

by xiphias 11y ago

What is the main reason for not merging V8 and ChakraCore? It's really cool that teams from the big companies can learn tricks from each other, but as far as I see the goal of Google and Microsoft here is to just advance Javascript in the same standard direction. Have you talked about not duplicating all efforts?

munificent 11y ago
> What is the main reason for not merging V8 and ChakraCore? Pragmatically, that's very unlikely to be effective. The two teams are culturally, physically, and temporally (time zone) distant, so Conway's Law tells us it would be very difficult for them to efficiently work on a single code artifact. It's not impossible, but it requires a lot of coordination. With something as deep as a high performance language VM, it's really hard to scale development beyond a handful of people in one room. Unlike, say, an application framework or an app, there are few easy, loosely coupled things to hack on.
Touche 11y ago
Multiple implementations is a very good thing to have in a language. V8 already has enough influence over JavaScript.
davnicwil 11y ago
> Have you talked about not duplicating all efforts? In this case the duplicated effort is desirable. You're implementing an engine to meet a spec. Duplicating the effort gives you: Competition - if there's only one implementation, what are your drivers, metrics and priorities for improving performance, spec compliance, and correctness? In practice, you're going to be deciding these things arbitrarily, by committee, on behalf of the market. If on the other hand you have two(+) competing engines, all these decisions are driven much more by the market, which is far likelier to generate better results for the market. Redundancy - If the same spec is implemented semi-independently by two different teams, then different implementations of the same features will be tried, and tested in the wild, until winners emerge for different use cases. This is incredibly powerful for innovation and optimisation, and the fact that both engines are open source only multiplies this power. Definitely by literally merging the two engines into one codebase, you'll lose these advantages almost completely, and even putting the two teams and the two projects under one organisational roof whilst still trying to keep them 'separate' would put the advantages of them being truly independent at serious risk, whilst probably not having much upside that isn't already provided by having the two codebases be open source. Two independent teams duplicating their efforts is a very, very good thing, and even better now that ChakraCore is open source.

by xiphias 11y ago

munificent 11y ago

> What is the main reason for not merging V8 and ChakraCore? Pragmatically, that's very unlikely to be effective. The two teams are culturally, physically, and temporally (time zone) distant, so Conway's Law tells us it would be very difficult for them to efficiently work on a single code artifact. It's not impossible, but it requires a lot of coordination. With something as deep as a high performance language VM, it's really hard to scale development beyond a handful of people in one room. Unlike, say, an application framework or an app, there are few easy, loosely coupled things to hack on.

Touche 11y ago

Multiple implementations is a very good thing to have in a language. V8 already has enough influence over JavaScript.

davnicwil 11y ago

> Have you talked about not duplicating all efforts? In this case the duplicated effort is desirable. You're implementing an engine to meet a spec. Duplicating the effort gives you: Competition - if there's only one implementation, what are your drivers, metrics and priorities for improving performance, spec compliance, and correctness? In practice, you're going to be deciding these things arbitrarily, by committee, on behalf of the market. If on the other hand you have two(+) competing engines, all these decisions are driven much more by the market, which is far likelier to generate better results for the market. Redundancy - If the same spec is implemented semi-independently by two different teams, then different implementations of the same features will be tried, and tested in the wild, until winners emerge for different use cases. This is incredibly powerful for innovation and optimisation, and the fact that both engines are open source only multiplies this power. Definitely by literally merging the two engines into one codebase, you'll lose these advantages almost completely, and even putting the two teams and the two projects under one organisational roof whilst still trying to keep them 'separate' would put the advantages of them being truly independent at serious risk, whilst probably not having much upside that isn't already provided by having the two codebases be open source. Two independent teams duplicating their efforts is a very, very good thing, and even better now that ChakraCore is open source.