<p>Hello, guys. I've noticed a lot of people switch from traditional web stack to Go. What's the main purpose?</p>
<p>There are several advantages if you think of Go <strong>as a reasonable replacement for C++ or Java.</strong> But Go also seems to have a growing popularity <strong>in web-development.</strong></p>
<p>Most Go frameworks I've seen even can't came close to 3-years-ago-Rails or any other high-level webdev toolkit:</p>
<ul>
<li>smaller ecosystem;</li>
<li>higher entry level;</li>
<li>web-frameworks in an early-stage, rising and dying everyday;</li>
<li>weak integration with modern webdev workflow.</li>
</ul>
<p>Just first things that came on mind. And despite this, a lot of people still are re-implementing the same things, which were written in other langs and work well.</p>
<p>Why people choose Go for webdev?</p>
<p>Not a holy-war, please. Thank you in advance.</p>
<hr/>**评论：**<br/><br/>titpetric: <pre><p>So, why do you need a framework again? Go has a strong standard library. If you're importing packages, they usually solve a very focused issue which doesn't fit into stdlib (like UUID generation for example), or reasonably upgrade what exists in the stdlib (I think jmoiron/sqlx is a great example of this).</p>
<p>One of the things to note as a comparison towards Node is that there's not a package marketplace. Code lives on github, and whatever package which you make might not get adopted due to various reasons from quality of code and so on. Certain package authors are thus more known than others and if you're looking for something as trivial as a configuration flags package, you're left with little but good quality choices. This just isn't possible with Node/NPM. Of course, Node has the focus split between front and back-end, so there's a lot of quirks code in Node that just doesn't exist in Go. Go is a completely server-side language, while Node tends to service a lot of front-end javascript code as well.</p>
<p>To skip over what you mean by "can't even come close to 3-years-ago-Rails" (so much for holy war intents ;)):</p>
<ul>
<li>smaller ecosystem - there are a lot of Go based projects which have terrific adoption, recently <a href="https://github.com/go-chi/chi">go-chi/chi</a> with 2500 stars on GH and very positive reviews (like sqlx builds on the underlying net/http package),</li>
<li>higher entry level - I find that when it comes to frameworks that this just isn't true. Language specifics differ (<a href="https://scene-si.org/2017/08/06/the-thing-about-slices/">how slices work, for example</a>), but you'd find those kind of issues when migrating from any language to any other language. Ruby <a href="http://ruby-for-beginners.rubymonstas.org/objects/predicates.html">predicate methods</a> for a weird example.</li>
<li>good things are improved and tailored to their specific use cases. This is normal everywhere, from the top of my head I can name a few testing frameworks from Node like sencha, karma, ava,... Go is a young programming language, where this will be more common than for example PHP. But even there, you have a lot of choice, and a lot of frameworks there also rise and die,</li>
<li>weak integration - so, what do you expect here? Angular, React, NodeJS and other similar projects build a front-end HTML website, which interfaces with the backend with APIS like REST or websocket or other choices. As such, Go is responsible for one thing, and the front-end for another. You can of course provide your own interface with stdlib <code>html/template</code> and that's your choice. These things tend to have two separate responsibilities, and it's good to lay out your projects like that as well. Less integration is a good thing, because it also means that you can replace one thing without throwing the whole thing out of the window.</li>
</ul>
<p>Mainly the selling point for me is that the quality of the stdlib, language and library is very high. It enables scaling outside of 1 CPU core with very understandable goroutines unlike Promises or yields which take some time to wrap your head around them (edit: and they don't really provide concurrency, node is a single process app). Ruby, Node, PHP and other web-development centered languages usually are single threaded and going beyond that is an add-on instead of a first-class citizen of the language, if even possible. Their memory management is poor (albeit, for atleast PHP it improved greatly over the last 15 years), and perhaps most importantly, all of them seem to fall into the scripting languages category. Compiled code will always run faster than whatever you run via an interpreter.</p>
<p>I hope this provides a bit more depth to your argument. People always reinvent the wheel, not just because they can, but also because they can improve it in some way. This can be done in small increments, like optimizing a specific function that generates a specific output, or it can be done in larger increments like creating a programming language that has concurrency as a first-order citizen. Other things might not be handled as well (which is why there's so much drama about generics in Go), but there's always space for improvement. I'm not excluding the possibility that somebody would just fork Go and provide generics the best way they see fit. People react to their experiences. If your experience is telling you that concurrency is a problem with some XY language, then you're going to find a way to solve it. Migrating to Go is a good way to do that :)</p></pre>1ngv4r: <pre><p>Thank you very much for detailed answer.</p>
<p>To be honest I'm looking for a healthy alternative to Node.js. I've got a dozen of Node.js apps, written over last 5 years. And it's getting harder and harder to maintain JS-code, even written with ES6+ features like <code>async</code>/<code>await</code>. And it's still error-prone. So, that's the choice: to get back to Django/Rails (both still rock as hell) or give a chance to something new like Golang. Thank you again)</p></pre>titpetric: <pre><p>If you're doing front-end work, esp. with popular front-end frameworks like Angular/React/VueJs, you won't get rid of Node for those, but it's a relatively healthy balance, I think. I'm sending you a copy of <a href="https://leanpub.com/api-foundations">API Foundations in Go</a> via DM, if you want/need to get started somewhere.</p></pre>kostix: <pre><p>BTW consider reading <a href="http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/" rel="nofollow">this classic dissection</a> of this "async/await vs runtime-integrated concurrency" thing.</p></pre>sqeji: <pre><p>Have a look at Elixir and Phoenix.</p>
<p>I've used Go for about 4 years and am learning elixir. With Go I find I can't create small functional units the same way I can in JS. I seem to have to do lots of for loops. Also type safety in go only go's so far. I find I get a log of nil exemptions from initiated data.
The lack of immutability leads to hard to find errors.</p>
<p>I believe Elixir leads to simpler to reason about code, especially in the context of a web server. Plus the concurrency support is probably better.</p>
<p>Maybe it's just having dived into functional JS that has ruined me for Go.</p></pre>sacado: <pre><p>Easy deployment, fast start-up, static typing and good scaling properties make go a good match in a few cases.</p>
<p>Funny thing is, C++ devs say "OK, go is a reasonable replacement for python/PHP/Ruby in webdev, but why use it in places where C++ is better?" ;)</p></pre>titpetric: <pre><p>Because C++ is harder (to the uninitiated ;)). But fun fact, recent C++ versions really are <em>sick</em> in comparison to what the language was 15 years ago. I guess the only caveat would be memory management (garbage collection, etc.), which Go and Java both have, and there's not a direct solve in C++ afaik (because more low level).</p></pre>eguanlao: <pre><p>Where I come from, our Web development is separated into back end and front end. Our back end is comprised of Java and Go microservices and AWS Lambda functions (Node.js) that expose a REST API. Our front end are React Web apps and Android & iOS mobile apps that consume our REST APIs. We chose to use Go for the following reasons:</p>
<ul>
<li>It's new.</li>
<li>It's different.</li>
<li>It's gaining popularity.</li>
<li>We were curious about its performance.</li>
<li>We were curious about how it is as a day-to-day language for development.</li>
</ul>
<p>We don't see Go as a Web development language. It's just another programming language that we can write our back-end services in.</p></pre>__crackers__: <pre><blockquote>
<p>any other high-level webdev toolkit</p>
<p>higher entry level</p>
</blockquote>
<p>That's one way to look at it. Personally, I've always found Rails, Django etc. hard to get my head around because they're so huge and there's so much "magic" going on under the hood. It all works very well until it doesn't. Or you want to do something in a different way to your framework's "blessed" methodology.</p>
<p>With Go, any layers of abstraction you've got in there, you put there yourself.</p>
<p>I find I have a much better understanding of my Go webapps than ones based on monolithic frameworks like Django. Hell, even with Flask, I'm not entirely clear on how all the "magic" works.</p>
<p>Also, Go is <em>ridiculously</em> fast compared to any of the usual suspects.</p></pre>Hunterbunter: <pre><p>TLDR at bottom.</p>
<p>I started my Uni life in C. I did some games programming in C++...fast and wonderful stuff but then I tried python. Holy shit the syntax. It was like I was holding my breath all this time and suddenly just gasped. I could breathe. 99% of questions I had were on stack overflow or within a few clicks. soo good. Development became about the problem and not the language. </p>
<p>With python I got into web development. I perhaps foolishly used web.py, which got its start in the reddit backend, and although I found it very pleasant and out of your face (but useful), it was slow as hell, and I could feel it. I know it could be sped up, but that took the complexity up to a point I was no longer comfortable.</p>
<p>I then was about to embark on a new big project. Good opportunity to see what else is out there. I did a whole bunch of research, especially on web frameworks, and Go kept being interesting. It wasn't as fast as the hardcore stuff (C++/C/Java), but generally was way faster than python. It was a compiled language, and compiled fast (yay fast like python but also fast like C++). It had <em>some</em> community support, but also had Google Engineers behind it. It had concurrency (something I dabbled in with C++, but man what a pain that was). Python just lolled in my face when I asked it to multithread. </p>
<p>I read what the designers had wanted for it. They were influenced by Python and C++. It's going to be somewhere in the middle...fucking perfect!</p>
<p>That's how I took the plunge. I've spent about a month learning the basics (and forgetting it all), then trying a few different frameworks out there. So far I've been pretty disappointed by them. Iris actually looked pretty good and the guy is commiting to it <em>all the time</em>. But he's got an incredibly toxic reputation, so sad. I spent a lot of time getting Gin to work, but it doesn't do enough and I have to figure out how to make other code work with this code, when I'm still pretty nooby about Go in general.</p>
<p>Yesterday I said enough and started again with fasthttp / fasthttprouter and kataras's go-session. I got it all working together; the page serving, static serving, basic database, authentication, sessions. I'm about 30% of the way to where I was in with my python framework. </p>
<p>I haven't needed a huge amount of help from places like stackoverflow, because the code is relatively simple to figure out. The error messages help me figure it out 90% of the time. That's actually a huge timesaver.</p>
<p>TL;DR; because I love C++'s speed but hate C++'s long ass way of doing everything, and I love Python's syntax but hate its slowness. Go is in the middle somewhere and does parallel as an added bonus.</p></pre>iburigakko: <pre><p>I did Rails back in the day. Here are some reasons I think folks migrated over.</p>
<ul>
<li>Really easy to install on your dev machine.</li>
<li>Much faster. Channels make using your CPU cores a delight.</li>
<li>Really easy to learn and hack on. And, easy to grok other Go code.</li>
<li>Basic HTTP functions are built into language. Most folks just pull in a few helper packages.</li>
<li>Deployments are a breeze.</li>
<li>Static typing means silly mistakes are caught at compile.</li>
<li>Compiling is really fast enough that it is not much different than an interpreted language.</li>
</ul></pre>atamiri: <pre><p>From my perspective, Go’s simplicity and robustness are what makes it stand out. It’s also very performant and the standard library is mature and has almost everything one needs when writing a web service/app. I was initially suspicious of Go having a GC because I had bad experiences with it in other languages but Go’s GC is really amazing and virtually never a problem (since Go 1.5 or so).</p></pre>deusmetallum: <pre><p>For me, I only write web services in go because I'm already writing other services in go, and it makes it super simple to integrate them.</p></pre>XANi_: <pre><p>Because migrating from Java won't guve you any performance benefits ( well, maybe save some RAM ), but migrating from Ruby/Node will</p></pre>Olreich: <pre><p>Those ram savings aren’t hypothetical! I’m finding Java is consistently 3x or so the memory cost for anything.</p></pre>SeerUD: <pre><p>Only 3x? I've found Go can start off at 20x less memory usage in certain cases.</p></pre>govision: <pre><p>Here is a go engineers version of why.
He is Brad Fitzpatrick and he used to write a lot of pearl/ruby/Python/JavaScript.
He even embedded some into go.</p>
<p><a href="https://youtu.be/xxDZuPEgbBU" rel="nofollow">https://youtu.be/xxDZuPEgbBU</a></p>
<p>I personally love go because those frameworks were built inspite of those interpreted languages, not because of them.</p>
<p>This guy really addresses why to use go</p>
<p><a href="https://kanishkdudeja.in/?p=108&shareadraft=baba108_59cbbcb8b061b#" rel="nofollow">https://kanishkdudeja.in/?p=108&shareadraft=baba108_59cbbcb8b061b#</a></p></pre>goenning: <pre><p>About an year ago I started working on Fider ( <a href="https://github.com/getfider/fider" rel="nofollow">https://github.com/getfider/fider</a> )</p>
<p>The reasons I chose Go were:</p>
<ul>
<li>It's simple and easy to learn</li>
<li>Single binary output. This is a big win!</li>
<li>Few runtime dependencies. My docker image is only 8MB large.</li>
<li>It's fast and has low memory footprint -> less money spent on servers</li>
<li>The popularity is increasing</li>
</ul>
<p>The bad:</p>
<ul>
<li><code>html/template</code> is not good enough for webdev, which is why I chose React for the view components.</li>
<li>Generics? haha :)</li>
<li>Folder structure is more strict than any other languages</li>
</ul></pre>SeerUD: <pre><blockquote>
<ul>
<li>smaller ecosystem;</li>
</ul>
</blockquote>
<p>This is something I've noticed - but you only notice it when you step outside of common tasks, and even then, only sometimes. For what Go is usually used for, there are some extremely solid library choices.</p>
<blockquote>
<ul>
<li>higher entry level;</li>
</ul>
</blockquote>
<p>Go is designed to be easy to learn, and frankly, it is. It's a very consistent language, with great documentation, and a great set of introductory material to get you started. The language itself is small, and the standard library helps you get things going without having to learn about loads of other libraries too.</p>
<blockquote>
<ul>
<li>web-frameworks in an early-stage, rising and dying everyday;</li>
</ul>
</blockquote>
<p>Many people don't use frameworks. I don't really care if people do, but personally I don't. If you're using Go for what it's good at in the context of the web (i.e. web services, not applications) then you'll likely find you have a better time just piecing together libraries.</p>
<blockquote>
<ul>
<li>weak integration with modern webdev workflow.</li>
</ul>
</blockquote>
<p>Not sure what you actually mean by this. You expose endpoints, something else picks it up. It's a very modern approach indeed. Sure, you're not going to server-side-render your React app with Go (probably anyway), but you still have the tools that are good for that at your disposal.</p>
<p>There are a LOT of reasons to choose to use Go, some of which I've hinted at above. It's just an all-round solid language. I went hunting for a new language to learn coming from PHP, and I wanted something with a great developer experience (fast workflow, good tooling, good editor support, etc.) and Go fit the bill bests out of every language I found. It's got a decent community, a good set of libraries, and the features of the language are a careful balance that works well to keep code simple.</p>
<p>Another language I tried was Scala, and I did really enjoy it at first, but then got bogged down in the language complexity, and the terrible developer experience (incredibly slow compile times mainly - seriously, it's insane how slow it is). I do miss the type system from Scala sometimes, but generally the trade-off is worth it to be using a language where I can dig around in the standard library and understand how it works because the language is so clear.</p></pre>Innominate8: <pre><p>Go has a similar pace of development as dynamic languages, but with the debugging and reliability benefits of static typing.</p></pre>
