What is Go?
Want advice about which of these to choose?Ask the StackShare community!
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.
Go has been a joy to work with. Performance is often 30x of what we used to see with Python. It's a performant and productive programming language: https://getstream.io/blog/switched-python-go/
- Most server-side scripts, all unit tests, all build tools, etc. were driven by NodeJS.
- ExpressJS served as the 'backend' server framework.
- MongoDB (which stores essential JSON) was the main database.
- MongooseJS was used as the main ORM for communicating with the database, with KnexJS used for certain edge cases.
- MochaJS, ChaiJS, and ExpectJS were used for unit testing.
- Frontend builds were done with Gulp and Webpack.
- Package management was done primarily with npm - with a few exceptions that required the use of Bower (also configured with JSON).
- The frontend was build primarily with ReactJS (as the View) and Redux (as the Controller / Store / frontend model).
- Configuration was done with json files.
The only notable exceptions were the use of SCSS (augmented by Compass) for styling, Bash for a few basic 'system chores' and CLI utilities required for development of the app (most notably git and heroku's CLI interface), and a bit of custom SQL for locations where the ORM extractions leaked (the app is DB-agnostic, but a bit of SQL was required to fill gaps in the ORMs when interfacing with Postgres).
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
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 are now re-considering TypeScript because 1) the tooling has improved significantly, and 2) and the root cause of the majority of our front-end bugs are related to typing (despite having PropTypes).
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!
To me, this is by far the best programming language. Why? Because it’s the only language that really got me going after trying to get into programming with Java for a while. Python is powerful, easy to learn, and gets you to unsderstand other languages more once you understand it. Did I state I love the python language? Well, I do..
Backend server for analysis of image samples from iPhone microscope lens. Chose this because of familiarity. The number one thing that I've learned at hackathons is that work exclusively with what you're 100% comfortable with. I use Python extensively at my day job at Wit.ai, so it was the obvious choice for the bulk of my coding.
been a pythoner for around 7 years, maybe longer. quite adept at it, and love using the higher constructs like decorators. was my goto scripting language until i fell in love with clojure. python's also the goto for most vfx studios and great for the machine learning. numpy and pyqt for the win.
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.