Go @ Work

[hampton catlin]

Just thought I'd stop in and post something saying "hi" to the group.
I work at
Moovweb where we power some of the biggest e-commerce sites' mobile
experience
on our platform. Our platform has super strong demands on it and our
business is
growing at a nearly exponential rate.

This past summer, I made the decision to switch all of our internal
software to Go
after being persuaded by our Senior Architect, Zhigang Chen. Of
course, knowing that Go
was beta and that the future of the company was being bet on Go was
(and is) amazingly
stressful.

The library ecosystem was a little weak for our needs when we first
showed up so
we've since released a Regexp library called Rubex that makes regular
expressions
2-3x faster, we've released Gokogiri which is a libxml wrapper library
for XML/HTML
parsing, and GVM the go version manager so that we can work with code
bases
on various versions of Go.

A couple observations:
* New users/employees have learned Go very quickly. +20!
* Found out about breakage in 32-bit while in production. -10!
* Had to write our own libraries for some basic stuff. -5!
* Performs very well in production (only on 64-bit). +10!

Man, so much to say... this bullet list might go on and on.

I mostly just wanted to say that to us Go is not a hobbyist language.
Its a complex
build environment for us with dependency management and 5 full time
developers
writing code daily in it.

We didn't build "some small part" of our platform in Go... its the
heart of our tech.
Our SDK is a compiled binary that we are packaging and sending out to
our
clients and integration partners. Our production system is handling
millions of pages
a day and millions of dollars of ecommerce a month.

We've bet on Go big time... and will continue to bet on it. We will
continue to release
new code and we will continue to try and mature the community and tool
set so that
we can deal with real life issues.

I'd love to hear if other companies are doing a similar thing.

http://site.moovweb.com // public site
http://github.com/moovweb // public software repo

-hampton (@hcatlin)

[Paul Stead]

Interesting experience Hampton.  And gutsy!

I love go, and do play with it @home, but won't use it @ work yet, for two reasons.  The first is the lack of LDAP support.  With so much infrastructure (not just ours, but corporations worldwide) needing LDAP based authentication and access control, it's a core need for us.  And our daemons not only read the LDAP, but add, modify, and delete accounts held therein as well.  The second is more minor, but the lack of major IDE support hampers it's use a little I think, and especially in team settings.  Not just the syntax highlighting or even code completion, but the IDE's ability to "build" the program without people fiddling with make files makes using an IDE very useful.

Having said that, it's a matter of time, and I'm watching closely because I'd love to start replacing some of our "back end" infrastructure with "daemons" written in go.  Oh, there's another (admittedly) minor problem, the lack of true "daemonization" available through go.

cheers,

Paul

[Kyle Lemons]

I use Go in a production system and have a small team of go developers working on it (and we're gradually impressing other developers in other teams to learn and use it :D).  I share your experience that it developers pick up the language quickly and easily, though they often feel frustrated because it requires not only a syntax shift but a new way of thinking.  We only use 64-bit (I follow the mailing lists and know that in 32-bit there be dragons, like worse GC performance), so that never bit us.  I wrote my own YAML parser and we baked some of our own libraries, but on the whole these were helpful exercises and not major excursions.

On Fri, Mar 30, 2012 at 10:40 AM, Paul Stead <oldcoder...@gmail.com> wrote:

I love go, and do play with it @home, but won't use it @ work yet, for two reasons.  The first is the lack of LDAP support.

You're probably not the only ones.  LDAP is the sort of thing that should be written and maintained by a person or team who knows it well and uses it heavily, since a hobbyist may not have the requisite knowledge to make a good implementation.  (*hint hint*)

 

 With so much infrastructure (not just ours, but corporations worldwide) needing LDAP based authentication and access control, it's a core need for us.  And our daemons not only read the LDAP, but add, modify, and delete accounts held therein as well.  The second is more minor, but the lack of major IDE support hampers it's use a little I think, and especially in team settings.  Not just the syntax highlighting or even code completion, but the IDE's ability to "build" the program without people fiddling with make files makes using an IDE very useful.

Having said that, it's a matter of time, and I'm watching closely because I'd love to start replacing some of our "back end" infrastructure with "daemons" written in go.  Oh, there's another (admittedly) minor problem, the lack of true "daemonization" available through go.

I have yet to find the lack of an ability to detach fully from a shell to be a problem.  Go programs run fine unattended and when started from things like init or crontab.

 

cheers,

Paul

On Fri, Mar 30, 2012 at 10:27 AM, hampton catlin <hca...@gmail.com> wrote:

Just thought I'd stop in and post something saying "hi" to the group.
I work at
Moovweb where we power some of the biggest e-commerce sites' mobile
experience
on our platform. Our platform has super strong demands on it and our
business is
growing at a nearly exponential rate.

This past summer, I made the decision to switch all of our internal
software to Go
after being persuaded by our Senior Architect, Zhigang Chen.

If I ever meet him in person, I'll buy him a beer :).  I know from first-hand experience that selling a team on a new language like Go (especially before Go 1) is no easy task.

I think you may be looking for some reassurance here... I don't think the Go team (nor the 200+ contributors) think it is or think it should be a language for hobbyists.  When you look at the brain trust behind the language itself, I think it's safe to say that the language is (and will remain for the foreseeable future) designed to run real software in real production environments and do real work.  The fact that it is also has great hobby and teaching potential is a bonus, but probably also a side-effect.

[Benny Siegert]

On Fri, Mar 30, 2012 at 19:40, Paul Stead <oldcoder...@gmail.com> wrote:
> Not just the syntax highlighting or even code completion, but the IDE's
> ability to "build" the program without people fiddling with make files makes
> using an IDE very useful.

Makefiles are gone. "go build" is where it's at.

> Oh, there's another (admittedly) minor problem,
> the lack of true "daemonization" available through go.

daemontools is a good solution for this. It does the daemonization and
restarts the service automatically if necessary.

--Benny.

[Rob Lapensee]

from Kyle:

>and know that in 32-bit there be dragons

are there still issues in go1?
does anyone know of any links to know issues on 32-bit?
I already know about issue "909".

I have a Go program running on a 32-bit Linux that I don't think I can
change to 64-bit.
so far no problems, but it has not been running long and it is a very
small program.


On Mar 30, 2:01 pm, Benny Siegert <bsieg...@gmail.com> wrote:

[Kyle Lemons]

On Fri, Mar 30, 2012 at 5:11 PM, Rob Lapensee <robl....@gmail.com> wrote:

from Kyle:

>and know that in 32-bit there be dragons

are there still issues in go1?
does anyone know of any links to know issues on 32-bit?
I already know about issue "909".

I have a Go program running on a 32-bit Linux that I don't think I can
change to 64-bit.
so far no problems, but it has not been running long and it is a very
small program.

Mostly the garbage collector (pinning, esp) and lower memory limits. 

[James McKaskill]

On Fri, Mar 30, 2012 at 13:40, Paul Stead <oldcoder...@gmail.com> wrote:
> Interesting experience Hampton.  And gutsy!
>
> I love go, and do play with it @home, but won't use it @ work yet, for two
> reasons.  The first is the lack of LDAP support.  With so much
> infrastructure (not just ours, but corporations worldwide) needing LDAP
> based authentication and access control, it's a core need for us.  And our
> daemons not only read the LDAP, but add, modify, and delete accounts held
> therein as well.

Haven't gotten around to cleaning it up, fully documenting etc, but
https://github.com/jmckaskill/goldap does have the basic protocol and
search going. I wrote it up awhile ago so that I could do kerb+ldap
authentication/authorization against an active directory server.
Adding add, modify, and delete commands should be fairly straight
forward.

-- James

[Saul Hazledine]

On Friday, 30 March 2012 19:40:47 UTC+2, oldCoderException wrote:

I love go, and do play with it @home, but won't use it @ work yet, for two reasons.  The first is the lack of LDAP support.  With so much infrastructure (not just ours, but corporations worldwide) needing LDAP based authentication and access control, it's a core need for us.  And our daemons not only read the LDAP, but add, modify, and delete accounts held therein as well.  

Its not a pure solution but wouldn't it be relatively easy to wrap the OpenLDAP client libraries[1] using cgo? 

[1] http://www.openldap.org/software/man.cgi?query=ldap

[Paul Stead]

I have to admit, I'm a bit of a purist.  :)   And yes, in a pinch I could do that I suppose.  But each time you fall back on that approach, I think you lessen the argument for going with go in the first place, just a little bit.  When I get a chance I'll take a look at what James has (posted in this thread), but for now I'm using go on personal projects to learn and come up to speed and work will just have to wait.

thanks,

Paul

[Paul Stead]

Looks very promising indeed James!  I haven't the time to dive in right now, since I'm in the "use go on personal projects to learn" phase @ home and @ work I have two other major projects ongoing (both web based).  However, when it's time to start looking seriously at work, I'll definitely revisit it.   As I mentioned, with so many organizations using LDAP and AD for their authentication, access control, and various other directory services, I'm sure a pure go implementation of the protocol is going to be highly desirable.

thanks much,

Paul

[James McKaskill]

On Apr 1, 2012, at 10:45 , Paul Stead wrote:

>
> I have to admit, I'm a bit of a purist. :) And yes, in a pinch I could do that I suppose. But each time you fall back on that approach, I think you lessen the argument for going with go in the first place, just a little bit. When I get a chance I'll take a look at what James has (posted in this thread), but for now I'm using go on personal projects to learn and come up to speed and work will just have to wait.

Amusingly enough, I actually initially started out with a wrapper around openldap, but quickly found it a pain to work with and rewrote it in go [1]. Specifically getting a pure go kerberos and cyrus-sasl to talk was annoying. The only way I could come up with was to write the credential out to a credential cache and then set an environmental variable to tell cyrus where to find it. This was really problematic if you had multiple kerberos credentials in multiple threads.

[1]: https://github.com/jmckaskill/goldap/commit/019ffe767f3314b7351f9e2bd2b85cb792622bf8

-- James

[Kiswono Prayogo]

Hi, if I may ask, what language do your company previously use before switch to Golang?

[Lars Lehtonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Saturday, 31 March 2012 00:27:36 UTC+7, hcatlin wrote:
>>
>> Just thought I'd stop in and post something saying "hi" to the group.

Kiswono Prayogo <kis...@gmail.com> wrote:
>
> Hi, if I may ask, what language do your company previously use before
> switch to Golang?

After almost five years, I suspect he has forgotten.

- ---
Lars Lehtonen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJYR0ymAAoJEIE31HTrywTy69MH/iba49/xSPz4Ux7sXlih8lgA
CmUYknFZwisszl32iENiCBrg12ZwkB28W3bZquVHZgQ6JzFs+mzN+7TMoQTpRZlT
Bxd/mx/NLo0++KD7580kCDRpfr6/UhhNFR2E01Lub7okqIZmbziutflzGN4UR3Ka
s+pkb2RkFqGFg9aEKbfwkga/kIjcjB4+OQd+dU5scBHrMV1mHtdOI5btURH+Y/pW
K5rVmMuLUTMen76MIq4JoyjsJ0czt3p+hqeo0dQtnGhI21Z8ijd/XN2VpDCa5OJj
T3ASQmSCB+5K4sNQ73jamE3Xcv/dZfDd+elytQysWXXQBSxjYVaiR4q6L30NpV4=
=x9bd
-----END PGP SIGNATURE-----

[je...@activestate.com]

Hi  Hampton,

I can assure you some big bets are being laid on Go as it has so much going for it. My thoughts are here (I'm product guy at ActiveState) and why we at ActiveState are "all-in" on Go: http://bit.ly/2gD4zxp

Cheers,

-JR

[Mandolyte]

Will ActiveGo come packaged with common database drivers Oracle, Postgresql, etc. and the usual assortment of NoSQL databases?

[je...@activestate.com]

Yes, drivers for all major databases including NoSQL.

-JR