Node.js vs Golang: Battle of the Next-Gen Languages

Node.js vs Golang

Recently, there have been criticisms about the value of using Node.js in a high-performance, networked application environment, and some developers have moved to the Go language.

There are also several high-profile corporate examples switching to using Go, beyond the creator of the language, Google. Dropbox has moved to Go, claiming significant performance increases, and the developers of the Docker virtualization system are also using Go.

It’s important to note, however, that Node.js is still used by a much wider audience, has more modules, is easier to use, and isn’t going anywhere anytime soon. Also, if you’re making a web application, Node.js will probably be your language of choice, as Go is currently used more as a scripting language when focus on concurrency and speed is the priority.

In this article, we will take a look at the differences between Node.js and Go from the developer’s point of view to uncover the strengths and weaknesses of each environment.

Node.js and the Javascript Language

Node.js Emblem

Node.js emblem

Node.js (and its recent fork, IO.js) is an increasingly-popular platform built on a fast, JavaScript-based runtime: V8.

V8 is a JS virtual machine created by Google that is designed to build scalable, networked applications. It compiles JavaScript code to native machine code, using some complex optimizations. V8 also does the memory allocation and garbage collection of JS objects.

Though these dynamic optimizations for a dynamically-typed language offer a lot of flexibility for developers, they do come with some performance costs at times.

As Node.js is written in JavaScript, it inherits most of the properties of that language. JavaScript is so popular these days that the ECMAScript standard development is done mainly in an evolutionary fashion, rather than a revolutionary fashion.

This has some important side effects for JavaScript and Node development:

  • Some of the JavaScript language flaws are difficult to fix without breaking backward-compatibility, though the worst issues are being fixed.
  • Useful, but radical, JS language features may not be implemented or only be “patched on” as an add-on syntax. This can lead to a messier language design compared to languages that integrate features cleanly into their design. A good example of this is concurrent computing with JS. JS best practices for concurrent computing went from a concurrency API (using event-based callbacks), to the devolopment of promises, to the coming support for async generators. These days callback hell is still a serious issue with many Node.js applications; however, this has led to less readable code, slower development, and perhaps even more bugs.

All this means that the JavaScript language evolves rather slowly (and some would say poorly too), even when good concepts from other languages are known to work better.

Node.js still has a huge community and tons of great applications being written for it, so we don’t want to scare you away with some of its pitfalls in small cases; it’s still a great platform to work with, according to the vast majority of developers.

The Go Language or Golang

The golang gopher

The Golang Gopher

Go, which is also referred to as “Golang,” is a compiled systems-oriented programming language started by Google in 2007. Go can be considered the result of a rather conservative language evolution from languages such as C and C++.

Go improves upon some of the misgivings of those languages:

  • poor dependency management
  • cumbersome type systems
  • difficult memory management
  • lack of parallel computation support
  • lack of multi-core support

Go also reduces the amount of code typing needed by being more expressive than C or C++.

Go makes it much easier to write robust, networked applications, without sacrificing much in the way of performance, compared to C or C++. The high performance is in large part due to the static compilation of the statically-typed Go code. A lot of optimizations are possible when a compiler can do all the code inspection work beforehand, as opposed to the dynamic JS compiler work done during runtime.

Golang vs Node.js Comparison of Features

We can begin to see why, for some types of application development, it might be useful to use Go instead of Node.js; however, Node.js is still a very useful language in many use cases.

Let’s compare the strengths and weaknesses of each programming language, so it may be easier to choose which environment is the right tool for your next job.

Go Node.js
Maturity Mature and robust for its age Mature, but the API is still somewhat changing. The recent IO.js Node fork changes might also become a cause for API problems for developers writing and using Node modules. How big this problem will be is not clear right now.
Performance Similar performance characteristics as with C or C++, which is to say very good Due to JS’s dynamically-typed nature, Node can not reach the raw performance of CPU or memory bound tasks that Go can achieve in many tests. However, in the common use cases where network communication or database interaction are involved, the performance of Node and Go are often equal.
Concurrency Go uses coroutines called goroutines. A goroutine is a lightweight thread managed by the Go runtime. Communication between goroutines is done very elegantly using channels. For more, see this video. Node suffers from JavaScript’s less than elegant concurrency support using the event-callback mechanism. However, for a lot of applications, working with JS promises and the coming async generator support (also called “semi-coroutines”) will suffice. Something like the Koa framework is already supporting the async generator approach in Node.
Scalability Go was really designed for scalability and concurrency, without too much hassle. Several people and companies using Node.js have made claims that Node has some problems in environments which need to scale massively. Perhaps Node can overcome these massive scaling issues in time.
Ease of Development People coming from a JS/Node background will need to learn some new programming concepts, such as: coroutines, channels, strict typing (with compilation), interfaces, structs, pointers, and some other differences. For a JS developer, it is really easy to get into Node programming.
Frontend & Backend Though you can run Go code in the browser using gopherjs, JS still is the way most developers like to program the frontend. Go is aimed more at the backend, in particular for developing high-performing concurrent services on the server-side. Not having to do a mental context switch while developing a JS-based client-server system is really nice.
Packages & Tooling The number of standard Go packages is growing steadily, currently at over 100, and the Go community packages can be searched easily. Though there aren’t as many different developer-friendly application frameworks to choose from as compared to Node yet, you can take a look at the “go get”-able packages from the Go community, which currently sits at over 58,000 available for use and growing. The number of Node packages sits at more than 100,000 currently. This means that a lot of groundwork has been done, and that can make certain software projects a lot easier and/or cheaper to implement. Node’s tooling is also superb. The npm package manager learned from all the package managers that came before and did most things right.
Developer Mindshare A recent study showed the rise of Go to a place in the top 20. The pace at which this happened exceeded expectations. Go definitely has a lot of momentum building up, especially with the recent support of the Android mobile OS. Node is much more popular at this time by many orders of magnitude. Getting good hosting support, commercial support, and Node.js freelancers for your project will be much easier for NodeJS at this point in time.
Error Handling Error handling in Golang requires you to implement explicit error checking, which can make error troubleshooting difficult. However, some argue that you get a cleaner application overall, once you understand Golang error handling. Error handling in Node.js can be inconsistent at times, but it does offer the more common throw/catch mechanism for errors that developers are accustomed to using with other languages.

Summary of Node.js vs Golang

The choice between Node.js or Go very much depends on which type of development suites you best and how massive the network service needs to scale.

Go may not yet have all community packages or mindshare that Node has, but its syntactically cleaner concurrency model, better raw CPU- and memory-bound performance, and its ability to scale up better with concurrent loads could make for a better foundation for certain network application types.

If you need certain Node.js packages that are not yet available for Go and that would be difficult or expensive to re-implement in Go, then Node may be the wiser choice.

If you feel like installing Go on your Ubuntu/Linux system, have a look at our guide to installing Go. Then visit GoByExample and the online Go book for some more great tutorials.

If you wanted to give Node.js a shot, be sure to check out our guide to installing Node.js, as well as our list of free Node.js hosting services. Then head on over to for some great tutorials on programming with Node.js.

Questions or Comments? Ask Jacob!

Ask a question and Jacob will respond to you. We strive to provide the best advice on the net and we are here to help you in any way we can.

  • Dmitry Vyukov

    You point to and at the same time say “dwarfs the packages available for Go (in the hundreds currently)”. Only contains 58000+ packages. Please fix the article.

    • Hello Dmitry,

      Thank you very much for your great comment and the additional information. I’ve gone ahead and updated the article to reflect that while the standard packages available in Go is only in the hundreds, the ‘go get’able community packages is up over 58,000 and growing.

      We always strongly value developer and reader input, so thanks for taking the time to stop by and help us get the best advice out to the masses!

  • Hello Dmitry,

    Thank you very much for your comment and the additional information. I’ve gone ahead and updated the article to reflect that while the standard packages available in Go is only in the hundreds, the ‘go get’able community packages is up over 58,000 and growing.

    We always strongly value developer and reader input, so thanks for taking the time to stop by and help us get the best advice out to the masses!

  • Ken Fromm

    FWIW, we wrote a couple of posts on our experiences in moving from Ruby to Go for our API and backend service architecture. We did this several years ago and it was one of the best decisions we could have made.

    • Wow thanks Ken!

      I read over your blog posts and that’s very cool to see was the first company to post a Go job on the Golang message board, and that you ended up snagging one of the core Golang developers.

      Any updates since the end of 2013? Are you even more proficient with Go now as more developers are using it and more packages have become available?

      • Ken Fromm

        Our productivity and usage have improved over the years but a large part is just being able to hire great Go developers. Go does provide a definite advantage because good systems engineers like to work in Go.

        There were a few issues we ran into in the first year with low-lying bugs within packages but those were fixed pretty quickly once we were able to pin them down. The larger issue we’re running into now is around dependency management. There’s some tooling around it (godep) that works well but there are still hoops to jump through to allow for easily reproducible builds. We expect to see some improvements over the next several months though as it appears to be a hot point for the community.

        Moving up from just Golang, another issue has been in isolating issues across the stack. We’re using Docker pretty heavily. A primary use is for containing the various language environments that IronWorker support, which allows us the capability to support multiple language versions within a low-latency job processing environment. We’ve also been Dockerizing other areas of our deployment stack. Using containers makes deployments a lot easier but it also brings challenges when it comes to isolating problems or bugs.

        Go provides a great debugging framework but when issues arise we’re not always sure whether it’s with the OS, Docker, or the application itself. No show stoppers but just a lot of extra cycles of trying different versions of each component to nail down the source. Improved Docker debugging would go a long way here.

        FWIW, here are the posts on our use of Docker. We’re definitely on the farther range when it comes to heavy use of it. (Primarily because of the ephemeral nature of a worker system.)

        Happy to get provide more information if you’d like.

        • Awesome, thanks for sharing your experience Ken!

          I think you brought up a really good point about being able to hire great developers, I’m sure no matter what language a company decides to go with, that’s a huge determining factor on how efficient they can be.

          It’s also cool to hear about your massive amount of Docker deployments, that’s something we’ve noticed as well talking to various companies relating to the web hosting field. There is a very large push to start leveraging new technologies like Docker to ease the process of supporting multiple environments and not worry so much about the underlying infrastructure constraints.

          Thanks again for the update, I’m sure others that are thinking about making the switch to Go could find your use case of it helpful to determine if it’s right for their needs.

  • Sven Slootweg

    You’re missing the data point of error handling – while the error handling in Node.js can be inconsistent, the error handling in Golang is just consistently wrong. It requires you to do explicit error checking (C-style, which is known to lead to many, many problems) and apparently does not offer any kind of throw/catch-like mechanism.

    This alone is enough reason for me to never ever use Golang, and stick with Node.js – making the right thing hard to do (like Golang does) is practically guaranteed to lead to unreliable software.

    • frankel0

      I think that is a good point. Though I also believe that there are some advantages to Golang that are hard to ignore. Go routines are extremely useful and are simple to implement. In Node.js I find that even for simple scripts you end up with callback-soup, using an async library, and using Cluster just for simple parallel processing.

      We will update the article to cover error handling though because you point is an important one.

    • Daniel Souza

      You can kinda throw/catch using Panic and catching the panics, but I personally believe explicit error handling is better, so to each his own. I’d rather treat errors locally when they happen than bubble them up… it does get verbose though, but I generally believe that explicit is better than implicit.

      • Sven Slootweg

        That’s 1) completely missing the point and 2) dangerous.

        You shouldn’t “treat errors locally when they happen”, you should handle errors where it is *appropriate* to handle them (which is often not the same level at which they are thrown). If errors do not bubble up, you just end up having to manually bubble it up and forgetting it at some point.

        You’re not advocating “explicit error handling”; you’re advocating “explicit error bubbling”. The former is good practice, the latter is downright dangerous.

        • Daniel Souza

          If you’re always dealing with errors explicitly (and in Go that often involves bubbling up errors explicitly by returning an ‘error’ upwards), then you won’t “forget it at some point” unless you explicitly forget/ignore errors (by assigning them to _ ), which you shouldn’t be doing, since everything can fail at any given time. Unless your idea of “forgetting an error” is not having your program crash terribly because of an Exception that was not handled, which is possible to happen in Go if you ignore the ‘err’ of some action. After a while, checking for errors in Go becomes a muscle reflex and forces you to think a lot more about errors and how to deal with them IMO.

          Of course this doesn’t make it any better than using Exceptions, it’s just different and yes, more verbose. There are packages too that make error handling in Go smoother (and include more annotations and stack trace information) that make error handling more sane. With that said, yes, error handling in Go is one of the few things that make me cringe in the language, but it’s not the end of the world (if you think of it as “C error handling but slightly better”).

          • robertjpayne

            Go lang seems to share the mentality of iOS Objective-C/Swift which is that errors are recoverable and exceptions are not.

            I agree with you that explicit handling is best otherwise corners are cut and errors are just left dangling.

            I see far too many catch all handlers for exceptions in all sorts of programming languages without any care as to what state the process may left in by not properly deciphering the severity of the error and managing it or actually letting your process crash.

            node.js also has no convention of when to use exceptions or errors or how to properly bubble up errors ( outside of EventEmitter ). There’s some community guidelines but good luck and have fun debugging any framework or library you use that decides to stray away from the norm.

    • Mau Lazyhola

      Could you please elaborate on how does that make you “lead to unreliable software”?

  • robmuh

    Personally after 25 years of watching technologies come and go Node and its community have all the indicators of a failed hype language like Rails has had. So many real computer scientists and don’t-care-about-show programmers who have been afraid of being forced into node on the back end are seeing the emergence of a language that has been very carefully crafted by geniuses who know the needs of emerging applications particularly on the back end. Good programmers cloistered behind enterprise walls in particular will find interest in Go. Python programmers are moving to Go. Node programmers are moving to Go. Perl programmers are moving to Go. C/C++ programmers are moving to go. The arguably mythical creator of the Node.js Express in MEAN stack (TJ) moved to Go (and it turns out he wasn’t joking). Rather than avoid the issue of concurrency by forcing everything to be async Go allows for it while fully leveraging all scalability modern multi-core machines offer. Go was written for this server-centric focus in mind rather than cramming a front-end, ancient yet modernized language onto the server. My personal favorite part of moving to Go — especially for web services supposedly in the Node sweet spot — is being free from the horribly poorly designed NPM package manager and the we-dont-give-a-shit, lets-play-guitars-laugh-out-loud-and-stroke-our-chin-beards-to-look-smarter Node community as a whole.

    • frankel0

      I would be interested to hear what about NPM that you find to be “horrible”.

      Also, I’d love to hear what your Go web-application stack looks like and if you use any framework/MVC/whatever as your baseline. Personally, for web-based applications I find Express/Node to be wonderful, even when the background processes are in other languages such as Go. I’ve played around with the Go (http?) web packages some but found them to be a bit under-developed. While Go is certainly better for high-performance, largely parallel workloads I still see a place for Node.

      • robmuh

        For starters NPM creates dozens, perhaps even hundreds of copies of the identical modules (lodash, etc.) because its flawed base architecture assumes you have to bundle them all for every dependency to match version requirements. This, in turn, blows out the path length maximums on Windows, but is bad enough it its own right.

        Go’s go get and static linking make it wonderful to work with in comparison not to mention its compatibility with the huge volume of C libraries already available.

        • gorgikosev

          This will no longer be true as of npm 3.0.

          As for how wonderful Go dependency management is, tell that to the creators of this game: who had their project fail thanks to Go’s “wonderful” dependency management

          • KimLetkeman

            Just stumbled on this thread and have to take issue with this comment. The project failed because they seemed not to understand that using a package that was live on github meant that they either fork it permanently and rename it, or they stay in sync. Option 3 is to ignore its evolution and then slam into it much later on, which led them to fail. They chose option 3. Not github’s fault and not Go’s fault.

          • James McGill

            That is a story of stupendously bad project management and misunderstanding of vendoring and version control. I understand how they got into that predicament and I sympathize, but the same mistakes could have been made using npm, mvn, sbt, nuget, gradle, you name it. Golang didn’t do that to them, even if the build system did effectively shield them somewhat from needing to understand dep locations. Godeps or glide would have forced them to be more specific and deliberate as to repo location and version, and CI milestone builds should have preserved the environment for a repeatable builds at every major juncture. Very rude to lay a project management mistake at the feet of the tool chain.

          • Craig Weber

            First of all let me say that the guy you responded to is definitely rude, trolling, and generally overexaggerating the positives of Go and the negatives of Node. That said, Go was not the reason that game failed; those developers weren’t following the idioms and best practices, and Go is very fast and easy to profile. It sounds like they had an engineering problem.

        • npm dedupe

        • Pep

          The problem is not in npm, it’s in Windows, which following your hostile patterns to describe things that you hate, you should call it the very real crap, not npm. You can’t simply say that npm is crap just beacuse doesn’t work in Windows in particular scenarios.

          Saying npm is crap is a bit hipocrit, IMHO. Just take a look to the huge community it has been created thanks to npm. It’s currently the large packages ecosystem created, and solves most of the problems like other package managers don’t do, such as reproducilibity, proper dependency hell management based on semver standards and so on…

          • timoun

            your arguments are quite bad, but i think it’s cause you only know nodejs ecosystem….
            Have a huge community which create package doesn’t mean that it’s a great package manager, they have no choice but they are also certainly like you, they only know how nodejs.

            Do you know that java solve this issues already in a better way, ruby did it with gem, python did it with pip, even php did it with composer ! (BTW they are all using semantical versionning so your semver point is not valid at all)

            He was talking about windows cause he certainly works on windows but on Linux or Unix system it’s all the same, I hit a lot of time inode maximum lenght cause of this poor package manager. NPM is the most horrible package manager i’ve ever seen !! This is non-intelligent package manager, all it does it’s just copy from vcs source in node_modules and make so much folder with the same package in your dependencies.

            Again, about it uses semver standards it makes me “laugh”. Hey guys, nodejs came from version 0.12.12 to v4.4.0, if you knew about semver you will know that 0.x.y mean that you’re in beta (and also that your api change a lot) so how can node come from beta to release 4 ?
            Even, node core developpers didn’t follow semantical versionning.
            And module developpers, well they are a lot with 0.x.y version …

            It tends to prove how is the nodejs community, it’s an immature community with no programmer background. It doesn’t really matter for me in fact, but nodejs developpers don’t should give lessons…
            Oh btw, cause i had to integrate and work with nodejs, it’s the best place to see bad codes, they have jsonlint and they don’t even use it.
            So much, if-else-for-while imbricated, bad code organization. They do test ok, but they don’t know how to test…

            So yes, nodejs will die if its community don’t grow up, if developpers become more professional it could be something. But like actually go cover all aspect of nodejs and have a great community I will stay on it.

    • Andres Manz

      Good comment. Well, I still prefer C++ over everything else. And I don’t think that, to me, any other language could ever replace it. Java couldn’t (although I like it), C# couldn’t (same here) and JavaScript couldn’t (I won’t say anything about that nightmare).

      But today I finally got to look into Go. And I think it is a very nice language. I’ll be honest here: If Go *should* become the most popular language for server-side web development (which would be a good thing!), I’d be a little bit confused. Because C and C++ are everything but popular when it comes to web development, and yet I see many – quite important – similarities between C/C++ and Go.

      There are a few things I don’t like about Go. The upper case, lower case stuff, for example. If I had to pick one of the newer languages as a replacement for C++ though, it would certainly be Go. I think it has (almost) everything a good, modern language needs. Still, from what I’ve seen until now, I am not sure if that language really is necessary, because it might be *too* similar to existing languages. I’m very excited to see the future of Go.

      • robmuh

        Go is a phenomenally great language for microservices (which is the first thing we used it for). Not all server-side web development falls under that category. It is absolute bliss when you can use the same code libraries to create c-speed command-line tools that also serve up your REST or other web APIs. Only a very specific type of engineer/developer appreciates this. Those I care about do.

      • NTN

        The only language that can compete with C in speed and has C++ features like operator overloading and generics I know is Rust. It is memory safe without garbage collection and has closures, pattern matching and algebraic data types.

        I have no idea if it is a good language, I’m not good enough in it. It has a lot of tedious things. Initializing an immutable array is a pain in the ass. Making a complex data structure with pointers is nearly impossible. ( Although, usually you want to implement these with arrays anyways.)

        These problems can be solved by using unsafe features, but then the safeness guarantee goes away, so you need to be a little careful instead of just thowing code at the compiler.

        • Umm… Java 8 can easily compete with C in speed because of the Streams api – which leverages multi-cores by default (with no extra coding required by the developer).

    • James Dixon

      Normally, I wouldn’t reply to a comment like this, but after reading your Disqus comment history, I couldn’t help myself. In this thread, you’re crapping all over Node and its community, yet you’ve posted many comments over the past year that praise Node and how it’s better than RoR, PHP, etc. What’s the deal? In general, it just seems like the vast majority of your comments are shitting on something, whether it be Node, RoR, or some guy trying to post an informative article on Sublime 3. Maybe it’s best to keep those types of comments to yourself unless you have something constructive to say? Stay douchey.

      • robmuh

        I LOVE node v.s. *anything* in RoR or PHP (*shiver*) mostly because I have direct professional experience being burned by their flaws. I used to be pro Ruby as well (v.s. the memory-leaking PHP crap for example).

        My “douchey”-ness is mostly calling out discoveries and warnings for those interested to do the work and their own research. As much research as I do before investing mindshare in a technology I place high value on those that are not afraid to call out the bad. The rest of it is personal experience with individuals for whom I have zero respect based on reading their comments and their responses to bugs when pointed out that they choose to ignore. The Node community is full of these individuals. The Go community is not.

        By the way, have you ever heard Linus Torvalds or Steve Jobs comment about technology (or people) they disagrees with? My comments are downright tame in comparison. In fact, I take your comment as a compliment. Stay bozo.

        • emojisequence

          As a semi-newb coming from the front-end/php world, with some experience with Node/Clojure, would you pick Clojure Go or Node for an eCommerce project? Thanks

        • oxygens

          PHP leaking memory? How is that an issue? WTF? The whole point of PHP is short lived *processes*.

          You are obviously trolling. Go troll somewhere else.

          • Did you seriously just say PHP leaking memory is a non-issue because it is a ‘short lived process’? *sigh* Let me know when you eventually delete that comment to not block your employment prospects. But thanks for helping me be sure to never hire or recommend you to ANYONE, lol.

          • Seer

            I think you may be seriously overestimating how much a Disqus comment might affect someone’s employability. PHP is a means to an end, much like any of the other tools we use to build products – sometimes the decision to use PHP is the right one based on people’s experience, or the needs of a client. There are also plenty of websites out there that work just fine with PHP – perhaps it’s not the “best” choice, but it does the job.

      • Richard Ellicott

        not fair, we are allowed to “shit on things” especially if they make more work

      • Totally agree. He is just a bitter person, likes to argue, and does not validate his opinion. Node, Ruby, and PHP are extremely potent languages. The amount of success PHP has had, and continues having, cannot be denied.

      • Richard Eng

        People are allowed to change their minds when future experiences warrant it. Even TJ Holowaychuk, one of Node’s brightest contributors, changed his mind:

    • Richard Ellicott

      i just found go….. woah…. so like previously only python and C# have really got me excited

      i don’t think go will be standard for a long time, but taking the go tour is like being shown round the death star

      the only other thing i sorta hoped for was compiled C#

    • Wait, the creator of Node Express – TJ – moved to Go? Where did you get this fact from.

    • 2Buku4U

      Since your so awesome I’m surprised that you have not invented a better language than Go by now! Yada yada yada… In software development there will always be tradeoffs and there will always be things that do not go as planned that developers will rant about. Given the perfect solution there is always going to be some ego that likes to complain about it claiming they have a better idea. There is nothing you can do about the shortcomings of human beings. Heres the best advice for most any developer that may stumble upon this rant. Use what ever language and tools that makes you happy and enjoy what you do because life is short. Also use what ever language and tools that can provide you with opportunities and the livelihood you desire. If there are lots of Node.js jobs available in your area then learn and use Node. Last time I checked JavaScript is one of the most popular languages well above GoLang so therefore if having a job and making a living is important to you then regardless of what some egotistical douchebag tells you, learn JavaScript! Who give a rats a$$ if GoLang is faster than [insert language here]? if there are 1 Go job for every 10 JavaScript jobs which is the best choice for your livelihood? Thats a no brainer. Look at it this way, for every robmuh there are at least 50 more 25 year veterans saying JavaScript is the way to go. Last time I checked Go versus JavaScript, they both pay about the same. Lastly, if Node.js and NPM were so terrible then why do they kick Go’s arse in the jobs market place?

      • Deciding between Go & Node based on the number of available job postings makes sense if you are a new developer trying to pick a language. But if you are trying to decide which language to build new software in at your company then this isn’t really the right criterion to use.

  • LOL

    I love go, but it is not a next-gen language. The same about js.

    • Richard Ellicott

      what’s a “next gen” language?

      • LOL

        Obviously language that doesn’t stuck in 1960s language design idioms.
        The really shameful example is nullable pointers and all that nil pointer dereference crap. A bit more modern approach (80s or 90s in the face of ADT) and this would not be a problem.

        • Richard Ellicott

          i will be soon out of my usual learning so no point writing an essay for me. But i did read about that and it’s along the lines of the type system, so some things can be of a different type they then don’t ==

          I think you might be being a bit harsh, Go is a serious upgrade on C++ in my personal opinion

          It needs to be “stuck in 60s design idioms” frankly doesn’t it because it is trying to be absolutely as good as C or C++

          So what you want is sort of more abstraction, I can deal with it I think

          However when they designed the language they said “it is now done” they had to do that… it’s now in a strong position to be a working language

          I think in the future I will dream of some Hybrid Language that is even easier to write and even more wasteful of memory but maintains maximum speed

          So i think you’re being harsh 🙂 Further none of us will get to use it anyway LOL, we’ll have to use C++ 🙁

          edit: all my opinion anyway, i imagine you are right

          • LOL

            ADT is a zero cost abstraction. For instance, pointer Pointer = Ref | None should have no memory overhead in comparison to C’s pointers: NULL (nil) refers to None, others are valid references.
            It is shameful to see new languages without ADT support.

            PS you may already noticed ugly solutions frequently becomes popular: C, C++, Java with its pseudo-crossplatform support, ugly javascript, horrible mess called node.js, unintuitive mess called Unix, etc.

          • Richard Ellicott

            zero cost?!

            not even the extra memory footprint or anything? Not even the size of the exe? 2.3 MB these hello world weigh in at, i try the same with g++ it is 15KB

            I agree with you if the exe is only slightly bigger but the memory requirement and speed are moreless the same?

          • LOL

            > zero cost?!


            > not even the extra memory footprint or anything?

            Yes, for safe pointer wrapper there’s no need in additional variables other than raw pointer itself. It is a pure compiler trick exploiting the fact pointer is nil if its value is 0. Thus it can translate raw pointer into safe wrapper and back unambigously.

            > Not even the size of the exe? 2.3 MB these hello world weigh in at

            Apples vs oranges comparsion that is: static vs dynamic linking, runtime size (for instance, go runtime includes garbage collector, goroutine scheduler, wider standard tools, like strings that are not a pain to use and more), etc.

          • Richard Ellicott

            well i feel i should announce the jury is still out for me on golang

            how about this for a “60s design idiom”

            hypot := func(x, y float64) float64 {
            return math.Sqrt(x*x + y*y)

            functions are values to, none of the inconsistent syntax of these things in C#!!

            are you sure this language is stuck in the past, i feel the null null issue was covered and explained (perhaps beyond me) on the faq, it looks like they have intelligent well thought out reasons (it was the type system)

            I think this language is targeted at C programmers sure but I flirted with some other languages and I want to come back to golang again

          • LOL

            > functions are values to

            Idea from 1958, LISP

            > i feel the null null issue was covered and explained

            nil pointer dereference definitely was less an issue compared to my short experience in Java (Android), but it still is. I believe though it is rather the contribution of built in asychronous primitives support than a language: Android program is a callback mess, both Go apps were servers with clean synchronous style code.

          • Richard Ellicott

            okay it’s just i am vaguely for no explicable reason convinced i like the idea of function pointers and stuff, despite the fact i have never found them useful and just well thought it was nice the syntax was so logical

            (ignore me there)

            …then the actual “nil pointer dereference”

            i guess i have never found it a practical issue this, i have yet to understand how it will be a problem for me?

            But I am convinced you’re right, clearly you are pointing out a correct logic and saying it doesn’t even cost anything.

            I just need to read more/ play more to find out why this is annoying 🙂

        • Richard Eng

          I see no need for a “next gen” language. No language will ever be perfect. Existing languages are fine, even with their faults. In the IT industry, it’s all about how useful a language is. In general, if a language is useful, it will always be useful. And that’s the only thing that counts.

          it’s hard to find fault even with “ancient” languages such as Lisp and Smalltalk. Smalltalk is damn near the perfect language, and it’s my favourite. I like Fortran, too.

          C was the principal language in my 20+ year career, and it’s still enormously useful today. I seriously doubt that something like Rust (a “next gen” language!) can supplant it.

          I’m not saying we shouldn’t try to advance language development. But we shouldn’t dismiss older languages just because they aren’t bleeding-edge, er, leading-edge. Someday, we may come up with a revolutionary language that completely transforms the software industry. Maybe. Someday.

          But I don’t expect to see it before I kick the bucket.

  • Camilo Azula

    I love NodeJS I have used java, spring, php, delphi, CGI, RoR just mention the technology, but it’s the first time the team can swap between server-side and client easily. I think that to develop the full stack in the same language is amazing (including DB thanks to mongodb)! you can always use that JS developer who is free 🙂 A lot of complains are risen out of the so called “callbacks hell”, well if you are not satisfied using promises to solve it, go go go reactive with RXJS this will get rid of that complain. Why to try to replace NodeJS? Is there in Go any amazing framework comparable to express? I also like very much libraries like I think I will give more time to the NodeJS team to solve some of the listed problems here but I wont move to a multi-lingual stack again …. NO WAY TO GO 🙂

    • Mau Lazyhola

      The thing with NodeJs (and I do like for certain tasks a lot to code in node) is that you get used too much working with frameworks. It is rare to se a javascript developer coding its own express version.

      In go there is really no need to do that, because the language itself was thought to handle pretty much everything you need without using any framework. Of course, there are (not as many because the language is younger and the community is smaller than node) frameworks, but more experienced developers usually write its own stuff in go.

      • Camilo Azula

        Mau big corporates are using more mature languages such java rather than go (specially for legacy) but what is nice about nodejs is to keep the full stack in javascript , read my comment 🙂

        • Mau Lazyhola

          Hi Camilo, that’s for sure because those big corporates have already a huge stable codebase, that works fast and is reliable.
          On the other hand, node (opposite from Go) is dynamic. Not to mention the callback hell which you can workaround. For me the biggest issue with dynamic languages is that you need to write a lot of unit testing for things that the compiler already does for you.
          I have coded in NodeJs since 2012 and as much as I like it I find more confident writting Go api’s.
          When you wrote “full stack” you ment client/server? How can that be an advantage other that sharing the same language? Unless you use something like meteorjs chances are you will not reuse anything at all. Cheers.

          • Camilo Azula

            Callback hell = solution reactive programming 🙂 fullstack: you can swap programers from front-end and back-end + programers will understand more what the other area is doing. I have been working for 20 years in java and javascript for me nodejs has been amazing 🙂 I wont go back to java. But in the end is up to you. I remember years ago same was going with RoR and other upcoming technologies. But I find amazing that I can code everything in the same language EoE. And to be honest I dont know whats your problem with frameworks when I worked in Java I used for example spring and it’s great. I use node with Rxjs + express and it’s great too. I love frameworks specially when they are performance oriented like RXJS vs Bacon 🙂

          • Camilo Azula

            And BTW I’m not saying anything bad about go 🙂

          • Mau Lazyhola

            Hey, me neither about Java or Node :D. I have respect for all technologies, and at the end you choose what suits better for fixing the problem.

            About the fullstack thing I am not buying it. I understand FE programming but I totally suck doing it, probably the same thing happens the other way around.

            Anyway nice to see different opinions on this subject.

          • Camilo Azula
    • Richard Eng

      The key reason that JS is shared between client and server side is because of the (perceived) need to duplicate rendering functionality on both sides. As a veteran software engineer, I find this to be an abhorrent abuse of software engineering. It’s only because of the web’s quirkiness that it’s even necessary. And I’m not sure it’s actually necessary. I believe there’s a way to design your system so that you can avoid this duplication.

      In general, there is (and should be) no need to use the same language for both client and server side. Client/server architecture has been around for decades, and they’ve always used multiple languages. Most developers are polyglot and have no difficulty switching between languages.

      • Dave Richer

        you lost me when you qualified yourself a ‘veteran software engineer’

  • David Mumladze

    Go and NodeJS are both good (I prefer Go) and useful, but they are mostly server languages… None of them fit into being a primary language like Java, C++ or C#. Not much gain in trashing either of the two. Instead, you should know both and use them appropriately… Ohh, and out the entire article, the most useful are final two paragraphs.

  • Leslie Cecile Brown

    Thanks for this article, I understood some parts but not everything, does anybody know of a good executive overview? I am just starting to get into programming so the code parts confused me a bit 🙂

  • Shien The Kid

    Go is the ugliest language I have ever seen. It had so much potential – it was starting afresh in a new age, a huge company backing it, a strong guiding principle of pragmatism, and a huge target market who were disgruntled by Node.

    Needless to say, it didn’t deliver. It doesn’t even have generics, its type inference was shit, and for a language which revolves around concurrency, coroutines are nowhere near as nice to use as async/await would’ve been, and yes, async/await is really nice in C#. Its error handling is in an even worse situation than Rust, despite having language level support, and it has no sum types, which are incredibly useful in just about any project ever.

    Also, Rob Pike himself said on one occasion that Go is for ‘the mediocre developer’ and while this is obviously not true considering the amazing things people have built in Go, it is concerning when the intentions of a language are to be ‘mediocre’.

    • Richard Eng

      That’s not exactly what Rob Pike meant. In most software development teams, there are junior or less experienced developers who would do better with a nice, simple, easy language (like Go), rather than a complex, difficult-to-use language (like C++). The simpler and easier, the better.

      Even for experienced developers (including myself with over 20 years), they appreciate a language that is easier to use and presents a lower cognitive load. I see no reason to use a more complex language when a simpler language can do everything I want to do.

      Complex languages are no more “powerful” than simple languages. I highly favour Smalltalk and Go, both of which are enormously powerful. For all its simplicity, Smalltalk is one of the most expressive programming languages on the planet.

      Beauty is in the eye of the beholder, and I see nothing ugly about Go. Its goroutine feature is fantastic. I find doing concurrent programming with Go to be a breeze.

      Generics is one of the most overrated features in the world. In all my 20 years in IT, having worked for a dozen companies and in dozens of software projects in many different problem domains, I’ve never used generics and I’ve never missed it.

      For the record, I’ve programmed in Fortran, assembly language, Tandem TAL, C, C++, C#, Objective-C, Java, Smalltalk, Python, and Go.

      By the way, Go is now a Top 10 language!

      • Shien The Kid

        I get what you mean (I think) and yes, everyone loves smalltalk, but honestly, compared to objective c, c#, and Java, literally anything seems simpler. And in my opinion, concurrent programming in c# is much nicer than in go.

        On another note, how do you propose we create statically type checked collections without generics? They seem to be used literally everywhere, and Go’s solution of hard coding some types, like map, is a bit lackluster, and inflexible.

  • I still don’t get it. Suppose I am a newbie who wants to write APIs, what technology should I choose – Go or Node? Your article is thorough in analyzing these two technologies, but it doesn’t help me decide. For example, I know that Go can achieve C/C++ equivalent speeds close to the CPU. However, it is almost cumbersome to quantify and compare to what Node.js does in this regard…

  • I’ll just admit that Node.js is much easier and fun to develop in but when you get into tough spots, you want the heavy lifters to step in and solve it in Go. Go is just more difficult to master and you’ll have a much harder time finding people to code for you but when you do, you’ll surely find the right types that have the chops to cover you in a bind. I would recommend using Node.js for web servers and micro services that are lighter weight and then use Go for core critical uptime and performance tasks. You’re not going to find your average hipsters jumping into Go because its fun, in other words and it has the nice side effect of attracting the stronger coders.

  • emrah

    Javascript is not next generation. We are stuck with it.

  • Edwin Quai Hoi

    Didn’ know that NodeJS was considered a language… :p

  • When was this actually written? Could not have been November 3, 2016 with something like “and its recent fork, IO.js”, (which happened September 14, 2015). I could not read anything past that.