V8worker – Minimal Go binding to V8(github.com)
github.com
V8worker – Minimal Go binding to V8
https://github.com/ry/v8worker
6 comments
By Ryan Dahl: the guy that created node.js.
I wonder what else he's been up to.
I find it interesting that many high profile "noders" have switched to Go (example [0]), but now its very creator? Wow!
As someone who's switched from (C++/Java to) node to (Python then) Go, I can understand where they're coming from though.
0: https://github.com/tj
As someone who's switched from (C++/Java to) node to (Python then) Go, I can understand where they're coming from though.
0: https://github.com/tj
It feels weird knowing I will never be 5% as productive as TJ is. (At least not without amphetamines or something.)
That's super interesting, I didn't know that he took a journey from C++ → Java → Python → Javascript → Go.
But Why Go? [1]
There are so many interesting programming languages, I'm curious why he chose go. And where do you have your information about high-profile Node.js users migrating to Go, if I may ask.
I've not used the go language yet, but a school friend was a fan of it a few years (3?) ago and started learning it. He was positive with about it, but went on with life and uses php and nodejs mainly now. However can't wait for an ArchLinux PKGFILE :)
--
[1] Faithless Feat Estelle - Why Go
https://vimeo.com/20690331
But Why Go? [1]
There are so many interesting programming languages, I'm curious why he chose go. And where do you have your information about high-profile Node.js users migrating to Go, if I may ask.
I've not used the go language yet, but a school friend was a fan of it a few years (3?) ago and started learning it. He was positive with about it, but went on with life and uses php and nodejs mainly now. However can't wait for an ArchLinux PKGFILE :)
--
[1] Faithless Feat Estelle - Why Go
https://vimeo.com/20690331
Where are they coming from?
Javascript seems like the future, not Go (speaking as a python engineer).
Javascript seems like the future, not Go (speaking as a python engineer).
This feels, apologies, slightly uninformed. JS obviously has a bright near-term future with so many engineers working on the runtime side, from Google, Mozilla, etc.
But the speed at which Go has been picked up - especially by high-traffic, massively-concurrent systems and companies like Google (obviously), Cloudflare, 6Wunderkinder, BBC, bitbucket, Digital Ocean, Disqus, Dropbox, ngmoco:), Heroku, Shopify, Tumblr, Zynga...
I realize a list doesn't a language make, (and these are just off the top of my head) but for each of these companies Go sits at the heart of the most mission-critical systems, often for extremely fast injection and analysis of huge data streams. (Funny enough, many come from a Python core, like Disqus and Dropbox, among others).
I don't think Go's splash was as big as node's, but it's found its way in to more organizations than not.
But the speed at which Go has been picked up - especially by high-traffic, massively-concurrent systems and companies like Google (obviously), Cloudflare, 6Wunderkinder, BBC, bitbucket, Digital Ocean, Disqus, Dropbox, ngmoco:), Heroku, Shopify, Tumblr, Zynga...
I realize a list doesn't a language make, (and these are just off the top of my head) but for each of these companies Go sits at the heart of the most mission-critical systems, often for extremely fast injection and analysis of huge data streams. (Funny enough, many come from a Python core, like Disqus and Dropbox, among others).
I don't think Go's splash was as big as node's, but it's found its way in to more organizations than not.
My problem with Go is the seeming masses of boilerplate in all the Go code I've seen. With ES2015 (and beyond) I can write clean code with little syntactical boilerplate in a highly functional style that can run anywhere. The only thing really missing at this point is well integrated static type checking. I feel the code should be typed, but invisible, through type inference and propagation.
> I don't think Go's splash was as big as node's, but it's found its way in to more organizations than not.
I'm having trouble understanding the second half of this statement. The two most clear readings are that over 50% of organizations use Go, or that over 50% of the organizations that have used Node now use Go (while still possibly also using Node). I doubt you intended either of these meanings. How am I misreading you?
EDIT: do you perhaps mean that over 50% of the organizations that use Node and have experimented with Go have decided to move forward with more Go projects?
I'm having trouble understanding the second half of this statement. The two most clear readings are that over 50% of organizations use Go, or that over 50% of the organizations that have used Node now use Go (while still possibly also using Node). I doubt you intended either of these meanings. How am I misreading you?
EDIT: do you perhaps mean that over 50% of the organizations that use Node and have experimented with Go have decided to move forward with more Go projects?
I think the statement themartorana is probably contextually inaccurate.
That being said, there are plenty of stories coming out about how companies are evaluating Go and seeing performance increases in mission critical application; as opposed to stories of people ripping out pieces of Go and replacing it with something more optimal for their situation.
That being said, there are plenty of stories coming out about how companies are evaluating Go and seeing performance increases in mission critical application; as opposed to stories of people ripping out pieces of Go and replacing it with something more optimal for their situation.
...is probably contextually inaccurate.
Yup, those should have been two separate statements:
1. Node made a bigger initial splash than go
2. A large number of organizations that deal with high-volume, highly-concurrent data sets and API traffic are either in production with Go, or are experimenting with it. (All the companies I mentioned have Go in production)
Yup, those should have been two separate statements:
1. Node made a bigger initial splash than go
2. A large number of organizations that deal with high-volume, highly-concurrent data sets and API traffic are either in production with Go, or are experimenting with it. (All the companies I mentioned have Go in production)
Quoting TJ Holowaychuk:
"I’ve been fighting with Node.js long enough in production now that I don’t enjoy working with it anymore unfortunately"
"In the past week I’ve rewritten a relatively large distributed system in Go, and it’s robust, performs better, it’s easier to maintain, and has better test coverage since synchronous code is generally nicer and simpler to work with."
https://news.ycombinator.com/item?id=7987216
"I’ve been fighting with Node.js long enough in production now that I don’t enjoy working with it anymore unfortunately"
"In the past week I’ve rewritten a relatively large distributed system in Go, and it’s robust, performs better, it’s easier to maintain, and has better test coverage since synchronous code is generally nicer and simpler to work with."
https://news.ycombinator.com/item?id=7987216
To me, they both sound like they are the future. They play different roles and have different strengths. A project like v8worker sounds exciting to me because we could use both in an application and get the best of both worlds.
Can someone explain motivation for this? Why would someone need Go bindings for V8? What's the practical applications of this?
Not trying to be a jerk, just plain curiosity
Not trying to be a jerk, just plain curiosity
This idea definitely has legs for what I do day-to-day. We have a data aggregation framework with hundreds of bots. Due to the fluid nature of maintaining it we use Python. The trade-off for the productivity we require is performance - we use GEvent to mitigate this to a degree.
I have already replaced parts of our suite with components written in Go, but at this point I wouldn't port the pointy end because I don't want to loose the agility that Python allows. If I could spider/parse with JavaScript and at once exploit the Go performance and concurrency features, this would be very attractive.
Funnily enough, the previous incarnation of the same solution was written in C++ with a JavaScript run-time used in exactly the same way. It predates Node.js by some years.
I have already replaced parts of our suite with components written in Go, but at this point I wouldn't port the pointy end because I don't want to loose the agility that Python allows. If I could spider/parse with JavaScript and at once exploit the Go performance and concurrency features, this would be very attractive.
Funnily enough, the previous incarnation of the same solution was written in C++ with a JavaScript run-time used in exactly the same way. It predates Node.js by some years.
Embed javascript as a scripting language into a Go app.
Build bindings to system functions in Go (e.g. write the common parts of an app in JS, run it in V8, write platform-specific things in Go).
Write the next Node.js/Io.js in Go?
Build bindings to system functions in Go (e.g. write the common parts of an app in JS, run it in V8, write platform-specific things in Go).
Write the next Node.js/Io.js in Go?
> Embed javascript as a scripting language into a Go app.
Sure, but you could already do that. There are several V8 implementations in Go you could use directly to invoke javascript code, but you'd have to pass values directly in and get return values directly out to interface between the two languages.
Sure, but you could already do that. There are several V8 implementations in Go you could use directly to invoke javascript code, but you'd have to pass values directly in and get return values directly out to interface between the two languages.
- Serve assets that need some transformation through a js script(uglify,LESS,...)
- Provide a scripting layer to an executable.
- Re-implement nodejs in Go ...
- Provide a scripting layer to an executable.
- Re-implement nodejs in Go ...
One use case I see is scriptability: You want to have the flexibility of javascript, but deploy a single binary (Go).
There are quite a few js engines/bindings already for go, like duktape, otto, go-v8, ...
There are quite a few js engines/bindings already for go, like duktape, otto, go-v8, ...
Multiple return values zomg is a tempting reason to change .
In theory one can reimplement Node on Go runtime, instead of libuv and other libraries Node uses for binding the V8 to the OS.
I imagine there would need to be some work getting this to work with Node.js/node-gyp/nan. Can anyone speak to the implications of this project and using Go bindings with node? Is this something that could possibly be done with a current version of Node/iojs? Or will it require a new version to ship with Go support built in?
> which will trigger a build of V8
This part gives me the impression changes will need to be made in Node/iojs to support Go bindings, rather than individual modules being able to plug into an existing build of V8 in Node. But perhaps I just don't understand exactly what node-gyp is doing with today's C++ bindings..
> which will trigger a build of V8
This part gives me the impression changes will need to be made in Node/iojs to support Go bindings, rather than individual modules being able to plug into an existing build of V8 in Node. But perhaps I just don't understand exactly what node-gyp is doing with today's C++ bindings..
Will V8 objects that reference Go objects, and vice versa, be properly garbage collected? How are these cycles handled by the GC?
There are shared references? I got the impression the bindings were for message passing.
> This exposes a non-blocking message passing interface to the V8 javascript engine. Go and JavaScript interact by sending and receiving messages.
> This exposes a non-blocking message passing interface to the V8 javascript engine. Go and JavaScript interact by sending and receiving messages.
I wonder if something like this could be paired up with ReactNative?