(Sorry, this was meant for wikitech-l.)
On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh ori@wikimedia.org wrote:
We should do the same, IMO. http://bowery.io/posts/Nodejs-to-Golang-Bowery/
I'm personally more excited about Rust. It is a true systems language with a modern type system, does away with the GC for more predictable performance and generally outperforms Go on CPU-bound tasks. It could actually become an interesting option for a highly parallel Parsoid 2.0 version once its 1.0 is out of the door. The Mozilla folks have built solid PEG and DOM libraries, which are important for that task.
In any case, I see little benefit in porting existing Node code to Go right now. The performance gains are marginal, and the cost of language fragmentation is real. We have a large number of JS developers, and it looks like the web is not going to move away from JS any time soon. Modern JS with promises and generators is also quite a bit nicer than old-style callbacks, and we are seeing speed-ups of around 10% with io.js.
Gabriel
PS: Wikia are building an auth service in Go https://github.com/Wikia/helios/, but have otherwise standardized on Java for now.
On Thu, Jan 29, 2015 at 7:21 PM, Ori Livneh ori@wikimedia.org wrote:
(Sorry, this was meant for wikitech-l.)
On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh ori@wikimedia.org wrote:
We should do the same, IMO. http://bowery.io/posts/Nodejs-to-Golang-Bowery/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Language fragmentation is always fun, but, as with any new one, my concerns lie in the environment - is there enough tools to make the advertised benefits worth it, does it have a decent IDE with the smart code completion, refactoring, and a good debugger? Does it have a packaging/dependency system? How extensive is the standard library, and user contributed packages. How well does it play with the code written in other languages? The list could go on. In short - we can always try new things as a small service )) And yes, Rust also sounds interesting. On Jan 29, 2015 7:22 PM, "Ori Livneh" ori@wikimedia.org wrote:
(Sorry, this was meant for wikitech-l.)
On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh ori@wikimedia.org wrote:
We should do the same, IMO. http://bowery.io/posts/Nodejs-to-Golang-Bowery/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options.
Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch?
On Thu, Jan 29, 2015 at 9:18 PM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Language fragmentation is always fun, but, as with any new one, my concerns lie in the environment - is there enough tools to make the advertised benefits worth it, does it have a decent IDE with the smart code completion, refactoring, and a good debugger? Does it have a packaging/dependency system? How extensive is the standard library, and user contributed packages. How well does it play with the code written in other languages? The list could go on. In short - we can always try new things as a small service )) And yes, Rust also sounds interesting. On Jan 29, 2015 7:22 PM, "Ori Livneh" ori@wikimedia.org wrote:
(Sorry, this was meant for wikitech-l.)
On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh ori@wikimedia.org wrote:
We should do the same, IMO. http://bowery.io/posts/Nodejs-to-Golang-Bowery/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdouglas@wikimedia.org wrote:
I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a statically typed language, it might be interesting to investigate and compare some of the different options.
Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't be a huge diversion, but I'm quite unfamiliar with what's in place now. Have we dabbled in Hack since the HHVM switch?
I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think. Changing from PHP to Hack only requires changing the opening `<?php` to `<?hh`. Today what Hack gives you is some syntactic sugar for various common idioms from the Facebook internal code base and much stronger typing. The last time I saw someone asking if it was faster on #hhvm the answer was "not yet". Whether strong typing is a pro or a con of Hack vs PHP seems like a religious debate that I'll try to stay out of until the issue is forced. The bits most likely to be of interest in the short term are the `async` and `await` keywords [0] and possibly the Continuation class [1] which makes creating generators easier than the PHP Iterator interface.
[0]: http://docs.hhvm.com/manual/en/hack.async.php [1]: http://docs.hhvm.com/manual/en/hack.continuations.php
Bryan
Hi!
The last time I saw someone asking if it was faster on #hhvm the answer was "not yet". Whether strong typing is a pro or a con of Hack vs PHP seems like a religious debate that I'll try to stay out of until the issue is forced. The bits most likely to be of interest in the short term are the `async` and `await` keywords [0] and possibly the Continuation class [1] which makes creating generators easier than the PHP Iterator interface.
PHP 5.5+ has actual generators: http://php.net/manual/en/language.generators.overview.php
The typed code would not be faster by itself unless some optimizations actually using type information would be done (not sure if HHVM has such optimizer), but that would require writing actually typed code which would not be PHP of course. And this probably will be useful only for scalar types, since there's not much happening at runtime with non-scalar typing that can be eliminated by stronger types (for scalar types, conversions and type branches in operators, parameter passing, etc. can be eliminated).
On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis bd808@wikimedia.org wrote:
On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdouglas@wikimedia.org wrote:
I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a
statically
typed language, it might be interesting to investigate and compare some
of
the different options.
Regarding Yuri's point about tools, what would it take to integrate Hack into the current MediaWiki build processes? It *seems* like it wouldn't
be
a huge diversion, but I'm quite unfamiliar with what's in place now.
Have
we dabbled in Hack since the HHVM switch?
I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think.
Yeah, I'd -2 anything that required Hack in core.
However if an extension wants to experiment they probably could. I was already thinking of trying some Hack in something WMF-specific like a Wikimedia* extension.
-Chad
Hmm, IIRC using Hack means you can't use xdebug with Zend PHP ... is debugging with HHVM in PhpStorm possible yet/soon? (I just figured out the debugger setup with Zend PHP and MediaWiki-Vagrant, and it's wonderful to have a debugger in PHP :D )
-- brion
On Fri, Jan 30, 2015 at 11:14 AM, Chad innocentkiller@gmail.com wrote:
On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis bd808@wikimedia.org wrote:
On Fri, Jan 30, 2015 at 7:18 AM, James Douglas jdouglas@wikimedia.org wrote:
I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a
statically
typed language, it might be interesting to investigate and compare some
of
the different options.
Regarding Yuri's point about tools, what would it take to integrate
Hack
into the current MediaWiki build processes? It *seems* like it
wouldn't
be
a huge diversion, but I'm quite unfamiliar with what's in place now.
Have
we dabbled in Hack since the HHVM switch?
I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think.
Yeah, I'd -2 anything that required Hack in core.
However if an extension wants to experiment they probably could. I was already thinking of trying some Hack in something WMF-specific like a Wikimedia* extension.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Jan 30, 2015 at 11:23 AM, Brion Vibber bvibber@wikimedia.org wrote:
Hmm, IIRC using Hack means you can't use xdebug with Zend PHP ... is debugging with HHVM in PhpStorm possible yet/soon? (I just figured out the debugger setup with Zend PHP and MediaWiki-Vagrant, and it's wonderful to have a debugger in PHP :D )
-- brion
The xdebug remote debugging was unstable in 3.3, as of 3.4 it has now considered stable. I have not actually tried it myself though. It looks like the hhvm version we are packaging is 3.3.1, so in vagrant it will be a bit unstable atm.
Erk B.
On Fri, Jan 30, 2015 at 11:14 AM, Chad innocentkiller@gmail.com wrote:
On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis bd808@wikimedia.org
wrote:
On Fri, Jan 30, 2015 at 7:18 AM, James Douglas <jdouglas@wikimedia.org
wrote:
I wonder whether Go's lack of parametric polymorphism might make it a pretty tough sell. Given the potential benefit of introducing a
statically
typed language, it might be interesting to investigate and compare
some
of
the different options.
Regarding Yuri's point about tools, what would it take to integrate
Hack
into the current MediaWiki build processes? It *seems* like it
wouldn't
be
a huge diversion, but I'm quite unfamiliar with what's in place now.
Have
we dabbled in Hack since the HHVM switch?
I'm not aware of any WMF/MediaWiki work being done in Hack yet. Putting Hack into MediaWiki's core would be controversial but a stand alone service/app could easily choose to use it I think.
Yeah, I'd -2 anything that required Hack in core.
However if an extension wants to experiment they probably could. I was already thinking of trying some Hack in something WMF-specific like a Wikimedia* extension.
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org