Introduction to Go

532 views
404 views

Published on

Slides from a talk I gave at CodeFellows in January 2014

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
532
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Introduction to Go

  1. 1. ! An Introduction to Go given January 30, 2014 at CodeFellows Zack Hubert
  2. 2. Hi, I’m Zack
  3. 3. I work here…and…
  4. 4. I think Go is Awesome
  5. 5. I think you’ll like it too
  6. 6. My Story with Go
  7. 7. The Year was 2012 • It was a NEW PROJECT! • Make it Real Time • Use a Javascript MVC
  8. 8. Ruby on Rails Server side choice was easy…
  9. 9. What about the Client Side?
  10. 10. logos believed to be fair use
  11. 11. Batman.js Has been a great choice
  12. 12. What kind of product? Resource Scheduling
  13. 13. “For an event that occurs weekly from 7-9pm on Wednesdays, Fridays (except 3 weeks...) are five out of ten chairs available along with three tables to go in the Green room and make sure Bill approves?” –Our Customers
  14. 14. Rails Performance < 150ms? This could be a problem.
  15. 15. Solution MySQL Upserts Histogram the Schedule Heavily Precompute Values in Cache
  16. 16. It Worked!
  17. 17. The Good • 40ms • Rails+MySQL • No NoSQL • Same stack as other apps
  18. 18. The Bad • Millions of rows of computed values • Caching is error prone • Data model polluted with derivative classes
  19. 19. Free Week - 2012 • Looked at Go for an API • Didn’t understand it • Frustrated by many things • Compiler error on unused import…wha!?
  20. 20. Go is Opinionated frustration will ensue without knowing the opinions of the designers
  21. 21. Back to Resources • 1.5 years later…many users etc. • The app was getting slower (larger JSON responses) • Complexity was an increasing burden
  22. 22. Techempower JSON encoding benchmark http://www.techempower.com/benchmarks bottom is visible :(
  23. 23. Free Week - 2013 • Had been reading up in the intervening year • Watched every video I could • and then it made sense…
  24. 24. RUSH is Born • Resource Utilization Service Handler • Day 1 - Working Service • Day 2 - Accurate Service • Week 1 - Production Ready • Launched Post Holidays • Rock solid. • (word play on my favorite band)
  25. 25. RUSH Performance • 100x faster than the heavily cached Ruby option • 1,000x faster than Ruby without caching • 1% of the memory footprint
  26. 26. Go turns out to be the best at JSON …a perfect complement, huzzah :)
  27. 27. Why Learn Go?
  28. 28. Why Learn Go? • Crazy fast • Awesome complement to JS MVC • Great service carveout to help an interpreted language web framework like Ruby on Rails
  29. 29. FUN!
  30. 30. Overview • A brief history of Go • Language design decisions
  31. 31. What is Go? Go is a new, general-purpose programming language.
  32. 32. What is Go? • Compiled: compiler makes runnable binary • Statically typed: compiler checks for a category of mistakes • Concurrent: easy composition of processes, (may be simultaneously executed) • Garbage Collected: runtime release of no longer used memory • Simple: as classically defined :)
  33. 33. The Story of Go
  34. 34. Rob Pike Bell Labs Unix team created Plan 9/Inferno os co-author with Kernighan (Unix Programming Environment) co-creator of UTF-8 (with Ken) image cc by-sa 3.0 chlor at en.wikipedia.org
  35. 35. Ken Thompson (seated) designed UNIX, B, Plan 9, Turing award image cc by-sa 2.0 at en.wikipedia.org
  36. 36. Robert Griesemer V8, Chubby for GFS, Java HotSpot VM, compiler for Cray Y-MP, interpreter for APL image cc by-sa 3.0 at en.wikipedia.org
  37. 37. The Creation Story long C++ build, 45 minutes, whiteboarded the language image still from Google I/O 2012
  38. 38. Open Sourced Nov, 2009 464 contributors as of January 26, 2014
  39. 39. Already Quite Popular (SO vs Github)
  40. 40. Problem #1: Development Speed
  41. 41. Development Speed • “It's a fast statically typed compiled language that feels like a dynamically typed interpreted language.” - golang.org
  42. 42. Fast is FUN
  43. 43. Fast has its Tradeoffs “Missing” language features - Generics, Inheritance, etc.
  44. 44. and its quirks managed imports for instance…but it makes sense from the creation
  45. 45. Problem #2: Make it Modern
  46. 46. Age of Languages?
  47. 47. C++ 1979
  48. 48. Python 1989
  49. 49. Java 1990
  50. 50. Ruby 1993
  51. 51. Go - 2007 (14 years after Ruby)
  52. 52. Modern Means Multicore
  53. 53. Multicore/Concurrency • Concurrency through CSPstyle processes called go routines • 1978 CSP by Sir Tony Hoare • M:N runtime mapping of green threads to system threads • “Do not communicate by sharing memory, instead share memory by communicating” - Pike image by Rama cc by-sa 2.0-fr at en.wikipedia.org
  54. 54. Concurrency is HUGE in Go
  55. 55. Modern Means Internet it’s kind of a big deal
  56. 56. The Internet Age • Go ships with a “batteries included” standard library • For instance, net/http • Instead of frameworks to pick up the slack, the std-lib has most of what you need
  57. 57. Problem #3: Complexity
  58. 58. Webscale. large programs, big teams.
  59. 59. Seriously though… • Designed to be C-like for early career programmers • Simplified syntax
  60. 60. 1 keyword for looping Simple
  61. 61. Garbage Collection Simple, easier with concurrency
  62. 62. 25 keywords total 50 in Java, 48 in C++, ~42 in Ruby
  63. 63. No Inheritance Composition is easier to get right, defers design decisions
  64. 64. CSP Concurrency Mutexes are hard to get right. Channels are easier.
  65. 65. So…when Go is confusing ask…
  66. 66. Is this because the language is YOUNG?
  67. 67. Is this because it’s SIMPLE?
  68. 68. Is this because it wants to be FAST?
  69. 69. Revised… Original talk proceeded to 1 hour Tour of Go and then “The Fun Part” (hands-on with Go, using D&D imagery)
  70. 70. Keep on Learnin’ • http://golang.org • http://gobyexample.org • http://gophercasts.io
  71. 71. Thank You! @zhubert, http://www.zhubert.com
  72. 72. Let’s Have Some Questions

×