This is not a good thing nor will it lead to good things.
Care to elaborate?
A JavaScript parser and interpreter written in Go
51–60 of 72 posts
Re: A JavaScript parser and interpreter written in Go
#52Someone please bind the Go Net and IO and there you have a Node.js-esque-Go-Hybrid. Not serious. haha.
Feed from node to go channels ... and then fly it on top of gevent async overload!
Re: A JavaScript parser and interpreter written in Go
#53Can 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.
At least two concrete reasons:
1. No cgo required. 2. Portable to any platform Go runs on that V8 doesn't.
Re: A JavaScript parser and interpreter written in Go
#54Alright, 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 a…
Reminds me of the early 2000s argument "why do we need another browser? IE is good enough".
This project may not be the fastest JS engine or the one with the most features right now, but if nothing else, it's a really nice project for learning Go and writing interpreters.
Maybe some new ideas will be explored in this engine first, because it's faster to implement them in Go than in the (huge) V8 or other JS engines.
Having new alternatives to established software is always a good thing.
Re: A JavaScript parser and interpreter written in Go
#55Earlier quoted context omitted.
I was wondering myself why you needed a union type. Is it because JS has dynamic types ? var x = 5; x = "John Doe";
The alternative is a data structure which has N-1 empty, yet allocated, slots (N is the number of possible types.) instead you can have one field indicating the type of the variable and then your code can switch which field it accedes based off that indication. Total size is one int plus size of largest type represented.
You could potentially also have an interface that defined methods for all the basic types `interface { AsString() (string, error), etc. }` and then each basic type implements this interface and returns an error if it can't/shouldn't be represented as the requested type. A type-switch could give you the same info you get from the tag and you don't pay for type-assertions
Re: A JavaScript parser and interpreter written in Go
#56Does 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 ?
Obviously the latter. Otherwise it would have to be a JIT compiling VM, not a simple interpreter.
Re: A JavaScript parser and interpreter written in Go
#57This is not a good thing nor will it lead to good things.
You say that, and yet here we are commenting on a forum? written in a Arc, a language implementation that wasn't strictly required.
Re: A JavaScript parser and interpreter written in Go
#58Alright, 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 a…
Reminds me of the early 2000s argument "why do we need another browser? IE is good enough". This project may not be the fastest JS engine or the one with the most features right now, but if nothing else, it's a really nice project for learning Go and writing interpreters. Maybe some new ideas will be explored in this engine first, because it's faster to implement them in Go than in the (huge) V8 or other JS engines.…
I wasn't making any argument, simply asking.
Re: A JavaScript parser and interpreter written in Go
#59A 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 inter…
Casting to/from empty interfaces is kind of doing the same thing for void* pointers in C, right?
No, for once, Go doesn't have casting, it has type conversions, but they are type safe. With void * you can do anything, with interface{} you can only use the dynamic types inside the interface.
That being said, using interface{} for unions is extremely unfortunate. The bright side is that after 4 years of using Go almost exclusively, I only had to abuse interface{} only once, with compiler parsers (like the parent says). Every other time there was a better design which did not require using interface{}.
Re: A JavaScript parser and interpreter written in Go
#60A 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 inter…
Sum Types in Go - 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.)