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 > >> > >> > >> > > >