How has your company adopted Go ?

[Tieson Molly]

What arguments or factors have contributed to your company adopting Go?

Many businesses see switching to a new language or even using a new language side by side with their existing  language choice as a business risk.

  Best regards,

  Ty

[gary.wi...@victoriaplumb.com]

It should always be 'use the best tool for the job'. If Go seems like a good fit for a task, use it. We've used Go for creating web services accessed via restful API's and it works great. I've personally used Go to create command line utilities to help with development. We've also used it to prototype systems before using other languages.

We don't see it as a risk but as a competitive advantage.

[Justin Israel]

Here are some high level slides I put together, for a demo about the timeline of my company (Weta Digital) getting introduced to Go

talks.godoc.org/github.com/justinfx/demos/go_at_weta/go_at_weta.slide

It was a slow process, and it wasn't any kind of full switch over. Just using the right tool for the job, as Gary just said. It seems best to not try and just cut everything over to it in one move, but to write piece by piece and let Go naturally prove it's worth and gain confidence and supporters. 

Then again my company is not your company, and the impact of using different languages, as well as the approach to introduce a new language, may be quite different. 

Justin 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Diego Medina]

In our case, our original product was a web app, written in Scala, as our data starting growing, we had to move from real time queries to our database plus some data manipulation to precalculating/storing the data in a ready to server manner.

This worked well for a while, but eventually our backend process was consuming large amounts of memory. This was the a good point for us to try Go, so we switch part of that processing to Go to see how it goes, worse case scenario, a crash wasn't going to affect our main product, we could still run the old code. Having a safe fallback was key for adoption.

But before we used Go at work, I personally made sure I was comfortable enough with it that I could answer any questions our team had, or at least being able to go look for the answer (this mailing list, stackoverflow, etc).

The move was great, our incoming data has grown a lot more than what it was 3 years ago, and I keep improving the go program from time to time. We still run our web application in Scala, but a few months ago we also started handling a couple of specific pages in Go, again, if those pages fail, they are not critical, so it wouldn't be a reason to stop migrating. A few weeks ago I got our CTO onboard with Go, which was a big milestone, so we'll be writing more and more of the web app in Go in the near/mid future.

In short, if your company doesn't like taking risks, you can go slow in migrating to Go, have safe guards and know where to go for help.

Thanks

Diego

[JM]

converted a web app from python to go.  performance, simplicity, and keeping the team excited were the top, and also the only other contender that had a had a chance at the time was node js which was quickly eliminated for many reasons.

I am doing consulting work for a fortune 50 company and all the new development is being done in go, moving from c++.  Also where i live many companies (some big ones) are doing rewrites in go on their core backend platforms.

[Eric Johnson]

On Monday, December 19, 2016 at 5:03:43 AM UTC-8, Tieson Molly wrote:

What arguments or factors have contributed to your company adopting Go?

My company does enough different kinds of work that the question is too broad. To some, "adoption" might imply broad usage. In practice, usage evolves over time, and use of Go is slowly increasing over time.

 

Many businesses see switching to a new language or even using a new language side by side with their existing  language choice as a business risk.

My company primarily used to use Java. In recent years we've explored options other than Java for two reasons that I can tell, because of the pressure Oracle has started putting on the Java ecosystem, and because there are many more viable options to Java than their used to be.

We looked at other JVM languages. Besides the fact that they didn't get rid of the potential licensing issues from Oracle, they also implied a lot of investment in learning new syntax and programming languages, but without any significant change in the runtime profile of the resulting programs. Seems like a very expensive effort for minimal gain.

That meant exploring the non-JVM languages. D, Rust, Go, Javascript, Python.... Go is, well, ... practical and effective in many cases.

Eric.

 

  Best regards,

  Ty

[Henrik Johansson]

For us it started with me rewriting a small service. It was done quickly and with great performance which led to curiosity from other developers which in turn led to a larger system of services being built in Go with great results. The initial usual fears about knowledge and "risks" was quickly alleviated since the team picked it up (for me quite predictably) fast and got things done very soon.

[Алексей Шаров]

We got some long-running export, it was slow and affected business, and few rewrites on current technologies didn't help. 

And made it fast by using Go. 

After this business-value everything was not fast but much easier. 

понедельник, 19 декабря 2016 г., 19:03:43 UTC+6 пользователь Tieson Molly написал:

[Haddock]

This thread is very interesting to me as I'm working exclusively with Java and am looking for ways to bring in other approaches such as using Go. Could some of you drop some few lines in what way in your company Java is combined with Go? That would give me an idea where to start experimenting in order to show some use cases to my boss.

Thanks, Haddock

[Henrik Johansson]

For us they interact exclusively through either plain http based services or via Nats, no other interactions take place. It works as expected without any particular issues. I would suggest that you start with a similar approach and create a self contained little service to show that Go not only works but runs fast and safe. If you are on the docker track try to demonstrate the outstanding startup speed by using something like Alpine or even scratch as base image.

On Wed, Dec 28, 2016, 22:34 Haddock <ffm...@web.de> wrote:

This thread is very interesting to me as I'm working exclusively with Java and am looking for ways to bring in other approaches such as using Go. Could some of you drop some few lines in what way in your company Java is combined with Go? That would give me an idea where to start experimenting in order to show some use cases to my boss.

Thanks, Haddock

--

[Eric Johnson]

Stand-alone services are definitely the way to go. Pick a small service that either is yet to be written, or is performing badly in its current Java implementation.

Eric

On Dec 29, 2016, at 12:35 AM, Haddock <ffm...@web.de> wrote:

This thread is very interesting to me as I'm working exclusively with Java and am looking for ways to bring in other approaches such as using Go. Could some of you drop some few lines in what way in your company Java is combined with Go? That would give me an idea where to start experimenting in order to show some use cases to my boss.

Thanks, Haddock

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/UE8NGYbb6ec/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Haddock]

Thanks Henrik and Eric. Replacing some service to start with bridging Java and Go through http or nats is a good idea. I'll pick that one up ;-).

[Jesper Louis Andersen]

Many businesses see switching to a new language or even using a new language side by side with their existing  language choice as a business risk.

Jespers approach to using-a-new-language-for-your-project™, a slightly adopted version of Joe Armstrongs approach:

Companies, once they get up and running, are very susceptible to the idea that risk is an evil which must be managed. Thus, anything but a startup, or something which tries to be like a startup will eventually get dragged towards a language monoculture: it is perceived to be easier to hire for, and perceived to be easier to control. True, whenever you employ a new programming language, you risk redoing the same work you already did. On the other hand, a single language also means you buy into its strengths and weaknesses, which means the monoculture has a side-effect of hurting the business.

There is a best time for making a language switch. If you have a recent project of the large and complex kind, which is bound to fail soon, you have a good opportunity for a switch. By playing the strengths of the language, by drinking coffee, and by your own perseverance, you can make magic happen. Target the kernel of the problem space, write a small solution in 72 hours as a tech demonstrator, and show management that the crux of the problem—the reason the previous project failed—is solved in this new solution. Once this gets traction, the choice of language plays a minor role. In short, the project drives the adoption, not the language itself.

The 72 hours can be extended to a couple of weeks if you have some 20% time. The key is to get a result fast though, so you can start showing off the achievement in the project. This is what gets traction in companies. Solutions, not religion. Before biting, however, it is good to make some experiments. Try rewriting small parts of your existing system in the new language, and use that to figure out where the pain-points are. For example, it might be that the (ephemeral) JSON data your send around between systems doesn't lend itself to the structure of the Go JSON decoding package. This suggests patching the existing system now, paving the way for adoption of a new system later. Another example is to build a system within the system: your new page-table algorithm for an operating system can be simulated in a user process. If you have a feed of requests, you can replay those against your experimental kernel.

Once you have made your experiments, you have cut down on the adoption time considerably, which makes it far easier to do a true solution in 72 hours. The other key factor is to understand the problem space such that succinctness becomes a major driving factor. Once you have the right structure of a program, the simplicity and elegance of a solution tend to make the software write itself, due to there being few moving parts. In Go, this usually means figuring out the right interfaces which makes you able to reassemble the code in many different ways easily. In something like Haskell, the game is to figure out what algebraic[0] properties the system has so you can part it into building blocks which can then be recombined into the solution (this is why Haskell people like to use special identifying terms for different kinds of building-block glue). Something like OCaml supports "functions at the module level:" a module takes another module as input and produces a module as output. The right solution often exploits such properties in order to achieve the same solution with less code. And simple solutions tend to outperform complex solutions in the end anyway.

Failing projects come in many forms.

A slow Python programs machinery is creaking under the normal daily load and more machines needs to be added in order to handle the pressure. A Java programs heap is growing out of bounds. Garbage Collection is stopping-the-world and hurts response times. A C++ program is dying because the junior programmer added some code which broke some undescribed assumptions about the memory state.

A system has seen a steady influx of new users, some of which use it in new ways not thought about when it was first written. A system has broken down because its algorithmic structure could handle the existing load, but not the new one.

A project can be so complex from the start, that it is doomed. But a project can also doom itself from the perception of programmers that "it cannot be done".

The key is to get into the limbo space between success and failure and then use your-poison-of-choice to move a project from limbo into success. When doing so, don't pick any project, but pick one that suits the language you wish to adopt. Go's strength is its relative sympathy to the underlying hardware: overhead of using the language is low which in turn means programs are compiled close to what the machine can efficiently execute. In addition, it is one of the few languages with a built-in concurrency story, which comes very handy on the modern server side. Finally, low-latency operation has been a goal for some time.

A good indicator of this kind of thinking is to look 7 years back, to the genesis of the Node.js project. There is nothing remarkable about Node.js, except that it combined a number of useful technologies into a stack: V8, an event loop, and an I/O engine. But adoption were driven by its ability to supplant existing server side solutions. The killer productivity feature being that you could replace your old clunky server backend with a new lean backend written in Javascript. In other words, you have server solutions which are failing and in comes the new shiny Node.js system and proves it can run on a fraction of the hardware of the old solution. 7 years ago, there were relatively little focus in the community-at-large on the latency of responses, so the major problem space for Node.js was ignored. This is now becoming a limbo in which languages such as Go, Erlang, and Elixir can operate due to their focus on low-latency operation.

My own experience is from the Erlang world, but it applies equally well in the Go world: an existing system was not meeting reliability needs, crashing weekly and requiring intervention by 3 people in the organization. By utilizing an Erlang strength, reliable operation through coordinated system restarts from known invariant states, we could quickly replace the failing component with one that has had 1 bug in 1 year. A bug which has not been fixed yet because it is so rare that the effort required to fix it outweighs its occurrence. Through automatic restarts of subsystems, the bug does not incur a fatality in the normal operating procedures.

Another situation was a project with faulty state-handling. This meant that the system gradually introduced errors in its persistent state, which meant that it required manual cleanup in order for the system to do the right job. By replacing the system with an idempotent solution, and by solving some distribution problems in the old solution, we could quickly replace the system with one that worked. Once replaced, we used the new system to add instrumentation around its core, which meant we suddenly had metrics of neighboring systems. This uncovered several bugs in the surrounding infrastructure, which were then fixed. The end result was a more stable system-whole.

[0] Algebra is here used in the arabic form of "al-jabr" (الجبر) which supposedly means "reunion of broken parts'

[oju...@gmail.com]

Poor man, you are out of luck. Unfortunatelly today I have the time to write a boring piece describing my saga at the current job. It can be entertaining, despite that.

Something like one year ago I called the IT director and said:

- Go is a great tool, I used it at my previous job, and we have plenty of opportunity to leverage the language ecosystem here. Can I use it?

- Cool! I am fine with that, of course. Just make sure your coworkers agree before we can adopt it.

The next day I called my two coworkers by the time (both C++ programmers, no working knowledge of Go), and explained why I think Go brings great opportunities. I finalized by saying:

-  ... that's why I think we should give Go a try. I have the ok from our IT director. He told me to ask your opinion. 

- No. Let's keep using C++. Hahah.

This last laugh was true. They coldn't hide it. Only then I understood that it would be easier to convince two turkeys to accept the importance of Thanksgiving Day.

Technical choices shouldn't have an emotional impact, but for me that one had. You can bet I got a lot frustrated by that "No. hahah".

I asked for the IT director for support, but he was always busy at the following days so I understood he was not willing to risk his relationship with the rest of the team only to put a smile at my face.

Two months later a new IT director was hired. I called him and told why I like Go. After all my explanation I got his answer:

- Yeah, that's pretty interesting, but from these new languages I prefer Rust.

By that time I knew two things:

1. I would therefore use Go to my own advantage as an individual programmer, since the company I work for showed no interest at all.

2. I need to improve my sale skills, just in case I eventually loose my job and have to work as a salesman.

So, I went ahead as planned, using Go only for my own tools and prototypes. When time came to put something into production I had to translate my Go code into C++ code before uploading to our official version control. Yes, that means I couldn't use some cool Go features I like, but that scheme worked well enough for practical purposes. The funny part is that the Go prototypes were faster than the C++ version. Always.

Despite that, I decided not to try to convince anyone. Life is short and I was not willing to ear another "No, hahah".

Go was my "not so secret" weapon, because everybody knew I used Go daily for nearly everything. I just didn't put the code under our common version control.

Weeks later when I was editing some Go code a newcomer take a look at my screen and say:

- Hey, guy, do you use Go?!

- Yes, I do.

- Man, that's wonderful. I absolutely love Go! If by any chance you stumble upon a Go project, please count me in! And by the way, that other new coworker came from a succesfull Go project at his previous job.

So, I went to talk to the other guy:

- Someone told me you can code in Go.

- Yes! At my last job there was this legacy component, bending at an increasingly production load. They tried several alternatives, but the only solution that really worked was to recode that part in Go. It worked flawlessly. Are your using Go here?

- Nothing official yet.

- If there is anything I can help, please count me in.

- Thanks.

I could feel the passion. I was not alone. We were like girls talking about the our favorite boy band. No, not exactly, but you know what I mean.

Some weeks later, at a meeting, I suggested:

- we need a validation tool to share with our business partners, for them to be sure the file set they produce is ok before sending it to us.

- No need to spend our precious time on such a tool. Our partners know the format and rules.

Can you smell it comming? I could. So I went ahead and coded the tool privately anyways. In few hours I had a working validator, checking for more than 60 rules.

When the first partner sent the file set I ran it thru my tool and found in excess of 25 thousand errors. Replied to the partner along the lines "Found some glitches. They are in the attached file. Could you fix it, please? Thanks"

A week later we were still exchanging emails like that one, because "our partners know the format and rules" proved to be not enough. It becames obvious they needed a tool. So I went to my IT director and said:

- I imagine you know how I could find those errors.

- Yes, you have a script.

- I think we could share this tool with our partners allowing them to find the issues by themselves. What do you think?

- A script? They would have to install a runtime?

- No. It's a Go program. Go produces an executable file.

- Really?

- It's a compiled language. The compiler produces native code, much along the lines of C or C++.

- What do they must install to run it? Some library?

- Nothing. Just the executable itself.

- Hum, interesting. Ok.

- By doing it I will have to upload the code to our version control.

By that time he already knew we had a couple of gophers in the company, besides myself.

- Of course. Go ahead.

I couldn't hide the grin upon my face. That was the first time Go code was accepted into our company official repository. The gate was open.

Some days later, two coworkers asked me about a change in the tool. I said:

- It's simple enough. Let's do it together.

I went ahead and guided them to install Go tools and implement the desired change. They were amazed it was so easy.

- Where is the makefile, or project file, or whatever?

- No makefile needed. You just command "go build".

- Wow. The build is fast!

People began to understand why I liked Go so much. They were shocked by the smartness of Go ecosystem as they learned each detail.

The next improvements to our new tool were made by them.

As we use to say: there is nothing like one day after another.

[oju...@gmail.com]

[Haddock]

Man, great read! Thanks for sharing. You are working in a C++ setting where things are a bit different than in the Java world as what using Go in addition to the main language is concerned. Go is more in the spirit of C or C++ than Java. But nevertheless, Go can be a complement in the Java world as well. Here is what I see where Go can be combined with Java in a meaningful way:

* Lower memory consumption.
* Much easier concurrent programming in case the application by nature leads to asynchronous/concurrent programming
* Much easier to balance heavy load changes: number of green threads just grow with the load
* Even utilization of the CPU cores almost "automatically" due to CSP
* Special situations where a standalone self-contained executable is needed.
* Shorter startup times. In the Java world not much of importance except for some very rare extreme situations and JDK9 will also solve this
* Stable vendor (as opposed to D, even Rust)

I think Go has a chance in small companies. Some weeks ago had a job interview in town with a company that mainly uses Java but starts to combine things with Go. Was a little company with few developers where the technical lead could get his ideas through with the head of development.

I large organization where Java JEE architects are around bringing Go into the game is almost impossible. Many architects have build up their careers on application servers and EJBs without really understanding what that big big hammer is needed for in that situation and just keep repeating the same recipes. So, then let's stick with the small companies without architects ;-).

-- Haddock

[Eric Johnson]

> On Jan 3, 2017, at 8:47 AM, Haddock <ffm...@web.de> wrote:
>
> I large organization where Java JEE architects are around bringing Go into the game is almost impossible. Many architects have build up their careers on application servers and EJBs without really understanding what that big big hammer is needed for in that situation and just keep repeating the same recipes.

I suspect large organizations are much more amenable than you think.
What with all the development that targets browsers, the prototyping
that might happen in Python, and all the small utilities that they
certainly need to build, there's probably much more opportunity than
you expect.

Eric