github.com/graybobo/golang.org-package-offline-cache@v0.0.0-20200626051047-6608995c132f/x/talks/2010/go_talk-20100323.html (about) 1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 4 <head> 5 <title>Go Tech Talk</title> 6 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 7 <meta name="font-size-adjustment" content="-1" /> 8 <link rel="stylesheet" href="support/slidy.css" 9 type="text/css" media="screen, projection, print" /> 10 <script src="support/slidy.js" type="text/javascript"> 11 </script> 12 </head> 13 <body> 14 <!-- this defines the slide background --> 15 16 <div class="background"> 17 18 <div class="header"> 19 <!-- sized and colored via CSS --> 20 </div> 21 22 <div class="footer"></div> 23 </div> 24 25 <div class="slide titlepage"> 26 <br/> 27 <br/> 28 <img src="support/go-logo-white.png" width="588px" height="217px"> 29 <br/> 30 <h1 style="padding-right: 0pt; margin-right: 0pt; color: #0066cc; font-size: 250%; border-bottom: 0px;">The Go Programming Language</h1> 31 <div style="color: #ffcc00;"> 32 <br/> 33 <h3>Sydney University<br/><br/>March 23, 2010</h3> 34 </div> 35 </div> 36 37 <div class="slide"> 38 <h1>Go</h1> 39 40 <h2>New</h2> 41 <h2>Experimental</h2> 42 <h2>Concurrent</h2> 43 <h2>Garbage Collected</h2> 44 <h2>Systems Language</h2> 45 </div> 46 47 <div class="slide"> 48 <h1>Hello, world</h1> 49 <pre> 50 package main 51 52 import "fmt" 53 54 func main() { 55 fmt.Printf("Hello, 世界\n") 56 } 57 </pre> 58 </div> 59 60 <div class="slide"> 61 <h1>Hello, world 2.0</h1> 62 63 <h2>Serving <a href="http://localhost:8080/world">http://localhost:8080/world</a></h2> 64 <pre> 65 package main 66 67 import ( 68 "fmt" 69 "http" 70 ) 71 72 func handler(c *http.Conn, r *http.Request) { 73 fmt.Fprintf(c, "Hello, %s.", r.URL.Path[1:]) 74 } 75 76 func main() { 77 http.ListenAndServe(":8080", 78 http.HandlerFunc(handler)) 79 } 80 </pre> 81 </div> 82 83 <div class="slide"> 84 <h1>New</h1> 85 86 <h2>It's about two years old:</h2> 87 <ul> 88 <li>Design started in late 2007</li> 89 <li>Implementation starting to work mid-2008</li> 90 <li>Released as an open source project in November 2009</li> 91 <li>Development continues with an active community</li> 92 </ul> 93 94 <h2>Why invent a new language? Older languages weren't designed for concurrency, but modern software needs it:</h2> 95 <ul> 96 <li>Large scale, networked computing, such as Google web search</li> 97 <li>Multi-core hardware</li> 98 </ul> 99 </div> 100 101 <div class="slide"> 102 <h1>New</h1> 103 104 <h2>Older languages are also frustrating on a day-to-day basis</h2> 105 <h2>Statically-typed languages (C, C++, Java) have issues:</h2> 106 <ul> 107 <li>Edit-Compile-Run cycle takes far too long</li> 108 <li>Type hierarchy can hurt as much as it helps</li> 109 </ul> 110 <div style="text-align:center"> 111 <img src="support/java-typing.png" width="800px" height="90px"><br> 112 </div> 113 114 <h2>Dynamic languages (Python, JavaScript) fix some issues but introduce others:</h2> 115 <ul> 116 <li>No compilation means slow code</li> 117 <li>Runtime errors that should be caught statically</li> 118 </ul> 119 120 <h2>Go has the lighter feel of a scripting language but is compiled</h2> 121 </div> 122 123 <div class="slide"> 124 <h1>New</h1> 125 126 <h2>Large C++ programs (e.g. Firefox, OpenOffice, Chromium) have enormous build times:</h2> 127 <ul> 128 <li>XKCD's #1 Programmer Excuse for Legitimately Slacking Off: "<a href="http://xkcd.com/303/">My Code's Compiling</a>"</li> 129 </ul> 130 131 <h2>On a Mac (OS X 10.5.8, gcc 4.0.1):</h2> 132 <ul> 133 <li>C: <code>#include <stdio.h></code> reads 360 lines from 9 files</li> 134 <li>C++: <code>#include <iostream></code> reads 25,326 lines from 131 files</li> 135 <li>Objective-C: <code>#include <Carbon/Carbon.h></code> reads 124,730 lines from 689 files</li> 136 <li>We haven't done any real work yet!</li> 137 </ul> 138 139 <h2>In Go: <code>import "fmt"</code> reads <i>one</i> file: 184 lines summarizing 7 packages</h2> 140 </div> 141 142 <div class="slide"> 143 <h1>New</h1> 144 145 <h2>Compilation demo</h2> 146 </div> 147 148 <div class="slide"> 149 <h1>Experimental</h1> 150 151 <h2>Go is still unproven</h2> 152 <h2>Language is still evolving</h2> 153 <h2>Package library is incomplete</h2> 154 <h2>Concurrent garbage collection is an active research problem</h2> 155 <h2>Reviving forgotten concepts:</h2> 156 <ul> 157 <li>Go's concurrency is strongly influenced by <i>Communicating Sequential Processes</i> (Hoare, 1978)</li> 158 <li>Go has types and interfaces, but no inheritance. It is arguably more object-oriented than previously mentioned languages, being closer to the original Smalltalk meaning (1970s)</li> 159 </ul> 160 </div> 161 162 <div class="slide"> 163 <h1>Concurrent</h1> 164 165 <h2>Unix philosophy: write <i>programs</i> that do one thing and do it well</h2> 166 <h2>Connect them with <i>pipes</i>:</h2> 167 <ul> 168 <li>How many lines of test code are there in the Go standard library?</li> 169 <li><code>find ~/go/src/pkg | grep _test.go$ | xargs wc -l</code></li> 170 </ul> 171 172 <h2>Unlike other languages, Go makes it easy to:</h2> 173 <ul> 174 <li>Launch <i>goroutines</i></li> 175 <li>Connect them with <i>channels</i></li> 176 </ul> 177 </div> 178 179 <div class="slide"> 180 <h1>Concurrent</h1> 181 182 <h2>Start a new flow of control with the <code>go</code> keyword</h2> 183 <h2>Parallel computation is easy:</h2> 184 <pre> 185 func main() { 186 go expensiveComputation(x, y, z) 187 anotherExpensiveComputation(a, b, c) 188 } 189 </pre> 190 191 <h2>Roughly speaking, a goroutine is like a thread, but lighter weight:</h2> 192 <ul> 193 <li>Goroutines have segmented stacks, and typically smaller stacks</li> 194 <li>This requires compiler support. Goroutines can't just be a C++ library on top of a thread library</li> 195 </ul> 196 </div> 197 198 <div class="slide"> 199 <h1>Concurrent</h1> 200 201 <h2>Consider web servers ("the C10k problem"):</h2> 202 <ul> 203 <li>"Thread per connection" approach is conceptually neat, but doesn't scale well in practice</li> 204 <li>What does scale well (event-driven callbacks, asynchronous APIs) are harder to understand, maintain, and debug</li> 205 <li>We think "goroutine per connection" can scale well, and is conceptually neat</li> 206 </ul> 207 <pre> 208 for { 209 rw := socket.Accept() 210 conn := newConn(rw, handler) 211 go conn.serve() 212 } 213 </pre> 214 </div> 215 216 <div class="slide"> 217 <h1>Concurrent</h1> 218 219 <h2>Let's look again at our simple parallel computation:</h2> 220 <pre> 221 func main() { 222 go expensiveComputation(x, y, z) 223 anotherExpensiveComputation(a, b, c) 224 } 225 </pre> 226 227 <h2>This story is incomplete:</h2> 228 <ul> 229 <li>How do we know when the two computations are done?</li> 230 <li>What are their values?</li> 231 </ul> 232 </div> 233 234 <div class="slide"> 235 <h1>Concurrent</h1> 236 237 <h2>Goroutines communicate with other goroutines via channels</h2> 238 <pre> 239 func computeAndSend(ch chan int, x, y, z int) { 240 ch <- expensiveComputation(x, y, z) 241 } 242 243 func main() { 244 ch := make(chan int) 245 go computeAndSend(ch, x, y, z) 246 v2 := anotherExpensiveComputation(a, b, c) 247 v1 := <-ch 248 fmt.Println(v1, v2) 249 } 250 </pre> 251 252 </div> 253 254 <div class="slide"> 255 <h1>Concurrent</h1> 256 257 <h2>In traditional concurrent programs, you <i>communicate by sharing memory</i>. In Go, you <i>share memory by communicating</i>:</h2> 258 <ul> 259 <li>Communication (the <code><-</code> operator) is sharing and synchronization</li> 260 </ul> 261 262 <h2>Threads and locks are concurrency primitives; CSP is a concurrency model:</h2> 263 <ul> 264 <li>Analogy: "Go To Statement Considered Harmful" (Dijsktra, 1968)</li> 265 <li><code>goto</code> is a control flow primitive; structured programming (<code>if</code> statements, <code>for</code> loops, function calls) is a control flow model</li> 266 </ul> 267 268 <h2>Learning CSP changes the way you think about concurrent programming:</h2> 269 <ul> 270 <li>Every language has its grain. If your Go program uses mutexes, you're probably working against the grain</li> 271 </ul> 272 </div> 273 274 <div class="slide"> 275 <h1>Garbage Collected</h1> 276 277 <h2>Automatic memory management makes writing (and maintaining) programs easier</h2> 278 <h2>Especially in a concurrent world:</h2> 279 <ul> 280 <li>Who "owns" a shared piece of memory, and is responsible for destroying it?</li> 281 </ul> 282 283 <h2>Large C++ programs usually end up with semi-automatic memory management anyway, via "smart pointers"</h2> 284 <h2>Mixing the two models can be problematic:</h2> 285 <ul> 286 <li>Browsers can leak memory easily; DOM elements are C++ objects, but JavaScript is garbage collected</li> 287 </ul> 288 </div> 289 290 <div class="slide"> 291 <h1>Garbage Collected</h1> 292 293 <h2>Go is also a safer language:</h2> 294 <ul> 295 <li>Pointers but no pointer arithmetic</li> 296 <li>No dangling pointers</li> 297 <li>Variables are zero-initialized</li> 298 <li>Array access is bounds-checked</li> 299 </ul> 300 301 <h2>No buffer overflow exploits</h2> 302 </div> 303 304 <div class="slide"> 305 <h1>Systems Language</h1> 306 307 <h2>This just means you could write decently large programs in Go:</h2> 308 <ul> 309 <li>Web servers</li> 310 <li>Web browsers</li> 311 <li>Web crawlers</li> 312 <li>Search indexers</li> 313 <li>Databases</li> 314 <li>Word processors</li> 315 <li>Integrated Development Environments (IDEs)</li> 316 <li>Operating systems</li> 317 <li>...</li> 318 </ul> 319 </div> 320 321 <div class="slide"> 322 <h1>Systems Language</h1> 323 324 <h2>Garbage collection has a reputation for being "slower"</h2> 325 <h2>We're expecting Go to be slightly slower than optimized C, but faster than Java, depending on the task. Nonetheless:</h2> 326 <ul> 327 <li>Fast and buggy is worse than almost-as-fast and correct</li> 328 <li>It is easier to optimize a correct program than to correct an optimized program</li> 329 <li>Fundamentally, it's simply a trade-off we're willing to make</li> 330 </ul> 331 332 <h2>Memory layout can drastically affect performance. These two designs are equivalent in Go, but significantly different in Java:</h2> 333 <pre> 334 type Point struct { X, Y int } 335 type Rect struct { P0, P1 Point } 336 337 // or ... 338 339 type Rect struct { X0, Y0, X1, Y1 int } 340 </pre> 341 </div> 342 343 <div class="slide"> 344 <h1>Systems Language</h1> 345 346 <h2>Quote from http://loadcode.blogspot.com/2009/12/go-vs-java.html</h2> 347 348 <h2> 349 "[Git] is known to be very fast. It is written in C. A Java version 350 JGit was made. It was considerably slower. Handling of memory and lack 351 of unsigned types was some of the important reasons. 352 </h2> 353 354 <h2>Shawn O. Pearce wrote on the git mailinglist:</h2> 355 <ul><li>"JGit struggles with not 356 having an efficient way to represent a SHA-1. C can just say "unsigned 357 char[20]" and have it inline into the container's memory allocation. A 358 byte[20] in Java will cost an *additional* 16 bytes of memory, and be 359 slower to access because the bytes themselves are in a different area 360 of memory from the container object. We try to work around it by 361 converting from a byte[20] to 5 ints, but that costs us machine 362 instructions" 363 </li></ul> 364 365 <h2> 366 Like C, Go does allow unsigned types and defining data structures 367 containing other data structures as continuous blocks of memory." 368 </h2> 369 </div> 370 371 <div class="slide"> 372 <h1>Go</h1> 373 374 <h2>New</h2> 375 <h2>Experimental</h2> 376 <h2>Concurrent</h2> 377 <h2>Garbage Collected</h2> 378 <h2>Systems Language</h2> 379 380 <h2>And more:</h2> 381 <ul> 382 <li>I haven't talked about the type system, interfaces, slices, closures, selects, ...</li> 383 <li>Documentation, mailing list, source code all online</li> 384 </ul> 385 </div> 386 387 <div class="slide titlepage"> 388 <h1>Questions?</h1> 389 <br><br> 390 <center> 391 <img src="support/bumper640x360.png" width="640px" height="360px"> 392 </center> 393 </div> 394 395 </body></html>