<p>Longtime Rubyist and web developer here here. You see a lot of posts describing a switch from Python/Ruby/Node/etc to Golang with huge improvements in performance, scalability, and in some cases the ability to embed. </p>
<p><strong>If my team is focused on building web applications, is it still worth the switch if we don't have performance problems?</strong> In my world, performance is not a concern and Ruby on Rails seems fine. I guess I don't know what I don't know, but I'm curious what other converts have to say regarding overall productivity or other improvements.</p>
<p>My current team is supporting a React frontend with a Rails backend, so the switch to Golang wouldn't be too hard (I don't think?)</p>
<p>Thanks y'all!</p>
<hr/>**评论：**<br/><br/>semi-: <pre><p>I switched for the simplicity, the performance is just a really nice perk. </p></pre>sharptierce: <pre><p>Why would you switch If you're current setup fits your needs perfectly? A switch comes with a cost. </p>
<p>Additionally hiring new Developers for ruby etc must be much simpler than hiring go developers...</p></pre>pinpinbo: <pre><p>I think its worth it.</p>
<p>Type system and returning error early will save you from large number of production-only raised errors.</p>
<p>The import system is also nicer than ruby or python. You always know where things are coming from.</p>
<p>The standard library is also surprisingly robust, unlike things that shipped with ruby or python by default. For example database/sql takes care of connection pooling for you.</p>
<p>So much to gain, very little to lose. Do it.</p></pre>manueslapera: <pre><blockquote>
<p>The import system is also nicer than ruby or python</p>
</blockquote>
<p>well i'd agree with it being better than ruby (whole module imported), but python has one of the most clear import syntaxes.</p></pre>pinpinbo: <pre><p>There are a few oddities about python import:</p>
<ul>
<li><p><code>sys.path.append(...)</code></p></li>
<li><p><code>from x import y</code>. I am looking at you <code>from datetime import datetime</code></p></li>
</ul>
<p>They are not show stopper, but definitely give you a pause for a bit.</p></pre>manueslapera: <pre><p>well the <code>from datetime import datetime</code> is just the design of that library and has nothing to do with the import methodology itself.</p>
<p>I agree that the <code>sys.path.append</code> is sketchy, but i've had waaaay more headaches with circular references in go, and the sys <em>hack</em> would have been more than welcome in those cases (instead of having to refactor things that made sense in my head just because go)</p></pre>pinpinbo: <pre><p>Ah :) I had forgotten about Python's circular import problem.</p>
<p>With Go, you can break circular import by implementing a small interface that implements the needed methods.</p>
<p>To break circular import in Python, you have to refactor a much larger surface area.</p></pre>Feribg: <pre><p>You will probably loose a lot in productivity in go if performance is not a problem. As much as go is advertised as "dynamic productivity, compiled performance" its not true. It doesnt get nowhere near Ruby or Python in terms of expressiveness. On the other hand if not for the performance type safety is always a benefit, but Go's type system in my opinion is definitely not amongst the best ones, but still much better than no types at all... </p>
<p>So to answer your question, if im not having performance problems and you arent working in very big teams, sticking with Ruby is probably best. As your team grows Go becomes easier to maintain in my opinion, but pure development turnaround times are still longer than Ruby.</p></pre>aranw: <pre><p>I'd say don't switch based on what you say about productivity and then instead look to build new features in a Microservice/SOA style manner to learn Golang and get the benefits that way. Your developers may end up loving it and want to switch the main backend system to it. </p></pre>jerf: <pre><p>Go can't solve problems you don't currently have, any more than anything else can. But an attempt to switch will inevitably create new ones.</p>
<p>That said, it may be worth having someone put it in their toolbelt in their spare time, for two reasons. One, sooner or later someone will hit a performance issue, because Ruby is incredibly slow. (As are Python and Perl; it's not special to Ruby, it's the paradigm it's a member of.) Two, because you may want to have someone whose entire worldview is not entirely shaped by Ruby's request/response view of the web. You may be missing an opportunity to use websockets, or have requests that both answer <em>and</em> still spawn a thread of computation, or have requests that can be spawned and easily wait for 'something else' to happen before returning while not consuming a full responder, or any of the other interesting possibilities that Go makes trivial and Ruby makes very difficult in most setups. (And I've not heard great things about EventMachine, either.) There's a lot of things you have to workaround, and a lot of things you just can't do, and there is a certain amount of danger in internalizing those limitations without realizing it.</p>
<p>But not enough to suggest switching without a lot more context.</p></pre>jrconlin: <pre><p>Golang, like any other programming language, is a tool. It has elements that are good, elements that are bad, and also has the added bonus of elements that aren't quite finished yet.</p>
<p>Like with anything, it's important to test your assumptions. Feel free to build a simple prototype and see if you get the sort of benefits you want. If nothing else, your project may benefit from a massive rewrite as you can incorporate lessons learned. </p></pre>jbuberel: <pre><p>Keep in mind that while Go services have been deployed that handle > 1 million queries per second (see <a href="http://i.imgur.com/tddp5Uu.jpg" rel="nofollow">http://i.imgur.com/tddp5Uu.jpg</a>), that was not the only design goal for the language.</p>
<p>The concise, simple syntax and rigorously enforced code formatting were all meant to enable large teams to build large complex system and maintain them in a cost-effective manner over a span of years.</p>
<p>That is why Go has gofmt, go lint, go vet. That is why there are no compiler macros or function annotations. That is why the type system is the way it is. </p>
<p>So ask yourself the question: Does the system I am building need to be maintained for years by a team of engineers who probably weren't the original authors of most of the code? </p>
<p>If the answer is yes, then I would at least consider making the switch. Besides, learning the core language basics can be completed in an afternoon (tour.golang.org).</p></pre>kamakie: <pre><p>Meh, not worth it. If ror isn't giving you issues then keep trucking along. Your job is to give your users features, and if golang isn't going to move the needle for you, then don't worry about doing the big switch. </p></pre>sqeji: <pre><p>have a look at elixir with the phoenix phoenixframework.org framework as well for an option.</p>
<p>It's a purely functional language with optional types and a syntax inspired by ruby.</p></pre>
