Hi, To extend this conversation with more reasoning…
Note that we are trying to make the distinction between driver and language strong. Why? GraphTraversal is but one "DSL" for TinkerPop (albeit the most popular). However, if someone creates SocialTraversal for their particular application and want to use Go, they would make a SocialTraversal Go language variant and then choose the particular Go driver to use for communication. As such, a Go driver may be used by numerous language variants, not just GraphTraversal! Thus, making it easy for anyone to plug and play your Go driver into their Go-based query language kills lots of birds with one stone. Moreover, imagine someone wanting to use SPARQL (https://github.com/dkuppitz/sparql-gremlin) or Graql (http://mindmaps.io/) in Go. Your Gremgo driver would be used by them as well... Thanks Marcus for the driver… now bring on the Go variant! :) … Its very easy to do if you understand Java reflection: http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/#using-python-and-gremlin-server The first code block at the URL reference is the Groovy source code to generate a non-JVM Python language variant. It ultimately generates this file: http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/resources/gremlin-python.py (which uses gremlinclient as its driver -- https://github.com/davebshow/gremlinclient) Take care, Marko. http://markorodriguez.com On May 9, 2016, at 7:43 AM, Marcus Engvall <[email protected]> wrote: > I agree, I think that if I were to write a potential GLV in Go it would be > some kind of wrapper around Gremgo, so having a well-functioning driver is > essential for any further development. > >> On 09 May 2016, at 13:23, Stephen Mallette <[email protected]> wrote: >> >> Well - the driver was crucial. Doing that first makes sense to me. Without >> that, the Go GLV itself wouldn't be terribly useful. >> >> On Sun, May 8, 2016 at 5:27 PM, Marcus Engvall <[email protected]> >> wrote: >> >>> I was considering doing a Gremlin language variant in Golang, but I came >>> to the conclusion that it would take a lot of time and effort and I am not >>> quite sure how it would be implemented properly. Thus, I decided that I’d >>> focus on making gremgo a driver rather than a language variant seeing as >>> all I really wanted at the time was an efficient and no-fuss way of issuing >>> queries to Gremlin Server. I may write a language variant in Golang in the >>> future as a separate library, but as of now the priority for me is to make >>> gremgo as a Gremlin driver as fully-functioning as possible. >>> >>>> On 8 maj 2016, at 20:27, Stephen Mallette <[email protected]> wrote: >>>> >>>> Thanks for that explanation. I"m always curious about why new drivers and >>>> libraries pop up for the same language. Sometimes it's because there's >>>> legitimately something different in the approach, sometimes it's because >>>> the author of the new driver didn't know the existing one was under >>>> development, etc. I know that the go-gremlin driver was a somewhat >>>> incomplete work as the author had to move on to other things, so perhaps >>>> that had something to do with the inefficiency. >>>> >>>> btw, any thoughts on what it would take to do a Go Gremlin Language >>> Variant >>>> ( >>> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/tutorials/gremlin-language-variants/ >>>> ) to pair with gremgo? >>>> >>>> On Sun, May 8, 2016 at 10:07 AM, Marcus Engvall < >>> [email protected]> >>>> wrote: >>>> >>>>> I was originally planning on using the other driver ( >>>>> https://github.com/go-gremlin/gremlin < >>>>> https://github.com/go-gremlin/gremlin>) for a project, but upon >>> examining >>>>> the code I discovered that the library opens a new connection every >>> time it >>>>> makes a request and does not have a connection pool to keep existing >>>>> connections alive. The result is an inefficient driver that would >>> probably >>>>> bottleneck as it scales, so I wrote a new driver designed with scale and >>>>> concurrency in mind which uses basic connection pooling and an extensive >>>>> use of goroutines to maintain efficiency. >>>>> >>>>>> On 8 maj 2016, at 15:44, Stephen Mallette <[email protected]> >>> wrote: >>>>>> >>>>>> Thanks for sharing your work here. I don't see a problem adding it if >>>>>> others don't. It will be nice to reference a Go driver and have >>> coverage >>>>>> for that language. >>>>>> >>>>>> As a separate question, is there any difference between your work and >>>>> this >>>>>> Go driver: https://github.com/go-gremlin/gremlin >>>>>> >>>>>> On Sun, May 8, 2016 at 8:45 AM, Marcus Engvall < >>> [email protected] >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I’m working on a driver for Gremlin Server in Golang and I recently >>>>>>> released a working version of it on GitHub ( >>>>>>> https://github.com/qasaur/gremgo <https://github.com/qasaur/gremgo>). >>>>> It >>>>>>> is still in an early development phase, but it works fine for basic >>>>>>> querying to the database at the moment and is designed in a way to >>> allow >>>>>>> for fast concurrent querying. >>>>>>> >>>>>>> With that being said, I was wondering if it would be possible to list >>>>>>> gremgo as a Golang driver on the TinkerPop main page? I looked over >>>>> some of >>>>>>> the requirements for listing a driver and it looks like gremgo >>> fulfills >>>>>>> these requirements. If not, I'd be happy to hear any concerns. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>> >>> >>>
