ES6 vs Go: What are the differences?
ES6 and Go can be categorized as "Languages" tools.
"ES6 code is shorter than traditional JS" is the primary reason why developers consider ES6 over the competitors, whereas "High-performance" was stated as the key factor in picking Go.
Go is an open source tool with 60.4K GitHub stars and 8.36K GitHub forks. Here's a link to Go's open source repository on GitHub.
Slack, StackShare, and ebay are some of the popular companies that use ES6, whereas Go is used by Uber Technologies, Google, and Medium. ES6 has a broader approval, being mentioned in 1461 company stacks & 1725 developers stacks; compared to Go, which is listed in 901 company stacks and 606 developer stacks.
What is ES6?
What is Go?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using ES6?
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.
I think next step could be to use Koa but I am not sure.
Following its migration from vanilla instances with autoscaling groups to Kubernetes, Postmates began facing challenges while “migrating workloads that needed to scale up very quickly.”
The built-in Horizontal Pod Autoscaler (HPA) automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization. But the challenges for Postmates is that there’s no way to configure the scale velocity of one particular cluster with an HPA.
For Postmates, which runs at least three different types of applications with distinct performance and scaling characteristics, this proved problematic.
To overcome these challenges, the team created and open sourced the Configurable Horizontal Pod Autoscaler, which allows for fine-grained tuning on a per-HPA object basis. The result is that “you can configure critical services to scale down very slowly, while every other service could be configured to scale down instantly to reduce costs.”
We are always building new features and replacing old code at StackShare. Lately we have been building out new features for the frontend, and removing a lot of old jQuery code (sorry jQuery but it's time to go).
As we've moved towards the above tech, its really made smashing out new features and updating legacy code super fast, and really fun!
Obviously, using ES6 and TypeScript is what makes it decent in browser contexts. Throw in a bit of React and now we're cooking with gas!
Go is a high performance language with simple syntax / semantics. Although it is not as expressive as some other languages, it's still a great language for backend development.
Python is expressive and battery-included, and pre-installed in most linux distros, making it a great language for scripting.
PostgreSQL: Rock-solid RDBMS with NoSQL support.
NATS: fast message queue and easy to deploy / maintain.
Docker makes deployment painless.
Git essential tool for collaboration and source management.
The power of SSR React and then hydrating it client-side to add interactivity and App-like feel is what makes Gatsby powerful.
It comes with a ton of plugins, that are mind-boggling: Image Processing, GraphQL, Node.js, and so much more. This is thanks to a great ecosystem, a great user-base and the revolutionary Community work, which led to the Gatsby repo to be one of the most committed to, out there.
We are phasing out jQuery and jQuery UI in favour or Vue.js and @Vue-cli so we can support building a modern, well-architectured frontend.
Our new backend micro services are primarily written in Node.js and Go and legacy systems are written in Java. For our new stack decision, we aimed to achieve greater developer productivity, low IO latency and good community so we had couple of technologies in hand to choose but finally we concluded to go for Node.js for API layer and Go for CPU/IO intensive tasks. Currently the inter-services communication is happening via REST but soon to be moved to RPC-based communication.
We have added very little to the CoffeeScript Hubot application – just enough to allow it to talk to our Hubot workers. The Hubot workers implement our operational management functionality and expose it to Hubot so we can get chat integration for free. We’ve also tailored the authentication and authorization code of Hubot to meet the needs of roles within our team.
For larger tasks, we’ve got an internal #CLI written in Go that talks to the same #API as Hubot, giving access to the same functionality we have in Slack, with the addition of scripting, piping, and all of our favorite #Unix tools. When the Hubot worker recognizes the CLI is in use, it logs the commands to Slack to maintain visibility of operational changes.
For markup and style, I used Pug and Sass, since they’re the perfect match to me. I love the clean and strict syntax of both of them and even more that their structure is almost similar. Also, both of them come with an expanded functionality such as mixins, loops and so on related to their “siblings” (HTML and CSS). Both of them require nesting and prevent untidy code, which can be a huge advantage when working in teams. I used JSON to store data (since the data quantity on my website is moderate) – JSON works also good in combo with Pug, using for loops, based on the JSON Objects for example.
To send my contact form I used PHP, since sending emails using PHP is still relatively convenient, simple and easy done.
DevOps: Of course, I used Git to do my version management (which I even do in smaller projects like my website just have an additional backup of my code). On top of that I used GitHub since it now supports private repository for free accounts (which I am using for my own). I use Babel to use ES6 functionality such as arrow functions and so on, and still don’t losing cross browser compatibility.
Side note: I used npm for package management. 🎉
For the backend of https://www.rsvpkeeper.com I went with Go.
My past few project have been built with Go and I'm really loving it. It was my first statically typed language after many years with PHP and Node.js - and honestly I couldn't be happier to have made the switch.
The biggest thing for me, is that with the forced declaration of types - it's made me feel like I've made a more solid backend. Sometimes with PHP I felt like a stiff breeze could knock the whole thing down. I know that's an exaggeration - but it's kinda how it feels.
Anyways, everyone knows that it almost doesn't even matter what an app is actually made with - what really matters are the design decisions you make a long the way.
At FlowStack we write most of our backend in Go. Go is a well thought out language, with all the right compromises for speedy development of speedy and robust software. It's tooling is part of what makes Go such a great language. Testing and benchmarking is built into the language, in a way that makes it easy to ensure correctness and high performance. In most cases you can get more performance out of Rust and C or C++, but getting everything right is more cumbersome.
The first time I actually started using Go was for software on our devices. So on our hotspots we have some custom software running in the firmware. For the first device, that was actually completely built by our manufacturer. But for the second generation most of the parts are built by us in-house and we needed a way to quickly develop software for the device. But we don't have any C programmers in-house, so we were actually looking for something that basically sits in between the friendliness of Ruby, but the performance and the ability to be deployed on an embedded system which you get with C. That's basically what led us to Go and it's been awesome for that. It works so well and so great. Since it works so great, it pushed us into looking into whether we should start using this for some backend services as well.
The following basic API endpoints are implemented on the server written in Go:
- Authorization (Sign Up, Sign In)
- Update user profile
- Community: add post, like post, add comment, delete post, add reply to comment
- Self-diagnosis: send data from the app to the server
- Journal: send user data from the app to the server
- Add groups of community
- Report post, report comment, report reply
- Block user
We wrote our own image processing, resizing, and snapshotting service in Go to allow our clients to send photos and GIFs to each other. Files are stored in S3, resized on the fly using OpenCV, and then cached in GroupCache before being served to clients.
Go allows it all to be quite fast and efficient, and entirely non-blocking on uploads!
We started using CoffeeScript years ago, so the switch to ES6 is quite natural in our team. ES6 of course advances the JS standard to a level of an advanced language. We are using it today simply because it: 1. helps to keep the code shorter, 2. integrates easily with JSX, 3. helps to deal with immutable using const.
Our main web scraping engine is built usign Golang because of the way how efficiently and fast this language is. Also out compilation facility let people who dont know Golang build fast as flash scrapers to run ourside of our platform without any knowledge in programming in Golang.
For some of our more taxing parts of our applications, something able to handle high I/O load quickly and with fast processing is needed. Go has completely filled that gap, allowing us to break down walls that would've been completely impossible with other languages.