<p>Our team is currently using python but unfortunately it seems like there's an internal mandate to use nodejs for new projects. I know that nodejs is more performant than python but we argued that if were gonna replace Python with something more performant, why not use Go instead? Its more readable and can perform cpu intensive tasks unlike nodejs. To be honest I don't even know how they came up with the idea of using nodejs by default. Basically my goal is to sell Go to the engineering managers. Please share your stories on introducing Go to your companies.</p>
<hr/>**评论：**<br/><br/>GoTheFuckToBed: <pre><p>I did buy the Go Gopher Toy from kickstarter, and showed it my manager. </p>
<p>"This is Go" I said, "we need to write our new code in Go". He looked at me silently and nodded. </p></pre>chmikes: <pre><p>I said that Docker was written in Go. This put a final stop to suggestion that Go would just be another academic and exotic programming language. It was fit for production application. This was a very strong point. </p>
<p>The remaining concerns were about long term support of the language. I explained that Google is leading and supporting development of Go. I added that the compiler and all std packages are open sourced on github. Even if Goggle would stop supporting Go, it would not be a problem. </p>
<p>Another concern was about it's young age. I explained that because the language is simple and complete, many people are publishing packages on github. The tools we need (manipulating FITS files, Swagger, DB, web) are all already available in Go. </p>
<p>Last concerns were about programming language fragmentation in our project. Usually programming languages are restricted to C++, C, Java and Python. In our distributed application there wouldn't be interoperability problems. The problem is about developer competence. I explained that I learned it in a week-end because it is very simple. A colleague who never saw the language but know C, C++ and Python had a quick look and confirmed. He decided to also adopt that language for his parts of the development. </p>
<p>Everybody currently agree on my usage of Go, but I still have to go through a formal review by a third party. So it's not 100% sure yet that Go will be used in our project.</p></pre>driusan: <pre><blockquote>
<p>The remaining concerns were about long term support of the language. I explained that Google is leading and supporting development of Go. </p>
</blockquote>
<p>Why would you bring that up if they're concerned about long term support of the language? That's the one thing that puts long term support in doubt.</p></pre>gngeorgiev: <pre><p>Shhh, it sounds cool to people who don't know google's track record of projects.</p></pre>jerf: <pre><blockquote>
<p>This put a final stop to suggestion that Go would just be another academic and exotic programming language. </p>
</blockquote>
<p>Ha, you may also want to share that almost all the criticism Go faces from the programming community fit into the category of "Go isn't academic and exotic <em>enough</em>". I'm not sure there's been a language as brutally practical since C or Awk or something.</p>
<p>I'm a big fan of the generally "academic" direction a lot of programming is going in, but it's also nice to use a really, really refined condensation of the practical side of programming too.</p></pre>kralyk: <pre><blockquote>
<p>Ha, you may also want to share that almost all the criticism Go faces from the programming community fit into the category of "Go isn't academic and exotic enough". I'm not sure there's been a language as brutally practical since C or Awk or something.</p>
</blockquote>
<p>LOL right, because languages like Python, Java, C# or JavaScript are academic, exotic or impractical... /s</p>
<p>Seems like Go programmers keep telling each other how Go is simple & practical and how other languages are academic/complex/whatever, but really what is this meme actually based on? How is Go simpler and more practical than, say, Python or Java? The answer is it's not, it's about the same in all respects.</p>
<p>To be absolutely honest, I don't see a very big difference between Java and Go. If I had to choose between Java and Go for a backend platform, the only difference that would actually matter to me is that Go has a less resource-hungry runtime and Java has a better type system, but that's about it. Yeah, sure, there are differences in the language details (such as no inheritance in Go etc.), but in the grand scheme of things those differences are IMHO rather minuscule.</p></pre>very-little-gravitas: <pre><p>The stdlib and culture are radically different.</p></pre>kralyk: <pre><p>I suppose I agree with that, but out of curiosity: What would you say the difference is?</p></pre>jerf: <pre><blockquote>
<p>LOL right, because languages like Python, Java, C# or JavaScript are academic, exotic or impractical... /s</p>
</blockquote>
<p>I said that the criticisms Go faces are of that nature. Are you aware of a great bulk of criticisms against those languages for "not being academic and exotic enough"? C#, maybe, though usually it meets those criticisms by adopting more academic features over time (non-nullable types, LINQ, etc., all added after 1.0).</p>
<p>What you're "lol"ing at is not what I said, it is what you <em>expected</em> me to say. If you just want to talk to people saying what you expect them to say, then you don't really need to go out on the Internet for that; you can conduct a monologue without me just fine.</p>
<p>I could easily criticize Python for being not very academic. Despite occasionally wearing the superficial trappings of academically-interesting features, like list comprehensions, it is basically disqualified nowadays because all academia is based on ever-stronger type systems, and dynamic typing is right out. But it is not the common criticism leveled against it. I assume it is because people don't expect languages released in the 1990s to track all the latest 2010s programming language theory developments and fads.</p>
<p>Let me pre-emptively point out how I wrote about the <em>developments</em> and <em>fads</em> separately quite on purpose, because they are different things. I'm actually also critical of Go not using the experience of the various <em>developments</em> of programming language theory; for instance I'd like all the nillable things to also have non-nillable types to go with them, because things like C# show that you can even <em>retrofit</em> that sort of thing on to an existing language. (Being able to retrofit things like that is actually fairly rare.) I thikn Go would have also been helped by some sort of memory isolation model between goroutines, both for programmer correctness and for easier GC, in the style of Erlang. However, it is also absolutely the case that a lot of the criticism of Go is because it rejects all the latest <em>fads</em> as well. There is a non-trivial amount of the criticism of Go that arises because it directly challenges some people's self image of themselves as being members of the community that is in sole possession of the rights to determine who's the cutting edge new language and who's last year's trash, and Go's success challenges that authority. Those criticisms should be discarded by serious engineers.</p>
<p>I do not have a lot of respect for the fad-driven community, because they have lost that respect with me by failing to use sober judgment. Scala was one of the more recent fads, for instance, and I've seen a lot of criticism about how complex it is and how that complexity doesn't seem to pay off anywhere near as much as it should, and a lot of those criticisms should have been evident from the beginning. It checked a <em>looooot</em> of boxes off the fad-of-the-year list, but in practice, it's probably going to end up a failed language. This is not uncommon.</p></pre>Freyr90: <pre><blockquote>
<p>Ha, you may also want to share that almost all the criticism Go faces from the programming community fit into the category of "Go isn't academic and exotic enough"</p>
</blockquote>
<p>Nope, Go is just the most badly designed language I've seen. I thought that it is impossible to design a more ugly language than C++ or php, but here it is.</p>
<p>It is definitely not awk or C. awk and C were beautiful and simple, and Go is not simple, it is complex as hell.</p>
<p>Do you know what makes languages simple? <strong>Rules</strong>. Do you know what makes languages complex, ugly and hard to use? <strong>Exceptions</strong> from the rules. And Go is full of exceptions. For example:</p>
<p>1) No generics, but generic slices, maps and channels in stdlib. You cant define your generic map or rb-tree, but there are some generic entities in the language which are exceptional.</p>
<p>2) There are no tuples, but functions can return multiple values, which is also an exception, not the rule. In language with tuples you can get multiple values as a tuple from a function and pass it to another function. But in Go you can't pass a pair of values to a function, there is no such type as pair, you can only return it.</p>
<p>3) interface{} which make Go type system unsound, just as python's one, but static (handicapped) typing is still there, not preserving you from errors but disturbing.</p>
<p>4) nul</p>
<p>Go feels like its creators didn't even try to design a decent language. It feels like they wanted C with plan9 libthreads, so they took libthreads and hastily made a language around it. Go is not simple, it's poorly designed, and I think more design issues would show up as they would add new features such as generics.</p></pre>serverangels: <pre><p>Kubernetes, too.</p></pre>ryeguy: <pre><p>etcd and cockroachdb as well</p></pre>mcouturier: <pre><p>The <a href="https://talks.golang.org/2013/oscon-dl.slide#1" rel="nofollow">talk</a> by <a href="/u/bradfitz" rel="nofollow">/u/bradfitz</a> regarding dl.google.com being now powered by Go instead of C++ is quite a good comparison of the 2 languages regarding web services and interoperability. I don't know about your company and your products but you mentioned C++ so... I thought it might interest you.</p></pre>hell_0n_wheel: <pre><blockquote>
<p>The problem is about developer competence.</p>
</blockquote>
<p>Aside from long-term support, this is a major consideration in any sort of tooling / language adoption. If the entire team is new to a language, who's going to be able to debug a difficult bug in a timely manner?</p>
<p>In OP's case, if he can show the ecosystem is sufficiently mature -- the tooling exists to make debugging easy enough for a beginner -- then he can go a long way in assuaging his manager's fears. I'm not so sure that this is the case with Go, but I could be wrong... I'm only a beginner myself.</p></pre>sleepybrett: <pre><p>I'm not sure pointing out that docker was written in go holds much weight considering how buggy docker is.</p></pre>NikkoTheGreeko: <pre><p>In my team I am the manager, so maybe my story isn't too helpful. I built a few small services in Go to see how it worked out. I was happy so I sent out some "suggested reading material" to the team for anybody interested in learning it and told them they have my blessing to take a few hours a day learning it and writing new endpoints in Go.</p>
<p>Nobody took my offer. PHP dev continued as normal. <em>sad</em> But I know how interrupting a required language change would be, so unless something was fundamentally broken with our existing language or process, I wasn't going to demand a change.</p>
<p>Flash forward 6mo. One of the services I wrote had a fatal error. I forgot to remove an os.Exit() call and the service was dying in very rare cases instead of elegantly handling the error. I was unavailable so my other lead developer who has never used Go in his life dug into the code, understood it, found the bug and reported it to me but didn't know how to rebuild it. I told him to SSH in and run "go install servicename" and "service servicename restart". He seemed impressed with how easy it was.</p>
<p>Try to get someone to debug a Node crash who has never used Javascript (or even someone who has only used JS on the frontend) and watch their head explode. Nothing about Javascript is intuitive or makes sense to someone with experience with programming languages with a consistent pattern and structure. If you are a proficient JS developer you can build in Node much faster. However, I'd rather take a bullet to the head than take over a large poorly documented Node project.</p></pre>zdebra1: <pre><p>Few things in my company: </p>
<p>1) We've got a great project for trying out Go: the budget was ok for a few extra days to learning new stuff, the project lies down on websockets and concurrency patterns where Go shines. </p>
<p>2) I've got talk with a few engineers in our company about how we got enough of programming web pages in php.</p>
<p>3) The company's managers are willing to trying a new stuff, so they get competitive advantage.</p></pre>notsogoodlang: <pre><p>thanks! hope my engineering managers are as open minded as yours</p></pre>tywkeene: <pre><p>Because the mascot is super cute.</p>
<p>Like, what more reasoning do you even need.</p>
<p>If they don't go for it based on that, I'd say update your resume and jump ship</p></pre>kwitcherbichen: <pre><p>Engineering manager here. We use Go, heavily among other languages, and the discussions around choice of language have been:</p>
<ul>
<li>Does it fit the problem space? (Mostly, in our case)</li>
<li>Does it have library support for... ? (Usually and while cgo can be a pain it frequently just works. Debugging cgo sucks, valgrind/helgrind support is weak/absent)</li>
<li>Are there good tools and an ecosystem around it? (Sometimes, dependency management still sucks, debugger support is poor)</li>
<li>Will it interoperate with <em>baz</em> thing or vendor <em>quxx</em> service? (Almost always, depends on what you're doing)</li>
<li>Can...
<ul>
<li>I hire people who know it? (Yes, but if they don't they'll pick it up in a few days or weeks on the job)</li>
<li>my worst developer learn it? (Yes, but they're still my worst developer)</li>
<li>we debug it and support it? (Yes)</li>
</ul></li>
<li>Who will perform code reviews and has time to shepherd? (This is a big one, we insist on having at least one person on each team who can lead with the language and one on cross-team who is able to pitch in)</li>
</ul>
<p>FWIW, I personally don't like Go. It has the wrong level of abstraction for me and its trade-offs and design decisions are not ones I prefer.</p></pre>cameronjerrellnewton: <pre><p>build something useful in go, tell them how fast it is and how it took you the same time as it would take in python or nodejs, and them tell them this is way better for long term maintainability because it has static type checking. Tell them segment.io moved from nodejs to go for reasons like this <a href="https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b" rel="nofollow">https://medium.com/@tjholowaychuk/farewell-node-js-4ba9e7f3e52b</a></p></pre>konart: <pre><blockquote>
<p>why not use Go instead</p>
</blockquote>
<p>If your want your team\company to use Go you shouldn'd ask "why <em>not</em> Go", but tell "why Go". </p></pre>bmurphy1976: <pre><p>I carved off a small but critical portion of our infrastructure and rewrote it while I was off on paternal leave. When I came back I deployed it and it sat idle for a few months while I politicked other members of my team to give it a try.</p>
<p>Eventually problems with the old version of the service tempted the rest of the team to try my version. Slowly they started migrating over to using the new service and it worked great. It was fast, reliable, easy to update. I basically knocked it out of the park. </p>
<p>The rest of the team was intrigued so they took a closer look. That was almost 3 years ago now. Since then then we've probably rewritten 50% of our backend code in Go (coming from C# no less) and I doubt we'll start any new projects in a language other than Go.</p>
<p>You should always experiment. Take a small representative piece of your infrastructure and try it and see what happens. Just be ready to drop it if it's not working out.</p>
<p>I've told my team through the years: Don't be afraid to try new things. If it's good, it will grow. If it's bad, it will go.</p></pre>PaluMacil: <pre><p>My team (9 C# devs, an artist, and a dba) just started writing some new services in Go, and it has been a distinct pleasure. Our boss largely lets us pick our frameworks, but our IT department's app dev team doesn't experiment. I think part of it is situational, but some is related to experience. If you have the career experience, or combined with a senior teammate have the experience to assure your manager that you can vouch for the technical merits of an initiative, a lot of managers will then delegate the technical choices to you.</p></pre>iends: <pre><p>I'm surprised C# team would be interested in Go. If you are already happy in the MS ecosystem, then C# seems superior. Can you talk more about why Go is appealing?</p></pre>PaluMacil: <pre><p>A need for strong math and statistics capabilities while in a .Net / MS environment meant that we wound up building a developer team with a fair bit of Python (for Numpy etc) and Linux knowledge. Docker is our preferred way to deploy applications due to the scalability needs. This was only Python till .Net Core hit 1.1, so our .Net stuff is being deployed via Docker too now. Go is more productive for us when we're writing APIs because the code is so explicit and density is evenly distributed. Personally, I find that a small API needs a fraction as much effort to go from nothing to production in Go compared to .NET despite my having an order of magnitude more experience in .Net. Most importantly, rapid compile time, fewer output files, no outside runtime, and fewer imported frameworks to configure gives us far simpler deployment experience. Some of us run Linux on our personal machines with some tending to use Python for build tools, so we are far from a typical C# group, with a lot more comfort in the commandline than previous teams I've worked with.</p>
<p>As far as ecosystem goes, we don't see a loss from using less .Net:</p>
<ul>
<li><p>I just completed an Active Directory utility in Go. Our desire to manage small things like this utility in Docker meant .Net Core or Go, so it was going to be bare LDAP either way. I think I would have spent exactly the same amount of time developing it in either language. Deployment in Go was (slightly) easier / quicker.</p></li>
<li><p>We use SQL Server for most vendor-purchased applications, but we sync data to Postgres for anything Geospacial (which is a lot of what my team does). When possible, I prefer to keep services doing one thing, doing it well, and isolating access to their data except by API, which leads to our lack of interest in ORMs (though we often use Dapper in .Net since it supports .Net Classic, Core, and is a thin layer with far better performance than something like Entity Framework).</p></li>
<li><p>We can't use Identity Framework for auth in any language anyway because we don't manage Active Directory (IT does) and can't make changes fast enough to support our complex environment. We authenticate via AD but authorize from outside our the firewall where AD lives (probably more weirdness there than you care to dig into).</p></li>
</ul>
<p>I still love C#. My whole team loves C#, and most of us like Python and / or Go (aside--we all hate JaveScript). However, after seeing junior developers without web experience struggle to understand multi-tier C# projects using ASP.Net and Web API, I'd like to expand the usage of Go further. I can't help but think the burden of learning Go for a junior C# dev might actually be lower than learning everything involved in ASP.Net and Identity, etc.</p></pre>iends: <pre><p>Thanks for the great response. </p></pre>FrenchDonkey: <pre><p>I did it this way.
I created a small project on the side and wrote it in Go. It was so fast and they were surprised. It picked their interest and they invested on it. </p>
<p>Action >> Words</p></pre>embedded_junkie: <pre><blockquote>
<p>picked their interest</p>
</blockquote>
<p>*piqued their interest</p></pre>Generalj10: <pre><p>We started using it after I learned it and built something for work one weekend. I walked my manager through how it worked and basically just got him as excited about it as I was. The combination of "Hey look at this cool language" and "I actually used it to build that thing we talked about last week" was enough to get it into production. Any new stuff we build now will probably be in Go.</p></pre>George3d6: <pre><p>I've used golang in two workplaces now, one of which had literally nobody with any knowledge of the language while the other had a QA guy sometimes using it.</p>
<p>In both of those cases my argument was that Golang is a very good replacement for python/bash/perl scripts because its very good at doing anything relating to fs management, networking... etc whilst being strongly typed, so you don't have to worry so much about scripts crashing or having weird bugs.</p>
<p>That's where golang shines above all other language really. You have to write some functional testing that involve creating jsons and posting them to a server ? Perfect. You need a cronjob that does "x" administrative task and is self-contained and compatible across any os (even without a cron manager) ? Perfect. You need a quick script to convert your report from CSV to Excel ? Perfect. You need to make a easy to use http service over the database because of a vague reason but you want really rebuke the task ? Perfect.</p>
<p>In my experience golang those all these tasks really fast and with really little code. Is self contained and less likely to crash and burn than *sh or python... and if you need to scale your scripts up a notch (e.g. run them on 100xxx small machines) that's not a problem since golang is very cpu&memory efficient (its not well designed C, but its unimaginably fast and memory efficient compared to Java or Python and it doesn't have memory leaks, and bad design patterns are easy to avoid).</p>
<p>After you switch administrative scripts to golang people will warm up to it.</p></pre>djslakor: <pre><p>I do hear the "it's more readable" claim, but I don't personally agree with it, and don't think that's universally true. Sure, gofmt and fewer syntax sugar features make more code more homogeneous, but I still don't personally find Go code any more or less "easy to read" than decently written JS.</p></pre>goomba_gibbon: <pre><p>I suppose readable is a subjective thing.</p>
<p>Personally I really appreciate a strongly typed language, like Go. On the other hand, Go can be quite verbose at times.</p>
<p>I'm also not a fan of how callback/promises work in JS- just seems dirty to me.</p></pre>djslakor: <pre><blockquote>
<p>I'm also not a fan of how callback/promises work in JS- just seems dirty to me.</p>
</blockquote>
<p>async/await makes code very easy to read and understand. it's available <em>now</em>. I'm not advocating for JS over Go, I just wish people would revise their criticisms with the current state of things.</p></pre>metamatic: <pre><p>I built a very simple web app in both Go and Java EE, compared the number of lines of code involved, and showed the CPU and RAM requirements and how they would affect our hosting costs.</p>
<p>Comparing with NodeJS, I mostly made a technical argument based on the lack of stability and reliability in the JavaScript ecosystem, and pointed out a few examples of companies that had switched from NodeJS because of the long term maintenance problems.</p></pre>djslakor: <pre><p>Lack of stability and reliability?</p></pre>metamatic: <pre><p>Remember the <a href="https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/" rel="nofollow">left-pad</a> incident?</p>
<p>Look at the dependencies of a typical open source NodeJS project. Look at how fast entire frameworks appear and disappear from the popular projects list.</p></pre>djslakor: <pre><p>The single npm incident which has been resolved and future proofed? Yes. </p>
<p>Not sure what you're talking about. Express, Koa, Hapi have been around and going strong for years. </p></pre>metamatic: <pre><p>I'm talking about <a href="https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f" rel="nofollow">churn</a>. You may not feel it's an issue, but many disagree.</p></pre>djslakor: <pre><p>Should I list all of the Go web frameworks as a counter example? </p></pre>metamatic: <pre><p>Counter-example to what?</p>
<p>And there's a reason why people on <a href="/r/golang" rel="nofollow">/r/golang</a> say not to use Go frameworks.</p></pre>goomba_gibbon: <pre><p>I'm not suggesting that Go is not a good choice for you but there are more than just technical considerations here.</p>
<p>One example is the pool of available developers to hire from. Similarly, the need to do front-end JS work as well as back end might make these developers more flexible.</p></pre>jbert: <pre><p>I'm less concerned about the pool of golang devs. Our experience has been that python/c/c++ devs are productive in golang within 1-2 weeks (as in shipping production code) if supported (code review etc) by existing golang devs.</p>
<p>I'm happy to hire good devs and cross-train to golang.</p>
<p>We get a benefit from running golang in the cloud and on-device (for IoT). It allows us to move processing between the device and the cloud in different releases relatively easily.</p>
<p>I can see that a similar benefit could acrue to nodejs on the backend with js in the browser. </p></pre>goomba_gibbon: <pre><p>Being easy to read and understand without much training is itself a big boon, particularly if you're dealing with a large codebase.</p>
<p>As someone looking for a Go job, it's refreshing to hear that Go experience is not a prerequisite.</p></pre>SirIsaacNuketon: <pre><p>I found this medium post quite useful, particularly in the node vs go argument:
<a href="https://medium.com/javascript-non-grata/the-fall-of-the-house-of-node-43697fd56a6" rel="nofollow">https://medium.com/javascript-non-grata/the-fall-of-the-house-of-node-43697fd56a6</a></p></pre>iends: <pre><p>That article is pretty terrible. JS wins over Go if you care more about time to market than anything else. Over time, maintainability becomes more of a concern and Go wins. Obviously Go is more performance for CPU bound tasks, but that might not matter for your application if it's IO bound. </p>
<p>The biggest problem with Go is that the level of abstraction doesn't always fit. For example, I can happily write SQL, but writing a data mapper to get objects to the database over and over is repetitive and the wrong kind of boring. </p></pre>tuxlinuxien: <pre><p>I lead a team of 5 developers, including myself, and we are working on an analytic platform. The first version was all written in nodejs but after 1 year, the system was just a huge mess. It was crashing all them time because of heavy ram usage for caching.
One day I have decided to rewrite one of our micro-service in Go for fun and see if it worth continuing it. That weekend spent on this project just changed my point of view about typed-programming languages.</p>
<p>I have shown this to my team member and they were all exited about trying it (maybe because of Javascript fatigue) and we all rewrite all our code base from node to Go. It has taken us only 2 weeks to finish this task and the final results were just amazing. It was suddenly easy to deploy our code in production over 50 servers (Intel Atom based) and deal with 200M requests/day.</p>
<p>After 2 weeks of log checking and make sure that everything was stable, we were confident enough to release resources and only keep 5 servers. In the end it was still working like a charm.</p>
<p>This was my journey with Go and how we have been able to reduce our hardware costs. We can refactor our code easily and see our errors at compile-time and not during the run-time.</p>
<p>However, there are some trade off... finding a go developer is not easy at all and it requires me more time to teach it to my new team members. Downloading packages from china is just terrible. There are lot of libraries but not as much as nodejs or python.</p></pre>asyncrep: <pre><p>'Downloading packages from china is just terrible' -- I'm sorry, what?</p></pre>tuxlinuxien: <pre><p>I am working in China so most of google related websites are blocked. I didn't say that to you but i do hope someone reading my answer would create a mirror here to make golang dev smooth. It was just to share one of my concern.</p></pre>andreasgonewild: <pre><p>I am my team/manager these days, but I remember that picking a thorny problem or suboptimal part of the system to re-implement and then showing the result is a good way to trojan-horse your way into a codebase.</p></pre>tmornini: <pre><p>I said I'd take a job elsewhere if they didn't let me use it. :-)</p></pre>redditbanditking: <pre><p>Concurrency. We had one app that obviously needs heavy concurrency support. Most of the backend apps were Node.JS or Ruby, which were all single-threaded. I told them "What, do you want me to write this in Java?"</p>
<p>They immediately agreed.</p></pre>Iliec: <pre><p>Usually if you want to use Docker/kubernetes or Gauge(testing) since they are open source tools, the company should have some go developers in case they need a patch or to fix a bug. The alternative to this is to buy support. I'm sure by now in most companies use some software which is open source and whiten in go. Argue that the company should have some go knowledge if they are serious about using any of these tools.</p>
<p>For me it was easy since I'm the manager and pushed go on my team. Initially it was mostly due to using docker in the company, but now people really like it and we're trying to get a Meetup started.</p></pre>circuitously: <pre><p>I didn't. I'm a Dev team lead with a strong devOps leaning in a startup with a lot of PHP and Python, and far more things on our to-do list than time/people to do them.</p>
<p>So I built some of the tools we sorely need, mostly devOps "script style" tools, using Go in my spare time. Shit's getting done, it's documented, and I'm going to hold a seminar soon for other devs who are interested.</p></pre>itsmontoya: <pre><p>I am the manager, so I said "Our next iteration of our dashboard will be written in Go". </p></pre>iends: <pre><p>Did your boss fire you for being a bad manager?</p></pre>itsmontoya: <pre><p>Nope, got a promotion!</p></pre>
