mcuadros

Could be a nice PR ;)

Nope I don't want to have any complex like a execution tree, this is just a small replacement of the kind of jobs you want to run with cron

I created Ofelia, being getting Vixie crond inside of a container is a nightmare (at least when I started the project, 1 year ago), with Ofelia is simply tasks.

As explained in the README, is a character from Mortadelo and Filemon[1], she is a office manager and I though that was a good simile to a job scheduler, obviously the intent is not make fun of the fat that she is fat.

[1]https://en.wikipedia.org/wiki/Mort_%26_Phil

Yep is a very similar approach, I'm not familiar with gitgo, but we started to work on go-git before gitgo was published, so this is the reason why we have our own project instead of collaborating on a existing one.

v8worker, was one of the evaluated projects, but V8 is not very fast compiling... takes several mins.

With go-duktape, you can compile CandyJS just lake a normal Go package without any other tool or library.

Other reason is that many of the features are based on ECMA6 Proxy, something that is not supported on v8.

True in some cases I fold back to JSON: https://github.com/mcuadros/go-candyjs/blob/master/base.go#L...

But the main goal of the project is be fully transparent more than the performance. At the very beginning I was making every case by hand but this is a endless work: https://github.com/mcuadros/go-candyjs/blob/54c8beb723aa8b1b...

I will take a closer look to the NaN issue and also a closer look to your code.

BTW I made a PR to go-duktape based on you fork: https://github.com/olebedev/go-duktape/commit/65f0be48ece4f6...

the main goal of CandyJS is allow to other developers build extendable programs without the requirement of compile.

A good example could be a chan bot in Go with plugins written on JS. (like https://github.com/djosephsen/lazlo) but with CandyJS the effort to make this will be minimal, since you can use the same structures on JS and Go.

About the performance, CandyJS javascript is much slower than pure Go, since the reflection is very expensive.

A small quick bench of this example: https://github.com/mcuadros/go-candyjs/blob/master/examples/...

Pure Go: 165951 requests

CandyJS: 36304 requests

That means that CandyJS is 4,5 times slower than pure Go. Both

Hi Chris, thanks for your support. Your packages looks like very interesting, I couldn't find it before.

About the pool of workers, they share the stack? Or how you keep the same status on each.

the method and field names are converted to lowerCamelCase to be compliant with the JS coding style. Let's see if this transformation becomes a headache.

BTW this behaviour is undocumented, I will fix that.