<p>I'm a front-end developer but I have coded with a few other languages. Did some PHP projects in the past (with laravel), created a desktop app with Java and I use a bit of C in college. Also did a website with ruby and rails.</p>
<p>I've been working only with javascript for a couple years at least in the front-end (building SPA's etc) and it's been a while since my last back-end work.</p>
<p>I'm creating a new project that is basically like iFood. I'll register stores, and will sell their stuff through the website. I assume this website will have a lot of traffic, and I want to create an admin panel for the store owners that will be real-time and have detailed analytics of data. </p>
<p>I was thinking in doing this with Node, since JavaScript is my main language and I have some confidence to do it in Node because I fiddle with it sometimes. However, I've been reading a lot about Node recently and a lot of people are making good points on why not to use it, one of the main reasons being that JS is in general, a bad language (in which I aggree). So i want to get out of my confort zone and write the backend in something totally different and more reliable. I've never written a single line of Go yet - would Go be a reasonable choice to do what I want? How people is hosting go apps these days, and which framework should I use (if any)?</p>
<hr/>**评论：**<br/><br/>tmornini: <pre><p>I'd recommend you pull back a bit and learn something even more fundamental.</p>
<p>The concept of a "web app" is somewhat nebulous. Many people that use that term think in terms of an application running on a server that renders HTML pages for the browser.</p>
<p>The development style is, IMHO, completely outdated at this point, as it typically does not provide the right interface for mobile app development -- though some frameworks allow for a "web app" and API all in one. Rails is a good example of a framework that allows for this.</p>
<p>Modern development, in my opinion, begins with a static HTML/CSS/JS web site that makes HTTP API calls to an entirely <em>separate</em> backend API. This extends nicely to mobile app development, as you can have a native mobile application that uses the same APIs.</p>
<p>Go is a <em>terrific</em> language for backend APIs.</p>
<p>Javascript is, short of transpilation, the <em>only</em> language that runs in browsers, so it's the simple choice for the front-end UI browser application.</p></pre>pietrofxq: <pre><p>I agree with you. I'm a frontend developer and I work with modern webapps - pretty much 100% dependent on javascript in the browser and only consuming api calls in the back-end. Can you elaborate why Go is terrific for backend APIs? Would I ran into trouble to create endpoints that talk with the database (maybe a no-sql one) and return JSON?</p></pre>mixedCase_: <pre><p>terrific = very good</p>
<p>terrible = very bad</p></pre>tmornini: <pre><p>Please elaborate? :-)</p></pre>mixedCase_: <pre><p>He seemed to have confused the two words.</p></pre>VirmundiUndead: <pre><p>No, go is good at that. The reason it's good at API level stuff is that it is compiled so you get good errors before you deploy, you have tool in to do API stuff built into the library, and you get a simple binary to deploy. </p>
<p>Go has decent drivers for all the big SQL DBs as well as Mongo and ArangoDB for document storage. </p></pre>tmornini: <pre><p>And it easy to deploy.</p>
<p>And it's "<a href="https://medium.com/@chrisgregori/i-wrote-some-golang-and-it-felt-great-3c3367a67db5" rel="nofollow">fast as fuck</a>"</p></pre>tmornini: <pre><p>Go is terrific for backend APIs because:</p>
<p>1) It's fast, way fast, super fast, crazy-wicked-fast.</p>
<p>2) It's tiny and simple: if you built micro-services style, total deployment size per micro-service will be under 10 MB, and a Docker container can be built that is also under 10 MB.</p>
<p>3) It's asynchronous and uses multiple CPU cores of HTTP requests out of the box.</p></pre>daniels0xff: <pre><p>How do you handle search engines for cases like these? I would love to just separate things like this but if you do something that needs good indexing by search engines what do you do? </p></pre>tmornini: <pre><p>There's no difference in search engine issues.</p>
<p>Just think about it as using an API to store your data rather than a database...</p></pre>Franke123: <pre><p>I would recommend learning Go and using it to make the app <em>only</em> if you are sure it's going to be worth learning a whole new language, and while Go isn't too hard to learn (especially if you aren't doing any fancy stuff with channels or too much with concurrency outside of using the net/http package), I would think you'd make a better app in a language you've actually done than one you have to learn, no matter whether Go is better or not.</p>
<p>Then again, even if you don't make <em>this</em> app in Go, no reason you still can't learn it! Use it in the future possibly too!</p>
<p>my 2c</p></pre>pietrofxq: <pre><p>I do think that learning Go will have a positive impact in my programming carrer, as learning any new language do. The main reason to switch from JS though is to use a less error-prone language, and also to get out of "npm hell" that is the node ecosystem these days. This app is a personal thing, so this is one more reason to learn something new - otherwise I'd sure be using something I'm already good at. I'm considering Elixir and Go, but Go seems to be the choice of a lot of people that were working with Node before (one of them being one of the creators of Express).</p></pre>Franke123: <pre><p>Sounds like some good reasons to me, go for it!</p></pre>tylermumford: <pre><p>I love using Go because it makes maintenance and deployment really simple. (Seriously, once you deploy a Go binary, everything else will look hilariously overcomplicated.) It's also nice to use the standard library for almost everything, although I imagine this approach can be slower than finding a good library or two. In any case, Go is absolutely a reasonable choice.</p>
<p>However, the abstractions that Go encourages you to make are different than other languages. Where Java encourages OOP, Go encourages composition and interfaces. Where Node encourages callbacks/promises, Go encourages channels. It's a different way of thinking, but I find it enjoyable.</p>
<blockquote>
<p>which framework should I use (if any)?</p>
</blockquote>
<p>The community seems to think that you don't need a framework to make web apps, and I'd have to agree. It's pretty easy (or at least straightforward) to wire up your app using the standard library, maybe with a routing or a template library thrown in for good measure.</p>
<p>Oh, and check out <a href="https://caddyserver.com/" rel="nofollow">Caddy</a>. It'll change your life.</p></pre>pietrofxq: <pre><p>I've checked out Iris, Revel and Gin frameworks - are they worth giving a try? My back-end will be mainly rendering dynamic HTML, some REST endpoints and database access. My concern with using a framework is in having to build things from scratch like routing, POST api calls parsing and html rendering like you'd need to do using pure Node (without express/koa plugins)</p></pre>patrickdappollonio: <pre><p>Check <a href="http://gobuffalo.io/docs/getting-started" rel="nofollow">Go Buffallo</a>, from Mark Bates, cool guy, cool tool!</p></pre>pietrofxq: <pre><p>Looks really interesting, but looks like it lacks support for no-sql databases, which is what I'm planning to use</p></pre>mixedCase_: <pre><p>Is your data non-relational? Almost no application benefits from "NoSQL" databases. Even the big players often use relational databases with a non-relational schema (Uber is an example).</p>
<p>Also, no, these frameworks are not worth a try. The standard library is already a framework. If you want more performance, which is usually the shiny selling point of these frameworks, get a better <em>router</em> (I like <a href="https://github.com/pressly/chi" rel="nofollow">Chi</a>) rather than a whole unidiomatic ecosystem.</p>
<p>If you need middleware, the <a href="http://www.gorillatoolkit.org/" rel="nofollow">Gorilla toolkit</a> is able to cover most needs.</p></pre>pietrofxq: <pre><p>I was actually also wanting to give no-sql a try and see why people usually say it's bad. My data will be very variable in a sense that a store can post any kind of product, and be able to add steps to the purchase (like adding/remove stuff etc), but I think a relational database would be just as good...</p></pre>mixedCase_: <pre><blockquote>
<p>give no-sql a try and see why people usually say it's bad</p>
</blockquote>
<p>It's not that it's bad (except for Mongo, whose implementation has been riddled with issues, many of them fixed, but still doesn't inspire confidence), it does one thing great: Help scaling <strong><em>non-relational data</em></strong> access and storage in a trivial way.</p>
<p>The thing is: The overwhelming majority of applications out there manage <strong><em>relational</em></strong> data. And for dealing with that we have a solid mathematical foundation (relational algebra), which is the basis for SQL and relational databases.</p>
<p>You mentioned products, purchase and purchase items in your comment. That's relational data. It's not that a relational database would be just as good, it would blow these NoSQL databases out of the water for dealing with that data because it's designed to handle all that efficiently with man-centuries of work put into it; while non-relational databases are much simpler.</p>
<p>At the end of the day these technologies all have tradeoffs to suit different purposes, but with databases you can follow a simple rule to get it right: If your data is relational, use a relational database. If your data is non-relational, <em>consider</em> non-relational ones, but if the data set is important still go with a relational one and only think of switching once you hit growing pains.</p></pre>brianvoe: <pre><p>I would highly recommend reading this article that talked about someone using node, having problems and how they were solved extremely well in go.</p>
<p><a href="https://medium.com/@chrisgregori/i-wrote-some-golang-and-it-felt-great-3c3367a67db5" rel="nofollow">https://medium.com/@chrisgregori/i-wrote-some-golang-and-it-felt-great-3c3367a67db5</a></p>
<p>Dont let learning a new language stop you from building a new app in it. I learned that the hard way. Iv'e used both PHP and Node and as soon as they go to any decent size they start showing there limitations in a big way. Go doesn't do that to you!</p></pre>jimpeak: <pre><p>If you are heavily relying on a database (i.e. you need some kind of ORM and deal with nullable ints, dates, strings, etc.), you better avoid Go IMHO. </p>
<p>I know there are new ORMs in the ecosystem now, but back when I started working on a similar project, I found it very tedious to use nullable types everywhere and developing my own wrapper types. I felt I was reinventing the wheel all the time.</p>
<p>You could always rely on code generation, but then again, it won't feel natural as it would in C# or Java even. My guess is node makes this super easy, although I know almost nothing of that technology apart from the pretty terrible package manager (again IMHO).</p></pre>tmornini: <pre><p>You're far better off if you never use nullable columns...</p>
<p>There's really no need.</p>
<p>The solution is simple, elegant, highly performant and storage efficient.</p>
<p>And it completely eliminates what appears to be your main reason for not using Go.</p></pre>no1youknowz: <pre><p>Please please don't put your own limitations on other people.</p>
<p>I've never used an ORM ever. How about telling people instead to actually learn SQL and use hand written queries?</p>
<p>You can use Go with a database just fine. I've used Go with Mysql, Memsql, Postgres, Aerospike, Redis, etc.</p>
<p>Databases aren't that actually hard to use, you know...</p></pre>jimpeak: <pre><blockquote>
<p>Please please don't put your own limitations on other people.</p>
</blockquote>
<p>I just exposed a scenario for which I don't think Go is better suited.</p>
<p>I did plenty of raw SQL in Go and my points are still valid: you still have to deal with nullable ints, dates, strings and wrapper types, even more so. </p>
<blockquote>
<p>Databases aren't that actually hard to use, you know...</p>
</blockquote>
<p>Where exactly I said databases are hard? Sometimes, an ORM makes sense. I never implied databases are hard. Only that Go makes it more tedious than it should compared to some alternatives.</p></pre>no1youknowz: <pre><blockquote>
<p>you still have to deal with nullable ints, dates, strings and wrapper types, even more so.</p>
</blockquote>
<p>so? it's not that much of a big deal to deal with these issues. </p></pre>tmornini: <pre><p>Particularly if you never use nullable columns...</p></pre>no1youknowz: <pre><blockquote>
<p>Particularly if you never use nullable columns...</p>
</blockquote>
<p>Which are no problem still...</p></pre>shadowmint: <pre><p>No.</p>
<p>If you know javascript and node already, this sort of project would be better done in typescript I imagine; the node ecosystem of 3rd party packages is more mature and robust than the go one.</p>
<p>Many go libraries exist for the same sorts of tasks, but:</p>
<ul>
<li>It lacks a package manager.</li>
<li>Different packages use a variety of different package management hacks / 3rd party tools.</li>
<li>There's no good high performance orm and auto migration story.</li>
<li>The ecosystem of middleware is smaller and poorer because there is 'standard framework' that people have centralized around.</li>
</ul>
<p>What go <em>does</em> give you is an <em>excellent</em> parallelism and deployment story; I would totally recommend learning go and picking it up for a small project to see how you feel about it and if you're happy to work around the limitations it has.</p>
<p>...but not this project. </p>
<p>I don't see anything in your task is node is particularly poorly suited to; I can almost guarantee doing it in a language that you already know will be more successful than trying to learn go <em>and</em> build a large project in it at the same time.</p>
<p>Try making a user authenticated 'todo list' app in go and see how you like it. You'll stumble straight and immediately in the problems with go web development and you can see if you're happy with the comprises or not.</p>
<p>Personally? If you need something more serious and reliable, I would use java or C# to build the platform you're talking about if you're serious about it. </p></pre>Growlizing: <pre><p>Very good advice.</p>
<p>There is also a rule of thumb I would like to mention. In a serious project, you can afford one experiment. A new configuration tool, a new library, a new testing framework. Keep it to one experiment, or your project becomes an experiment. Using a new language, producing quality features and decent tests does not happen all at once.</p></pre>shadowmint: <pre><p>This is great advice. :)</p></pre>pietrofxq: <pre><p>Thanks for your response. Would you recommend another language that would be suited for the project? I'm very interested in Elixir as well. But I'll take your advice and do some programming in Go first and see how it goes. With Node I know that for every problem I'll encounter it's likely to exist a solution for it and it be in a package - but this is one of the reasons that I'd like to try something different. In the Node ecosystem you have to depend a lot on other people code and it kind feels weird to "npm install" a hundred packages. Ironically, this is what makes Node productive.</p></pre>shadowmint: <pre><p>Pheonix (<a href="http://www.phoenixframework.org/" rel="nofollow">http://www.phoenixframework.org/</a>) is also an excellent choice for doing high quality work in elixir and I totally recommend it, but once again: all I can say is that using a new language/framework/platform for a project is super risky.</p>
<p>There are plenty of mature platforms you <em>could</em> use; Spring, .Net core MVC, pheonix, django, rails... but really, I guess my only practical advice is break it down into a couple of choices that you like and try them out. Build a few small things in them before you try to build a big project.</p>
<p>If you're really set on doing it in something different, elixir is pretty reasonable choice.</p></pre>LeBuddha: <pre><blockquote>
<p>i want to get out of my confort zone and write the backend in something totally different and more reliable</p>
</blockquote>
<p>Elixir definitely will get you out of your comfort zone <em>and</em> it's a "good language". Golang is also a great nodejs alternative, especially when 10x-100x faster is what you're looking for.</p></pre>shadowmint: <pre><p>I categorically challenge any 100x speed up benchmark for node vs go until I see the code from both, and the actual raw data. I just cannot believe it.</p>
<p>People spouting this kind of stuff are either doing very specific things that most people aren't doing, or doing it wrong in node if they're getting that kind of speed up (and if you're referring to that recent article, it <em>is</em> because they were doing something most people aren't doing, highly concurrently). Node is a highly <em>highly</em> optimized runtime, that is, despite javascript being a pile of steaming goo, really very fast and good at what it does.</p>
<p>I think we can safely say that go is great, but if you're expecting 2 order of magnitude speedup from using it for a generic web app, you are just plain dreaming. It won't happen.</p>
<p>What <em>will</em> happen is you'll struggle with the tooling (like migrations), the package management (because GOPATH is a stupid idea, and luckily <code>dep</code> will help us solve that eventually) and a lack of 3rd party ecosystem for middle ware.</p>
<p>You've just got to be pragmatic about it; yes, you can build excellent little services in go which are quick and easy to deploy.</p>
<p>...but no, it's not a drop in replacement as an application platform for node. Not. Even. Close.</p>
<p>...and you <strong>will not</strong> get a 100x speed up from using it.</p></pre>LeBuddha: <pre><p><a href="https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node" rel="nofollow">https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node</a></p>
<p>Based on this article I would estimate a more accurate speed comparison maybe that golang is typically 2x-20x faster. And those benchmarks probably miss the "real world" qualifications. Also the memory footprint is probably generally 10% of node's. If you have a better way to describe how much faster golang is than nodejs, I would love to hear about it.</p>
<p>Also that's a good point about golang's lack of a "Rails". Node's ecosystem is certainly ahead of golang in terms of Rails alternatives, but I don't know if golang has anything "Rails enough". It's pretty common for somebody to says "Yeah, who needs Rails, X has everything and is way better than Rails" then when you take their word for it, it's only 5% of what Rails is and what is available is experimental.</p></pre>schlinglebop: <pre><p>If you know your requirements write in Go. If the requirements will change constantly I'd use python or JS. </p>
<p>Go provides code stability and performance while node, python provides writing faster code.</p>
<p>You may want to write in Go just the sake of learning pointers, uniqueness of Go, typed languages etc..</p>
<p>It's your call. </p></pre>ferociousturtle: <pre><p>I haven't written a full-fledged website in Go, but I've done it in C#, Node, and Rails. I think it's <em>easier</em> to iterate on C# than it is on Node/Rails due to easier refactoring, compile-time checks while you move fast. Just my 2 cents. I suspect the same is true of Go.</p></pre>schlinglebop: <pre><p>Interesting. I find rails lot more easier. One command and you have an admin panel. Magic like those dont exist in Go. Research will be needed and probably you'll need will write some stuff from scratch.</p></pre>ferociousturtle: <pre><blockquote>
<p>If the requirements will change constantly I'd use python or JS.</p>
</blockquote>
<p>This is what I was referring to. I find that if requirements are constantly in flux, it means I'm doing lots of code reorganization, and if I'm doing lots of code reorganization, static typing speeds things up significantly in my experience.</p>
<p>I would say that if you are looking to generate lots of UI out of the box (e.g. admin panels, etc) then GO is not the best. But honestly, I never used generated UIs out of the box.</p></pre>
