There's no guarantee that it will succeed, but the fact that they're willing to sacrifice some considerable degree of compatibility to achieve other important goals may make the project a lot easier to pull off.
I still think Unladen Swallow should have been based on V8, but as I recall that project had very strict compatibility goals that would have made a V8-based implementation impossible.
Even ignoring the extension-compatibility goal, at the time Unladen Swallow began, V8 was nothing more than an AST-based JITing interpreter, hence there were far fewer generally applicable parts of the code compared with today.
Google has pretty specific needs, so this project may be very successful internally even if it gets zero traction externally.
A lot of big software companies do this nowadays. Google and Facebook both have a lot of purpose-built software, some of which gets released as open source, that meets their needs well but is hard to use for other purposes. I guess it's still strictly better than them not open-sourcing the code, but it's definitely an existence proof that just making something open source doesn't make magic happen.
Perhaps Golang will get a VM or something similar to enable stuff like exec/eval to be implemented with rapid response times in Grumpy. The only way I've ever seen a REPL implemented for Go is by recompiling the source code via a call to "os/exec".Command for each statement or declaration entered, which gives a 1-second delay on many computers.
Not if it turns out to be usable and have a significant impact on the performance. You need to realize that at the scale Youtube works, even a small performance boost translates to huge savings in server cost.
So the worst case here is if they never improve this past their own needs (which is a pretty limited subset). But if it's successful for them, and it's opensource, I could very easily see other people who run heavy stuff on Python contributing to it and helping it grow.
That's the thing with opensource, even if Google doesn't actively work on it, others can (if it has actual value and is useful to people).
>Google essentially is moving everything to Go ...[snip]... and then module by module will rewrite it in pure Go.
I can see this happening for some core modules sure, but I think you've underestimated the work required to convert the sheer amount of Python code at Google. There is a tool inside Google which graphs the number of lines of each language in Piper; I don't think I can quote numbers from my time there but it would be no small feat, even for Google.
>To me it looks like Google essentially is moving everything to Go, and this project is to help with it.
Interesting - first time I have heard such an opinion. Why do you think it may be so? One reason I can think of, is they get more control over the languages they use.
The Go seems to be developed for their needs (well it's coming from them). It's simple to learn, it's very opinionated, how code is stored, how it is formatted etc. It seems perfect for a company that gets a lot of college graduates.
Now with Python, they still seem to stick to Python 2.7 and don't show any effort to move. TensorFlow was released for Python 2.7 and only later Python 3 support was added. Grumpy is for Python 2.7 and first issue opened asking about Python 3 support was closed with change in documentation that only Python 2.7 is supported.
To me it seems like they wouldn't stick to Python 2.7 if they were planning on continuing using Python. It seems like it coincides with deprecating Python 2 in 2020.
I made an agreement to myself to never use any Google language, tool, or library after they decided to shut down google code. Google has a history of creating all of these crazy projects and then just completely abandoning them leaving the early adopters to fend for themselves. It's really bad practice and leaves a nasty taste in my mouth. That's why I haven't even tried Go. I have no interest in it. As soon as Google develops some other language they'll drop Go like a hot potato and everyone using it in production will be forced to rewrite or stagnate.
Look at AngularJs for a more recent example.
Add to this that Google has some of the worst versioning practices I've ever seen and you get a recipe for destruction.
