121–130 of 324 posts
In the last couple years it seems like MS has been acting like the crazy-small-TV-shop-owner-doing-his-own-tv-ads : "Yes folks, we're open sourcing everything, cuz I'm crazy Bill". Mind you, this is good for devs finally getting access to this amazing technology!
Earlier quoted context omitted.
Competition! Now both teams have one more incentive to innovate and we get better software in the end.
As far as I understand, v8 doesn't care about node, and would never think twice about doing something that breaks the entire node ecosystem if it makes Chrome slightly faster. FWIW, they aren't even "wrong": it makes sense to me. What is interesting here is not "competition" but "someone who builds a JavaScript engine wants you as a user".
I've seen that a partial Linux support is on the roadmap, but does anyone know if there is a way to compile it with gcc or clang, or if it's on the roadmap ?
It doesn't look like it builds yet. See https://github.com/Microsoft/ChakraCore/wiki/Roadmap .
I suspect the implementation is tightly coupled to Window's ABI.
Earlier quoted context omitted.
It also means that the company can sell proprietary versions with extended functionality, and the company is therefore motivated to not allow contributions to the free code which duplicates functionality which they sell.
However, since ChakraCore is released under a permissive license (like most corporate open source projects), Microsoft could do the same thing without a CLA. It matters more when something is under a GPL variant...
The way this ends up working for Microsoft projects licensed under Apache 2.0 is that it essentially allows Microsoft to do anything with the contributions (as if it were licensed under MIT, with a liberal interpretation of the implied patent grant), but requires everyone else to continue abiding by Apache 2.0. Not exactly balanced.
EDIT: I'm totally confused about why people are having a problem with this comment.
Good that it's open source, but I found this blurb from their contributing guidelines [0] to be contribution inhibiting: You will need to complete a Contributor License Agreement (CLA) before your pull request can be accepted. This agreement testifies that you are granting us permission to use the source code you are submitting, and that this work is being submitted under appropriate license that we can use it. [0] h…
NodeJS has exactly the same restriction.
Earlier quoted context omitted.
That's what Go does. The reference of the language is [an actual document]( https://golang.org/ref/spec ), not a reference implementation. There are two compilers (gc and gccgo), and this way, no edge-case of an implementation can make its way into programmers' habits, something that tends to happen a lot with JavaScript.
What do you mean by the, "edge-case of an implementation... makes its way into programmers' habits" as something that happens a lot in javascript. Maybe I'm not understanding but I read that statement and I don't see how that applies to javascript.
This ends up with them avoiding it in general usage, which means that now "avoiding try/catch" is considered a general purpose performance tip in javascript, even though it might only apply to one engine (and the v8 team has expressed interest in trying to stop that deopt)
This might be a bad example, i'm honestly not sure how try/catch performs in other engines, i just know it deopts in V8. But the fact that i don't know if it's a javascript thing or a V8 thing speaks to my point.
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?
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.
Earlier quoted context omitted.
Don't most large organisations require something similar with their own open source projects? I know Google and Facebook do. It's just a way of confirming that you own the rights to your contribution, and that you explicitly give Microsoft permission to use it. (And if you didn't want to grant them permission, you would have no reason to contribute!)
> Don't most large organisations require something similar with their own open source projects? I know Google and Facebook do. Mozilla gets by without one. Apple's approach for managing Swift, too. > It's just a way of confirming that you own the rights to your contribution, and that you explicitly give Microsoft permission to use it. If that's all they wanted to do, they could get by with something resembling the te…
Mozilla does have one.
> Code committed by you to a Mozilla Repository, whether written by you or a third party, must be governed by the Mozilla Public License 2.0, or another license or set of licenses acceptable to the Mozilla Foundation for the Code in question.
https://static.mozilla.com/foundation/documents/commit-acces...
Swift has a much shorter one:
> By submitting a pull request, you represent that you have the right to license your contribution to Apple and the community, and agree by submitting the patch that your contributions are licensed under the Swift license.