The Go programming language has been around for a bit over a decade now and has been gradually growing in popularity. Here are some reasons why, and why you might find yourself wanting to write your next project in Go.
Joan and Jim are having a conversation about how to write Go code that deals with database tables:
Jim: Maybe we can have a Store and just make methods like CreateUser, DeleteUser, CreateWidget, etc on it, without worrying about a User or Widget struct. CreateUser can accept userName, password, etc. as parameters, and each of these methods just runs the appropriate SQL.
Joan: Hm, might work initially but what happens when you need to select a list of users?
I already know what you’re thinking: No, we don’t need another ORM written in Go.
Very true. Which is why I didn’t write one, promise.
Instead, I wrote tmeta (short for “table meta” or “type meta”, or something). It can parse struct tags to understand how your structs correspond to SQL tables, including common relations (one to many, many to many, etc.), and makes it easy to build corresponding queries:
While I’ve been a proponent of writing web software in Go for years, using “routers” (or “muxers” or “dispatchers”) is something I’ve been long disenchanted with and have actively avoided in my own code for some while. Not infrequently I mention this to someone and they look at me like I have something stuck in my teeth or really bad body odor. After briefly verifying those are not the case and ascertaining their consternation is due to my lack of a router, I then get to impart to them what I mean.
NOTE: This is an article I originally wrote for the TopTal Engineering Blog.
Understanding the Input/Output (I/O) model of your application can mean the difference between an application that deals with the load it is subjected to, and one that crumples in the face of real-world use cases. Perhaps while your application is small and does not serve high loads, it may matter far less. But as your application’s traffic load increases, working with the wrong I/O model can get you into a world of hurt.
I recently did some tests where I benchmarked some simple HTTP requests with servers implemented in PHP, Java, Node.js and Go:
Benchmarks were run in a CentOS 7.3 (Linux 3.10.0-514.el7.x86_64) virtual machine (Intel Core i7, 4 cores @ 2.2GHz, 1GB of RAM) running in VirtualBox on a Mac laptop. Timings were taken with ApacheBench (v.2.4.6).
PHP v5.4.16; Apache v2.4.6 Java (OpenJDK) 1.8.0_131-b11; Tomcat v7.0.69 (without APR/native) Node.js v6.10.3 Go v1.8.1 Please Note: There’s been plenty of discussion here about the version used for PHP, the Node.
My recent jaunt from Orange County up to the San Francisco Bay turned out to be a rather memorable experience. In spite of the fact that I missed much of the local charm in San Francisco city itself, I was able to get some great photos and do a bit of Silicon Valley tech sightseeing.
I’ve written this brief guide to help remind of the important things for future trips for me and thee.
So you’re building a web application and you need to push data from the server to the browser. The good news is that you have some options. The bad news is that you have some options. The question of which technology to use here does not necessarily have an immediate and obvious answer. (TL;DR)
After struggling with the choices for browser push available to me on several new projects, I did a comparison and came to the conclusion described here.
After a long overdue incubation period, I’m finally launching my official blog on Peabody.io.
My name is Brad Peabody and I’m a software engineer working in the Los Angeles/Orange County area. With 15+ years of experience writing code of many kinds, I’ve had the fortunate (or unfortunate depending on which side of the various programming language holy wars you reside on) opportunity to write copious amounts of Java, PHP, Python, Go, C, C++, JavaScript and an entirely unhealthy quantity of shell script.