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 <spmalle...@gmail.com> 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 <engvall.mar...@gmail.com> > 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 <spmalle...@gmail.com> 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 < >> engvall.mar...@gmail.com> >>> 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 <spmalle...@gmail.com> >> 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 < >> engvall.mar...@gmail.com >>>>> >>>>> 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 >> >> >>
