Re: From Node.js to Go

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Ori Livneh
(Sorry, this was meant for wikitech-l.)

On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <[hidden email]> wrote:

> We should do the same, IMO.
> http://bowery.io/posts/Nodejs-to-Golang-Bowery/
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Gabriel Wicke-3
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 <[hidden email]> wrote:

> (Sorry, this was meant for wikitech-l.)
>
> On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <[hidden email]> wrote:
>
> > We should do the same, IMO.
> > http://bowery.io/posts/Nodejs-to-Golang-Bowery/
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Yuri Astrakhan-2
In reply to this post by Ori Livneh
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" <[hidden email]> wrote:

> (Sorry, this was meant for wikitech-l.)
>
> On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <[hidden email]> wrote:
>
> > We should do the same, IMO.
> > http://bowery.io/posts/Nodejs-to-Golang-Bowery/
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

James Douglas
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 <[hidden email]>
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" <[hidden email]> wrote:
>
> > (Sorry, this was meant for wikitech-l.)
> >
> > On Thu, Jan 29, 2015 at 7:20 PM, Ori Livneh <[hidden email]> wrote:
> >
> > > We should do the same, IMO.
> > > http://bowery.io/posts/Nodejs-to-Golang-Bowery/
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Bryan Davis
On Fri, Jan 30, 2015 at 7:18 AM, James Douglas <[hidden email]> 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
--
Bryan Davis              Wikimedia Foundation    <[hidden email]>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Stas Malyshev
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).

--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Chad
In reply to this post by Bryan Davis
On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis <[hidden email]> wrote:

> On Fri, Jan 30, 2015 at 7:18 AM, James Douglas <[hidden email]>
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Brion Vibber-4
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 <[hidden email]> wrote:

> On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis <[hidden email]> wrote:
>
> > On Fri, Jan 30, 2015 at 7:18 AM, James Douglas <[hidden email]>
> > 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: From Node.js to Go

Erik Bernhardson
On Fri, Jan 30, 2015 at 11:23 AM, Brion Vibber <[hidden email]>
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 <[hidden email]> wrote:

>
> > On Fri Jan 30 2015 at 10:04:39 AM Bryan Davis <[hidden email]>
> wrote:
> >
> > > On Fri, Jan 30, 2015 at 7:18 AM, James Douglas <[hidden email]
> >
> > > 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l