<p>I have a chance to own a small service, and I would like to write it in Go.
I think it's perfect for the job. It's going to be a very simple web service that will have half a dozen endpoints that query database and return some response.</p>
<p>I am really excited to start the project, but at the same time I am worried that I won't get support from my manager and my team, if I say I would like to write this in Go.
To make matters worse, I am not 100% comfortable with Go at the moment, although I am working hard to learn to code in Go.</p>
<p>Were any of you in this situation before? How did you go about convincing your team and get them to be onboard using Go on production? </p>
<hr/>**评论：**<br/><br/>VivaceNaaris: <pre><p>First, get comfortable with the language. How can you tell others they should use it if even you don't fully understand its nuances?</p>
<p>Second, understand the alternative languages your team might be looking in to. Be prepared to define the advantages (and disadvantages) of using Go.</p>
<p>Third, go through your software requirements/criteria and figure out where Go fits in here. This goes back to my first point - you need to know how the language operates and what its strengths are. Also - whats the pre-existing stack your team already develops? Wouldn't make since to jump for Go if everything else is C# WCF.</p>
<p>Lastly... Software Engineering is allllll about reusability and teamwork. If you're only adopting Go for one tiny piece and only a few people are working on it, chances are it'll get tossed out down the road and re-written in the preffered languahe of your team/company. They don't know the language, so it comes down to either A) do I learn this language JUST to maintain this small service or B) do i just go with what I know and am most comfortable with?</p>
<p>Hope this helps a little.</p></pre>PaluMacil: <pre><p>This is totally correct. The only other option is to do what my most senior peer did after the fact: "So today I'm demoing this application I wrote in F#." Now, we're a .NET shop on one hand, but on the other hand, F# is more uncommon than Go. If you aren't the most senior person around, you might not do so well with the "just do it!" approach.</p></pre>Doxa_to_Theo: <pre><p>Things company cares about:</p>
<ol>
<li><p>faster?</p></li>
<li><p>quicker to develop?</p></li>
<li><p>catches more bugs?</p></li>
</ol>
<p>rewrite a core piece of your company's project completely in go</p>
<p>say "hey check this out, if we use go, this service runs <insert benchmark> faster, <em>and</em> it only took me <short amount of time> to rewrite it, <em>and</em> <if company is using dynamic language> I got the compiler to catch tons of bugs for me <else if company using static typed language such as java / c#> go's type system offers me a ton of more flexibility and I don't have to fight the type system as much to make the compiler happy by <show example of implicit interface implementation or ease of a type implementing interface></p></pre>mvpmvh: <pre><blockquote>
<p>go's type system offers me a ton more flexibility and I don't have to fight the type system as much to make the compiler happy</p>
</blockquote>
<p>explain?</p></pre>Testiclese: <pre><p>7 years of C# experience here. I prefer Go's type system. Here's why:</p>
<ul>
<li>Less bureaucratic. This is <em>mostly</em> a feeling. </li>
<li>Does not force the late 90's mostly-useless "everything-is-an-object" pattern</li>
<li>First-class functions</li>
<li>I like how I can introduce interfaces <em>later</em>. </li>
<li>Simpler (this is actually huge)</li>
</ul>
<p>In C# I spent an enormous amount of type dicking with types and type hierarchies. In Go - close to 0. I get to <em>working code</em> much faster. And, with few exceptions, <em>cough</em> generics <em>cough</em>, that code is simpler and more maintainable, and less brittle. </p></pre>taylorchu: <pre><p>I agree. Go's simple type system gets 80% cases working perfectly. 20% complicated cases including generics is not a hard problem with go generate.</p></pre>Doxa_to_Theo: <pre><p>work with Java/C# for 5 years, then switch to go. </p>
<p>No explaining required.</p></pre>SandalsMan: <pre><p>And for those of us that don't have 5 years to invest in Java/C# to understand where you're coming from?</p></pre>Barrucadu: <pre><p>I've always found Go's type system one of its major weaknesses (ad hoc syntax and lack of generics (of course) being the main offenders).</p></pre>iends: <pre><p>I'm sorry the Go community has stockholm syndrome and must downvote opinions they disagree with.</p></pre>SeerUD: <pre><p>I introduced Go at an internal hackathon. We were building a chatbot system with a bunch of different service components; ones for handling passing messages around, things for processing actions that came about from messages, communication with a natural language parsing service, and a router to route the messages to the right place.</p>
<p>I was working on the "things for processing actions", we called them agents. I decided to use Go, and it got the interest of a couple of other devs. I was still pretty new to Go at the time, so we just worked on it all together and learnt it.</p>
<p>This got the attention of the MD here, and I said I wanted to formally introduce it to the team by giving an introductory presentation on it, so, that's what I did. Now we've got a few projects on the go that are using Go, and some more in the pipeline.</p>
<p>To me I think the most important thing is making sure your team is ready for it. Let them see the language, have a chance to play around with it. Try it out in a toy project that doesn't have any implications (I work at a software agency, so we didn't want to just try it out on a client project and learn on the job). If you do this kind of thing, people will either like it and start playing with it themselves, or they'll not like it, and interest will die out. I think the worst thing to do would be to force it upon your team.</p>
<p>It sounds like you need to get a bit more confident with Go yourself first, so just spend a bit more time learning it and make something you can show off. Make sure it's something that utilises the features that make Go stand out from what you're currently using.</p></pre>ronny10: <pre><p>Just do it!</p></pre>bmurphy1976: <pre><p><em>If it works, it will grow, if it doesn't, it must go.</em></p>
<p>Pick a small and insignificant portion of your system (but worthy of investment) and rewrite it in Go. If it works, it will start to grow like cancer. If it doesn't, kick it to the curb and replace it with something that does work.</p>
<p>That's how we went from a simple experiment in Go to 50% of our code-base rewritten (and more on the way). It's also how we learned MongoDB was a piece of crap without burning ourselves. :)</p></pre>mundanevoice: <pre><p>If you want to convince your team, maybe you need to show them a POC written in Go. Maybe right the same POC in your current language and in Go and show them the numbers. If will also help you get a better grab of the language and understand Go's strength and weakness. Writing a service in Go is not going to make it faster and better on it's own but architecting it correctly and using Go strength to your advantage will. So figure out where Go might help you with that.</p></pre>dahlma: <pre><p>I was the sole developer on the team and with only a little bit of knowledge of golang, I was able to write some real-time analytics software that I couldn't have imagined doing in PHP in about a week, the company I work for is very impressed. Since then, everything I've written has been in go and haven't heard any complaints yet.</p>
<p>I wasn't comfortable with go, after 4 years I'm still learning how to harness the power of it and try new things because it took awhile to get out of that mindset that the application doesn't live and die with the process like PHP applications do, so what I'm capable of doing with caching, behind the scenes processing, etc. is much greater.</p></pre>FrenchDonkey: <pre><p>Don't.</p>
<p>Write by yourself a smaller tool. Make it work and then people will see the benefits of it...</p>
<p>Having said that you need to be really comfortable.</p>
<p>This is the way I did it </p></pre>j_d_q: <pre><p>What's your role in the team? If you have some form of senior role, maybe you can take the same approach I did.</p>
<p>"We're doing this in Go."</p>
<p>I had joined a new team and was still fairly new to Go. The team had never used it and Java was the 99.9% language of choice. I had push back but my mindset was "they'll get over it. If they were coding it they could choose whatever language they want."</p>
<p>We have 4 day sprints, I worked with a (new) jr dev, designed the contract, and coded up a few endpoints. We were using 1/10th system resources and -- worst case -- if it had to be redone it would only take another sprint.</p>
<p>Fast forward a year and most of our back end development is now in Go. Pairing really helped get others on board and keeping the contracts well defined makes it so if we all quit tomorrow a new team could rewrite them in their preferred language in a short span. Middle management doesn't worry too much about that level of risk and I've found it far more maintainable than my previous preference (node).</p></pre>BoTuLoX: <pre><p>Step 1: Be the boss.</p>
<p>Step 2: Be the only person in your company.</p>
<p>I think that was the recipe for success.</p></pre>
