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

Reply via email to