<p>Hey <a href="/r/golang">/r/golang</a>,</p>
<p>I just started learning ruby/rails about a month ago and noticed that Go has been picking up a lot of traction these days.</p>
<p>While I enjoy the syntax of ruby and also the rails community, I'm curious if I should look into Go instead. My main interests (aside from learning how to program) are developing web apps. So, am I better off investing into Ruby or Go?</p>
<p>Sorry if my question seems trivial or amateurish, as I mentioned I am still new to web development.</p>
<p>Thank you!</p>
<p><strong>EDIT: Thank you for all your responses, the community here is really great and helpful :)</strong></p>
<hr/>**评论：**<br/><br/>shovelpost: <pre><p>If you are looking to build web apps as a new developer then Ruby on Rails is probably your best bet. It's been refined all these years to offer amazing productivity and it's quite user friendly. It has great tooling that offers tons of scaffolding. You can set up a standard CRUD app in seconds which you can then change according to your needs. </p>
<p>Rails might not be as efficient as Go but to be honest it will take quite some time till you reach the level where Rails is a problem.</p>
<p>If you are not looking for developer speed and productivity and you'd rather understand and learn every little detail of a web app, while working on a lower level and you are not afraid to write some extra boilerplate to keep things simple then you can also try Go.</p>
<p>I'd say it's a trade off. You trade off, some developer speed, productivity and code magic to for simplicity, maintenability and software efficiency.</p></pre>Zombayz: <pre><p>Speed is definitely a plus with Rails. However I realllllly like the micro-service approach that Go promotes. I would love to see some Go projects that have implemented things like authentication and a front-end framework like React or Vue. </p></pre>shovelpost: <pre><p>There's no need to start with the micro-service approach right from the beginning. In my opinion you should start with a monolith and if necessary slowly extract important services as micro services. Besides, if you structure your code appropriately and separate it to service structs and interfaces, pick good package names etc. if you decide to extract one of those into a separate service later down the line, the process should be quite easy.</p>
<blockquote>
<p>I would love to see some Go projects that have implemented things like authentication</p>
</blockquote>
<p>You'll need lots of research, read lots of code and dig into many articles to find those. You'll have to make many decisions yourself, write boilerplate, tryout libraries etc. Meanwhile most if not all those are already made for you in the Rails world.</p></pre>3zcurdia: <pre><p>A rubist here and a Go lover. I think the approach for rails is more for a monolith architecture, and go for micro-services. If you want to build a monolith in go, you can do it but it will take you longer although there are some frameworks like <a href="https://revel.github.io/" rel="nofollow">https://revel.github.io/</a> but I think you should change your mindset, and think more in microservices. You can always start by creating small high-performance apps with go, and then integrate them with your rails platform.</p></pre>Zombayz: <pre><p>Yeah Rails does seem very monolithic, which I personally don't really care for. I like your idea of integration... have you done that before in a project? </p></pre>3zcurdia: <pre><p>In the project I am currently working we start to move into a micro-services architecture, so far we only had used ruby, but I got a couple of modules where go could really be an improvement. </p></pre>kaeshiwaza: <pre><p>Go is enough simple that you should just try and see by yourself.</p></pre>ahmad_musaffa: <pre><p>If you are beginning as a web developer, then you should probably choose Ruby. Ruby/Rails ecosystem is more beginner friendly than Go ecosystem. The most of Go developers are experienced programmers who learned programming from other languages' ecosystem and then switched to Go.</p>
<p>A beginner programmer should focus more on productivity than the scalability of the language itself. With Ruby, you may not hit the ceiling of performance at all. If you really do, only then you should look for a faster alternative (Go, Rust, Elixir etc).</p></pre>Zombayz: <pre><p>That makes a lot of sense. I suppose the only thing I don't like about Ruby/Rails so far is its monolithic nature. But yes, I should probably stick with Ruby/Rails and once I get my feet off the ground start taking on small projects in Go. Thanks for your response!</p></pre>nohoudini: <pre><p>If you build stuff in Go it's easier to share. People have generally an easier time using your software. Maybe that's also important for you?</p></pre>sleepybrett: <pre><p>If you have infinite hosting cash to burn on ruby/rail's poor performance certainly take the short term bonus of rail's framework for accelerating your development.</p></pre>Zombayz: <pre><p>Is it really that bad? Would love some more info on this.</p></pre>Xychologist: <pre><p>It's a bit harsh, but in the long run, yes. Ruby is slow to start with, especially MRuby, and then with Rails you're going through ActiveRecord for your DB, which is a convenient but not very smart bit of software. I recently joined a new company with a massive Rails monolith and am having to deal with optimising a section where loading one page makes over a thousand separate SQL queries...slowly. Admittedly that's in large part an architectural issue, but AR doesn't help.</p>
<p>If you do go with Rails, kick as much out to Sidekiq or Delayed_Job as you can, make good use of <a href="https://github.com/ruby-concurrency/concurrent-ruby" rel="nofollow">Concurrent_Ruby</a> and <a href="https://github.com/grosser/parallel" rel="nofollow">Parallel</a>, and where possible write your own SQL for anything where multiple joins are necessary.</p></pre>f00b4z: <pre><p>yes</p></pre>SYN_SYNACK_ACK: <pre><p>Disclaimer: I don't know ruby on rails but do know python django</p>
<p>Hey and welcome to <a href="/r/golang" rel="nofollow">/r/golang</a><br/>
Because you're in <a href="/r/golang" rel="nofollow">r/golang</a> most people will say Go is the way to go (hah) obviously but it really depends on what type of work you'll be doing.<br/>
If you want to do freelance work and focus on pushing out client projects fast then something like ruby on rails or python django is probably more suited for you because it gets you started really fast and you don't have to worry about a lot of decisions as they handle the routing, come with an orm and handle templating.<br/>
In Go you have to make these decisions yourself so you'll end up writing more boilerplate code to get everything working together.<br/>
Go truly shines when you're app gets hit by lots of traffic and when you venture into breaking up monoliths into microservices.<br/>
That being said I love Go and use it even for smaller private projects (e.g. stupid rest endpoints) because it's just so much fun to work with it.<br/>
Reasons I love Go: </p>
<ul>
<li>the toolchain is amazing<br/></li>
<li>the sdtlib is awesome<br/></li>
<li>the community is kind and helpful<br/></li>
<li>code quality is really high even for third party libs<br/></li>
<li>documentation quality is high even for third party libs<br/></li>
</ul>
<p>Take Go for a spin and see if you like it and then think about what you're going to work on to see if it's suited for you.<br/>
Ruby on Rails and python django are focused on development speed.<br/>
If that's important in your line of work then stick with RoR.<br/>
You can even combine Go and RoR for bigger projects e.g. build a prototype in RoR so your client can get a feel for it and play around and then reimplement it using Go. </p></pre>Zombayz: <pre><p>Thank you for your detailed response! Breaking things down into smaller micro services really attracts me. How complicated is it to attach front-end libraries such as Vue or React? </p></pre>SYN_SYNACK_ACK: <pre><p>Microservices are misunderstood because lots of folks talk about it like it's the pattern of patterns.<br/>
They're not.<br/>
Microservices come with a buuuunch of new problems that need solving that weren't problems in monolithic architectures.<br/>
Things you took for granted e.g. logging get complex when using microservices.<br/>
You've just started programming and microservices are the big buzz word right now but don't fall into the trap of designing your app in microservices from the beginning or else you'll be overengineering it.<br/>
Microservices do have a big advantage over monoliths but only if you felt the disadvantages of a monolith. </p>
<p>Lets say you're starting to work on a project and you 'feel' it could have potential to get big. Even then I'd suggest pushing out a monolith first as it's better to get out fast and get user feedback then to over engineer the architecture, something the user is completely unaware of.<br/>
Some people may disagree but when it comes to scaling in 99% of the time I'd suggest to: </p>
<ol>
<li>start with a monolith
<ul>
<li>if you gain users and performance gets worse then<br/></li>
</ul></li>
<li>start caching everything you can<br/>
<ul>
<li>if you gain users and performance gets worse then</li>
</ul></li>
<li>start multiple instances of your monolith behind a load balancer<br/>
<ul>
<li>start clustering your dbs<br/></li>
<li>if you gain users and performance gets worse or it gets to expensive to justify running all the monolith instances then<br/></li>
</ul></li>
<li>start breaking up your monolith into microservices<br/></li>
</ol>
<p>I know the feeling of wanting to get it right the first time but it really isn't worth the effort. You'll make architectural mistakes writing your app regardless even if you're using the microservices pattern from the start. </p>
<p>To answer your qustion about how complicated it is to attach front-end libraries such as vue or react I'd say it isn't. <strong>BUT</strong> like I said microservices come with a bunch of new problems to solve and one of the new problems is where does you UI come from?<br/>
Your UI now consists of multiple services so you have to have one service dedicated to assembling your UI.<br/>
What has been one request to one endpoint now is a request to n endpoints and you need to think about what it means for your app when one of those calls fail.<br/>
Then you start debugging and because all of those calls are async you can no longer read the look from top to bottom. You'll need request tracking in you're logs and some sort of context shared between you services etc etc etc. </p>
<p>tl;dr: Microservices are ONE solution to a problem not THE solution to web development </p></pre>
