From Node.js to Go

I&#x27;e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations:<p>- The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python&#x2F;Ruby background, that was nice to see.<p>- I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.<p>- The tooling for Go is excellent: More languages need something like &quot;go fmt&quot;.<p>- In general the document is solid, but I&#x27;ve found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...<p>- I&#x27;ve noticed a lot of Rust lovers commenting about how great Rust&#x27;s type system is. It probably is, but I haven&#x27;t run into any problems with Go&#x27;s type system. I&#x27;ve found it to be practical and easy to use. The only issue is parsing JSON when you&#x27;re not marshalling it to struct. They need to fix that (although there are some nice third-party tools to make it easier).<p>- Go is a minimal language and has been called boring. [2] I don&#x27;t claim to be an expert yet, but I don&#x27;t think I&#x27;ve reached this level of productivity with a language this quickly before.<p>[1] <a href="https://github.com/tools/godep" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tools&#x2F;godep</a><p>[2] <a href="http://stevebate.silvrback.com/go-is-boring" rel="nofollow">http:&#x2F;&#x2F;stevebate.silvrback.com&#x2F;go-is-boring</a>

This is just another generic Go vs Node post. Do we really need another post telling us about Go&#x27;s concurrency&#x2F;built-in features&#x2F;compile benefits.<p>This post sadly doesn&#x27;t really go into much details that bowery.io is trying to solve, how Go fits that and why Node was so bad.<p>A basic crud webapp would probably be better suited towards node and it&#x27;s larger list of libraries supporting that kind of stuff.<p>On the other hand, building you own messaging queue or doing heavy mathematical processing might be better suited for Go.

&gt;In Go, you can define different files for different operating systems that implement functionality depending on the operating system.<p>That sounds like it&#x27;s actually very difficult to support multiple operating systems. As a developer I never, ever want to write any OS-specific code. Sure, that&#x27;s sometimes required, but saying that the solution is to have multiple files, each for a single OS, doesn&#x27;t sound good. It&#x27;s a lot better to abstract the OS away. Node.js does this quite well. Seemingly a lot better than Go.<p>Besides, Node.js doesn&#x27;t need to be compiled for each system. This alone makes Node.js better for writing code for multiple operating systems.<p>&gt;Go is a compiled language so distributing applications for use on multiple platforms is just easier.<p>I disagree. You need to compile to code for every single platform, making code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform. (The probability is as high as it is for Go assuming no extra work for a new platform). Sure, each platform needs to have Node.js, but Node.js is supported in most platforms.

&gt; Go is a compiled language so distributing applications for use on multiple platforms is just easier.<p>How is this a true statement? Ease of distribution isn&#x27;t a function of a language&#x27;s runtime environment (native vs interpreter).

For me the single biggest disadvantage of Go against Node.JS is the lack of a decent dependency management solution. NPM is awesome and Go doesn&#x27;t even have a &quot;meh&quot; answer to that.

Go does lack quite a bit of the web pizzazz you&#x27;d find in rails, but I learned a lot more by writing web things in go than I did in rails because so much less of the magic is hidden away from you.

For testing frameworks, standard library tasks, workflow: he author prefers less choice and more standardisation, hence Go &gt; Node.js.<p>Which I find very disappointing. One thing that I learned, if some standardization happen and you have to use it, it will cause you pain eventually.<p>Obviously, there is honey-moon period and a clear path what to do if you only got &quot;one&quot; standard, but the author will eventually there is no free-lunch. The standard will be insufficient for some his usecases and then what....<p>Node.js out of the box embraces multiple solutions - I know this can be overwhelming, but it gets better over time not worse. When you know, the trade-offs between the different choices, you feel empowered to pick the best tool &#x2F; lib for the job.

Go is definitely promising but the last time I checked the problem with web development with Go was that there is no mature libraries for User authentication etc(Please correct me if I&#x27;m wrong). This makes going with Node or something like Rails more tempting.

I wish a language with advanced types like Haskell or OCaml would have the same tooling and ease of distribution around it that Go does. I haven&#x27;t built anything in Haskell&#x2F;ML in a while, so if anyone has any updates on this please chime in.

So is this is a growing sentiment? Recall that TJ famously left Node.js in favor of Go.<p>I find Node downright amazing for web development. npm has everything you could ask for. And the whole community takes the unix philosophy and runs with it. Also love that there&#x27;s no single best way to create something, you as the architect, gets to decide.<p>And io.js&#x2F;ecma6 makes node even more appealing.

I disagree with the concurrency part. Node.js has excellent built-in IPC support through the process and child_process objects.<p>Since Node.js is JavaScript, you can&#x27;t possibly argue that Go code is more &#x27;portable&#x27; than Node.js. For one, JavaScript can run on more machines than any other language.<p>Go will not run in the browser because most browser vendors will not let that happen. On the other hand, JavaScript is already universally accepted by everyone and it&#x27;s everywhere - You can run JS in the browser, natively on mobile devices, on the server, on set-top-boxes, on robots&#x2F;IoT devices and just about everywhere you can imagine. Anybody can implement and modify their own JavaScript engine to suit their specific needs.<p>No need to worry about protocols - Since JSON is a subset of JavaScript, you can seamlessly pass objects between the client and the server and no need to context switch between programming styles when going between client and server.<p>People who don&#x27;t like JavaScript mostly feel that way because they don&#x27;t understand it well enough (it&#x27;s a lot more expressive and powerful than people imagine). I have programmed in many different languages - C&#x2F;C++, C#, Java, ActionScript 3, Python, AVR Assembly (ATMEL ATMEGA8-16PU microcontrollers and family) and a few others but I feel that no other language has the expressiveness and elegance of JS.<p>Before I got into Node.js, I considered myself &#x27;language agnostic&#x27; because I often switched between languages because no one language could do everything I needed. I no longer consider myself an agnostic - In fact, I feel quite comfortable saying that C&#x2F;C++ and JavaScript are the only two languages worth knowing.<p>In reality, you can&#x27;t be &#x27;fluent&#x27; in that many languages because fluency requires constant practice - It makes sense to settle on fewer languages - Mastering a language&#x2F;tool allows you to focus on what&#x27;s really important - Logic and structure.

They left out the most obvious reason for them to switch. Their business is based on docker, coreOS etc . . . aka the Go ecosystem. In that context developing Go expertise just makes business sense regardless of technical merits.

It is frustrating to see how many Go vs Node posts are happening here. I have been implementing a bluetooth LE module in Go, and due to lack of some robust libraries, had to go back to Node. This is primarily a question of maturity, but I also realised that my use-case didn&#x27;t really need the thing which Go is most useful for - namely really really good concurrency primitives. I am quite sceptical about Node&#x27;s future because of that forking fiasco, but at this point in time, both Node and Go provide enough distinct functionality that both will be used for a long time.

I&#x27;m primarily a mobile dev, so the biggest impediment to me adopting Go over Node is the fact that converting and manipulating my data models to send as JSON documents is considerably harder on Go - there&#x27;s no Go equivalent to Gson yet, nor will there likely ever be due to the nature of the language.

I&#x27;m having a hard time enjoying Go. It just reminds me a little too much of Java, and I programmed in that language for way too long. After I finished my test program, I uninstalled the toolkit from my system. Right now, I feel that there&#x27;s no perfect language for me. I do love JavaScript, but there are some things I wish they&#x27;d fix. And it takes browser makers way too long to support the latest features. Been messing around with Erlang. Kind of an interesting language.

&quot;but he didn’t learn his lesson there&quot;<p>This set me up for a negative article about Go, but, like other Go-related materials, it makes me want to use it. I should use it.

I for one hail our Go overlords, because that way it will mean less Python, Ruby and Javascript code for serious stuff like backends.. Given the language will please this crowd.<p>Theres a lot of good stuff, created by good people, in those languages and while the solutions are great, the fact that they are in those languages, make them unfit for a lot of cases.

It&#x27;s interesting the switch was prompted very few things that are JS vs Go, perhaps concurrency. The main factors were tooling related, enabling stable workflows and easy deployment.

One thing I hate about JS and the thing I love about Golang: the error handling. I love that there is only one way to do it in Go.<p>ok, More actually. Some APIs return ok instead of err.

Why on earth would a line editor need platform specific code? Sounds like a case of that&#x27;s-a-cool-feature-let&#x27;s-use-it!!!

Golang only 2x ruby at net&#x2F;http level and same as ruby at web framework level ?<p><a href="https://news.ycombinator.com/item?id=8964255" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8964255</a>