Mark Bates

Mark Bates is a full stack web developer with over 18 years of experience building high quality scalable applications for companies such as Apple, USA Today, Klarna, and Palm. He has written three books, “Distributed Programming with Ruby”, “Programming in CoffeeScript”, and “Conquering the Command Line”. Mark has spoken at conferences around the world, has led user groups such as Boston Ruby and Boston Golang, and has helped to organize conferences such as GothamGo and GopherCon.

Mark is the co-founder of PaperCall.io, a platform for connecting technical events with high quality content and speakers. Mark is also a partner at Gopher Guides, the industry leader for Go training and conferences.

Website

http://www.markbates.net

Sessions

(Re)Writing Rails in Go

I spent 12 years writing Ruby on Rails applications. I wrote a lot of them. I was great at it. I could knock an application out in a weekend.

A few years back I found Go. I feel in love. I won't bore you with the details of why, they're un-important. What is important is I wanted to build web apps in Go, but I couldn't. It was painful. I struggled. I tried every "framework", every 3rd party package I could find, but none of them brought me the developer speed I had with Rails. I cried. I drank. I cried and drank.

Finally, I thought, why not take all of the experience I've had with Rails and all the of the experience I've had with all the Go frameworks and packages I've played with and try to smoosh it all together and see what happens. Enter Buffalo.

This talk isn't about trying to convert anyone to using Buffalo over Rails, or Go over Ruby. Instead it's a look at the challenges, the ups and downs, the high and lows, of trying to re-build a framework that is known for it's harrowing use of dynamic meta-programming in a language that knows not of those things.

I'll discuss rebuilding Rake as Grift. Look at the challenges of trying to build an ActiveRecord like system (including migrations) with Pop, and much more.

This talk will hopefully provide light on why you should never want to build your own web framework, and why you should shower those who do with lots of pretty, shiny trinkets.