Go + V8 or so, like Nashorn with JVM?

[Maarten Koopmans]

....see  subject.

From an app server perspective, it would be *very* interesting if we had a JS engine in Go that could expose Go libraries as Javascript calls in the JS engine.

Has anything like this been done before?

--Maarten

[Brad Fitzpatrick]

https://github.com/robertkrimen/otto

https://github.com/ry/v8worker / https://news.ycombinator.com/item?id=9285407

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Konstantin Khomoutov]

On Thu, 9 Apr 2015 06:14:10 -0700 (PDT)
Maarten Koopmans <maarten....@gmail.com> wrote:

> ....see subject.
>
> From an app server perspective, it would be *very* interesting if we
> had a JS engine in Go that could expose Go libraries as Javascript
> calls in the JS engine.

Why would it be very interesting?
I have no experience with Nashorn (supposedly it exposes Java libs to
some JS layer) but I'm tempted to know what would really be your use
case.

[Henrik Johansson]

Nashorn is the JavaScript engine in HotSpot.
It could be neat to have easy execution of JavaScript in a Go program. Lot's of use cases can be thought of.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.

[andrewc...@gmail.com]

otto is written in Go, so can handle go objects really well. I personally don't like the Javascript and Lua interpreters that are currently used.

Personally I want to see a clojure inspired scripting language with a thread safe interpreter written in Go. Having pervasive immutability at that level would make it good for introspection of running systems.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[andrewc...@gmail.com]

To clarify, I don't like them because they don't have proper facilities to safely interact with concurrent code.

[mattn]

another one https://github.com/mattn/go-v8

[Konstantin Khomoutov]

On Thu, 09 Apr 2015 15:23:55 +0000
Henrik Johansson <dahan...@gmail.com> wrote:

> Nashorn is the JavaScript engine in HotSpot.
> It could be neat to have easy execution of JavaScript in a Go program.
> Lot's of use cases can be thought of.

You merely waved hands about "lots of use cases" just like the OP
did. ;-) Sorry, but I'd like to hear about one or two real
non-imaginary use cases for this scheme. I'm honestly not trolling.

[Henrik Johansson]

Yes well I don't use it myself so I can not give any hands on use case. This is of course true for many things but it is not hard to envision possible use cases. I have used embedded interpreters in real projects before. For example we once exposed an interface for business analysts to perform ad hoc calculations on various data sets and they picked the pseudo-real language pretty fast.

[Roberto Zanotto]

Not exactly what you asked for... but you might want to take a look at gopherjs, a Go to javascript compiler. With gopherjs you can mix Go and javascript code and use javascript libraries as well as goroutines and almost every package from the Go standard library. Everything gets compiled down to javascript and you can run it with nodejs or even in the browser.

[Benjamin Measures]

On Friday, 10 April 2015 12:25:53 UTC+1, Konstantin Khomoutov wrote:

On Thu, 09 Apr 2015 15:23:55 +0000 Henrik Johansson <dahan...@gmail.com> wrote:
> Nashorn is the JavaScript engine in HotSpot.

I'd like to hear about one or two real non-imaginary use cases for this scheme.

One example is to be able to use the same code for the front-end as for the back-end in things like input validation.

That said, it is my opinion that the back-end can do all the validation for the front-end if response times are good, so side-stepping this use-case.