
A JavaScript parser and interpreter written in Go - scapbi
https://github.com/robertkrimen/otto
======
ek
A couple years ago for a programming languages course, we wrote a bytecode
compiler and interpreter for a JavaScript-like language we were using in the
class (objects, prototype-based inheritance, higher-order functions, etc), and
we initially started building it in Go, but the biggest thing that made us
switch to C++ at that time was the fact that Go didn't have a straightforward
union type.

It looks like this interpreter is using tagged unions for values, and using
the empty interface to emulate a union type. I seem to remember that we may
have read something at the time that recommended using the empty interface
instead of unions, though I don't remember for sure. Nice to see some
interpretation efforts finally being realized in Go!

~~~
jerf
Sum Types in Go -
[http://www.jerf.org/iri/post/2917](http://www.jerf.org/iri/post/2917)

It's less convenient than writing a compiler in Haskell, but then, what isn't?
It does give you reasonable type safety, though. (Again, don't say that where
a Haskell programmer is listening, but it's at least decent.)

~~~
zik
Thanks. That was really interesting.

------
ebilgenius
This is the most Hacker News sounding title I've ever heard.

~~~
ihsw
No, there's not enough Redis here. _It needs more Redis._

~~~
nl
Haskel!

~~~
carterschonwald
Its actually really easy to get involved in hacking on GHC, the main Haskell
compiler. Seriously, its as easy as taking some time to just try to build
current head and report any build problems!
[https://ghc.haskell.org/trac/ghc/wiki/Building](https://ghc.haskell.org/trac/ghc/wiki/Building)

I'm actually really excited by all the people starting to jump in and try to
learn/help. We've even got 2 really smart high schoolers doing some amazing
contributions to GHC recently.

seriously: its easy to get involved in hacking on interesting open source
projects. Just choose one you care about and stay excited by, and dig in!

------
jchrisa
We use this for the sync function interpreter in Sync Gateway. Robert has been
very helpful and responsive with pull requests etc. thanks!

Edit to add link to example code using Otto
[https://github.com/couchbase/sync_gateway/blob/master/src/gi...](https://github.com/couchbase/sync_gateway/blob/master/src/github.com/couchbaselabs/sync_gateway/channels/sync_runner.go)

~~~
jzelinskie
Thank you for being one of the few gophers that put newlines between standard,
third party, and local imports. I wish gofmt forced that standard on people.

~~~
gyepi
It is a useful convention in C and C++ to group includes, but I don't see the
benefit in Go.

Since gofmt sorts imports, the grouping is soon undone.

In any case, it is quite easy to distinguish the three kinds of imports if
local imports share a common prefix or set of prefixes.

Am I missing something here?

~~~
codebeaker
It's possible that if you have packages that understand flags (config package,
with flags in init(), for example) that if you include it _after_ the testing
package, or before. One of them won't accept flags. (because flag.Parse() has
already been called)

~~~
1631-
You can't rely on the order of imports initialization anyway. See
[http://golang.org/ref/spec#Program_execution](http://golang.org/ref/spec#Program_execution)
.. I believe that's also the reason, you shouldn't call `flag.Parse()` in
`init()`

------
recuter
Alright, 90 points, most comments being meta about the title so I'll be the
brave one and ask: What is this actually good for?

I can't think of any reasonable use case. Grab little NPM ditties and
incorporate them into your Go binary - Javascript to Go becomes as Lua is to
C? Somebody enlighten me.

Edit: Not that this _needs_ a use case per say, just that the intent behind it
is underspecified enough for me to wonder about it.

~~~
Loic
In the case of web application, you can have the same templating engine
running in the browser and in the server. This means rendering the full HTML
at the server level if needed or part of it or just at the browser level. You
get a bit of freedom. It is painful to manage two different templating engines
between the server and browser sides.

~~~
yeukhon
I don't get it. Are you saying - okay let's replace the javascript run time in
today's browser to this version in Go?

~~~
furyofantares
I don't think he's saying that. I think he's saying your Go server could
execute similar JavaScript as the client executes.

Imagine a highly dynamic web page, beyond the initial page load when you
interact with the page javascript executes the user's actions then rewrites
large chunks of the page. As a developer, you need to write code on your
backend that knows how to render the initial HTML for the page, but then you
have to duplicate this functionality in JavaScript since the client needs to
be able to render any chunk of the page that changes in response to a request.

You have a few options as a developer here. You can live with maintaining two
code paths in different languages that do essentially the same thing. Or you
can get rid of the backend rendering entirely, making your page less friendly
to no-script users and web crawlers (and sometimes making the site flicker a
bit as content gets loaded initially for all users.)

Or you can use shared code on the backend and the client for rendering HTML by
having a backend that speaks JavaScript.

------
runn1ng
Isn't there also a Go parser and interpreter written in JavaScript?

~~~
jheriko
Paradox!!!! Infinite loop!!!

Oh, wait causality doesn't work that way. Never mind. :P

------
fabriceleal
I have no idea how to really ask this, but does it uses continuation-passing
style [0] to execute expressions? I tried to search for "cps" or
"continuation" in the repo, but no luck. I also don't really have the time
right now to go dig through the source.

[0]: [http://en.wikipedia.org/wiki/Continuation-
passing_style](http://en.wikipedia.org/wiki/Continuation-passing_style)

~~~
barrkel
Most languages don't have reliable enough tail call elimination to implement
CPS without trampoline techniques to get rid of the excess stack frames, which
in turn has a fairly hefty performance impact unless you're using it for
something high-level like async callbacks.

------
riobard
It would be nice to have some rough performance numbers to compare with
existing JS engines.

------
omeid2
Someone please bind the Go Net and IO and there you have a Node.js-esque-Go-
Hybrid.

Not serious. haha.

~~~
borplk
Feed from node to go channels ... and then fly it on top of gevent async
overload!

------
Goranek
Can someone explain to me whats wrong with using V8 in Go? I mean what's the
point in building js interpreter in Go, when you already have a better one
made.

~~~
BMorearty
What's the point of starting anything new, when something like it already
exists? Why become a doctor when there are already good doctors? Why write a
book when there are already good books? Why sing a song when somebody else
already sings it better?

~~~
Goranek
By putting in the context the amount of money and number of one of the best
programmers in the world building a V8, building a Go V8 alternative is
probable not a best business choice unless you're a huge company with clear
goals

------
Aardwolf
Now someone must make a Go interpreter written in JavaScript, so you can
JavaScript while you Go while you JavaScript while you ...

------
oelmekki
Does this aim to compete with v8 implementations for high level products
usable by non go developer (I think qtwebkit, here), or is it just a mean to
have js integration in go for small low level scripting ?

~~~
mseepgood
Obviously the latter. Otherwise it would have to be a JIT compiling VM, not a
simple interpreter.

------
scosman
the perfect hacker news title

~~~
ChronosKey
Show HN: How a JavaScript parser and interpreter written in Go allowed my
startup to succeed and Why your company should switch to Go

~~~
mushroomhead
Show HN: A JavaScript parser and interpreter written in 30 lines of Go

------
yOutely
This is not a good thing nor will it lead to good things.

~~~
1631-
You say that, and yet here we are commenting on a forum? written in a Arc, a
language implementation that wasn't strictly _required_.

