Welcome to Emerging Languages Camp 2010. Go by Rob Pike. I'm not the sole inventor here. There's other people involved. I don't want to take full credit for that. But thanks for letting me come and talk a little bit. I'm actually giving three talks at this conference and dividing up the pieces is kind of a bit of a challenge. So I thought today, because this is specifically a language session, I'd focus on a particular detail in Go that has gotten a lot of attention, and that is the concurrency stuff. A lot of the people who've remarked on Go or looked at it have thought that there's something really unusual and maybe even unique about the concurrency features inside Go. And I think they are unusual, but they're not without origin. They actually have a long history, and I thought it would be worth telling this community, some of whom might not know the background where these ideas come from and why Go is the way it is with respect to concurrency communication. The story actually started in the 1970s. Can somebody start the timer there? It goes back to the 1970s when multiprocessors were really a research topic. I wouldn't say there are no multiprocessors available commercially, but there are very few, and I don't remember when they even were. I do remember some other things about the 1970s though. And the problem was that nobody really understood how to program these things. We knew it was a good idea to have a lot more processing available, but we didn't know what to do with it. And there were a bunch of sort of research ideas that floated around at the time, things like monitors, semaphores, locks, which we now know more as mutexes. And there was also a sort of line of inquiry involving message passing. But it wasn't clear which of those really worked well without the proper hardware to try them out on. It didn't seem like we really understand them. A lot of these things were brought up in the context of understanding how to program attached devices inside a single processor system. So it's kind of, you know, what are we doing here? We don't get it. We know it's important. What are we going to do? And so the real breakthrough happened in 1978 when Tony Hoare published a paper called Communicating Sequential Processes, which is locally called CSP.  But I'm going to explain to you there's actually a lot going on in the original ideas of CSP and we still haven't fully mined out this paper. It was a truly seminal paper. What it proposed was a model programming language, not when you could actually execute, although some people later did implement it pretty much as defined in this paper. And it was very unusual. It was really a groundbreaking idea. What it did was take, it turned I.O. into a fundamental property of a programming language and coupled that with this notion of parallel composition of sequential processes. So you have things that are independently sequential, but you compose them and you have them communicate. And that model is the fundamental property behind essentially everything we're talking about today. So there were several things in here. Well, actually really only two things. First of all, communication that is I.O. is fundamental and parallel composition of sequential processes gives you multiprocessing. That's all you need and even to this day is pretty much all you need if you think about things the right way. This paper is pretty amazing. There are more ideas in this one paper. I just read it again last week when I was putting this together. There are more ideas in this than probably any other ten papers you could easily put your hands on. It's really worth talking about more and I'll talk a little bit more about the paper itself later. So what does this language look like? Well, it's pretty mathematical and strange, but it's actually kind of pretty in a way. It generalized these things called guarded commands or Dijkstra's guarded commands as they're more commonly known, which is basically just a way to express conditional processing in various ways. Horde generalized this into this idea of communication as the guards and the notation developed had several simple elements. This is not complete, but it's pretty close to a complete definition of language. So P-Bang value sends a value to a process. P-QuestionVar receives that value and stores it inside a variable.  So the last really strange thing is really in this statement, except in the nature of Dijkstra's guarded commands, the various conditions, the guards, little a and little b, are actually evaluated in parallel, whichever one can proceed as the one that goes. And those guards, of course, can be communications or, in fact, much richer expressions. And then on top of that, you have this notion that when you communicate, when you exchange a value on P, the sender and the receiver are synchronized. And that's it. That's pretty much the whole language. And so here's an example. I'm not going to talk through this example because it's, you know, messy. It actually does work, I believe. I'll show you later.  So there's three processes here. Copy, disassemble and assemble, copy. Copy is all the characters from West to East. Disassemble takes a set of characters on 80-character cards. Remember cards? I do. And just emits them as sequential characters. And then the assemble guy takes the incoming sequence of characters and reassembles them into 125-character cards.  I've got 80-character cards. I want 125-character cards. How do I reformat it? And that doesn't sound like a hard problem, but if you try to write it in a traditional standard programming language, especially one from the 1970s, it's a remarkably fiddly, annoying problem. And here is this sort of three-element process that we then combine at the bottom. And this is really the key point. This bottom line here is the parallel composition of those three processes. And you can observe that you don't actually need copy. You can run disassemble directly into assemble. But the reason copy is there is in the paper he substitutes other processes inside there to do other intermediate operations on the characters as they go by. And of course, to anyone who's programmed in Unix, that looks just like a pipe one. And that's no accident, but in 1978, pipes were new. And this was a way to formalize the idea of a pipe inside a language. There were more properties in this language that were interesting both for good and for bad. The ports that were communicated on, like the east and the west in that previous example, were actually processes. There were names of processes. The idea was you communicate with a process. This is, after all, communicating sequential processes. But they were not programmatic. They were just defined in the program. And so that meant that, for instance, you could write a concurrent prime sieve to generate the first thousand primes. But you could write a program that generated n primes because there was no way to parameterize the number of processes. Those processes all had to be created statically. As a slightly more interesting example, he gives an example where you do matrix multiplication on a three by three matrix. But you can't write the code for an n by n matrix in this language because you need a process for each of those dimensions and you can't express the dimensionality as a variable because the processes have to be static. And this will become very important in a minute. But there are some other nice properties of the language. It had this idea of pattern matching to analyze. So remember those guards that do conditional execution? Here's a guard that says if we receive from C a pair x and y, then you can do A. And the point is that x, y is kind of a pattern match. I'm expecting an x and a y. I'm going to receive a pair on this thing. So if you cannot parse the message into an x and a y, then that guard blocks and another guard must execute. And you can write more general conditions like you can say if I is greater than 100, then I can receive an x and a y from C, then going to A. And so that's a more general thing and you'll see an example of that in a minute. One interesting problem with CSP from where we're going to go is you can't use a send as a guard. You can only receive. You can only say, am I allowed to receive one of these? You can't say, am I allowed to send one of those? And that didn't seem like an issue at the time, but we'll see. It actually is a generalization we'd like to make. So to recap, you've got this paper that defines a whole bunch of things from scratch in a kind of mind-blowing way for the time. You've got this idea of a parallel composition of independent processes. You've got communication and synchronization combined into a single set of operators. You've got things that don't share memory. These are independent processes and they just exchange values. They don't share anything. So there's several models you'll recognize that are not supported by CSP. In particular, they're not threads. They're not mutexes. Things are different like these all together. And so here we are in 1978. We have a paper that pretty much lays out everything we need to know about how to program multiprocessors, how to think about concurrent algorithms, how to do communication and synchronization together. We can program parallel code and there isn't a lock anywhere. So this is a pretty important step. But it's also a theoretical paper. I would bet money that every program in this paper is correct even though it was never been executed. But that's Tony Hor. That's not a normal person. And so we have to turn this into something useful. And what happened was, so the next few years people sort of digested this and the road sort of forked into multiple paths. One of the paths generated a language called ACOM. And ACOM is interesting in this story because it's the closest to CSP. A company called Inmos in Britain, in Bristol, designed a machine in the early 80s called the Transpuder. And the Transpuder was a parallel piece.  They were unusual processors, but they were general processors. But they had essentially CSP connections in hardware. So each computer could talk to his neighbors with a communication synchronization device. And Inmos designed this language, ACOM, to represent the communication capabilities of this hardware. In fact, the ACOM compiler was written in ACOM, although it was something of a tour de force. ACOM in general to write code like that. But it was a really interesting piece of hardware and an interesting language that was fundamentally CSP with slightly different syntax. But you recognize the bang in the question, the conditions. This program receives 100 things from C1 and 100 things from C2 in arbitrary order, adds them all up, and then sends what the two counts were at the bottom. And if you squint a bit, you can see that it's very much like the syntax of the original CSP. And in fact, Tony Hoare was a consultant on this system. And it was pretty important because it showed that you could actually write real code that really ran in this world. But it was a peculiar language whose lingering effect might be using white space for indentation rather than anything in the communication model itself. But another branch that came out of here, although quite a bit later, was the Erlang branch. And Erlang differed from ACOM in that it was very network, it was functional, and it focused on the pattern matching capabilities inside CSP rather than just the basic communication. Erlang was developed in the late 1980s at Ericsson. There's, I think, a deliberate question whether the language is named after a Swedish computer scientist or stands for the Ericsson language. But it's different because it's profoundly functional. Now the original CSP had variables and you could assign them and stuff like that. But without making much mental state at all, you could turn into a purely functional idea where a variable is only assigned once it never changes value. And that has certain expressive capabilities. They're important when you're trying to exchange messages between processes without sharing data. And so Erlang took that, it promoted functions and processes as things that work across a network, and it brought in the idea of a mailbox. So a process in Erlang is very much like it is in the original CSP. But there's now this somewhat richer model of a mailbox, which is a thing that parses input that it receives. And so you can see this alternation here is receiving a bunch of different things and depending on the elements of the messages you execute different commands. So the guards become these parsing sort of message unpacking operations. And Erlang is actually quite a beautiful language. A lot of interesting software has been written in, a lot of commercially important software. But it's unusual because it has this profoundly functional and very sort of rigid model of the communication. I don't mean that as a criticism, I really think it's kind of beautiful. But it's not the kind of language that I, for instance, want to write code in all the time because I can't communicate with... I can't write code comfortably that isn't somehow expressing the things I want to do like write operating system software and stuff like that. And so we come to the third branch, which is the New Squeak Limbo Go branch, which is clearly where we're going to end up here. And here the focus is different because in the Auckland branch, we really based on ports and communicating basic messages between processes. Erlang, we've got this mailboxes and parsing. And in this branch, we're going to focus on a thing called a channel. There was a paper that probably none of you have read, and I don't think you probably want to dig back that far, but in 1985, Luca Cardelli and I wrote a paper for SIGGRAPH on a language called Squeak, which is unrelated to the thing that's called Squeak today. And Squeak was a toy language. It was kind of like a yak. It takes a grammar and generates a C program for you. The Squeak processor took a concurrent program and turned it into a sequential program with a state machine compiled into a C program for you. So you could write code with this, and it worked, but you wouldn't want to write much in it. It was really a research idea to show what would happen if you use the ideas of CSB to program graphical user interfaces. And it was a research paper, and it was kind of fun, and actually sort of influenced some thinking for a while, but I don't think it has a sort of lasting legacy, except that you can see this is very CSP-like, and it also compiles and runs. You can actually execute this code inside a Squeak with the processor. And again, the important thing is down at the bottom here, you see the parallel composition of, that's type as in typing on a keyboard. This is a program that lets you type code and then type text and have it appear in a window on the screen. So the typing program is the composition of the mouse process, and the text process. Okay, but we haven't got channels yet. These things are communicating between processes. A few years later, I've been doing a lot of graphics work and wanted to write real graphics code, and the ideas in Squeak were interesting to me, but I didn't have a programming language I could use to express them. And so I took some time and designed a language called New Squeak, which I thought was a good name, and around 1989 this became an actual implementation you could use to write real code. And several quite interesting programs were written in it. Again, it was a research language, you wouldn't want to spend your whole time in it, but it was actually fun to write code in and there was some important stuff written in it. Syntactically it looked like C, but it was a purely applicative language, and it had this concurrency stuff built into it. And so here we have the first language that I got to use where I could write real code with the ideas of CSP, and it was very important to me and a lot of interesting things came out of it. New Squeak had lambdas, which were what I called pro's in the language, it had a select statement which was essentially the alternation of CSP, but it was restricted to communication. You couldn't write composite conditions on those branches. It had also two, for you guys, things that you may recognize, they're going to turn up and go. Two syntactic inventions arose in New Squeak. One was the left hour operator for communication. I managed to find a way to express receive and send using the same operator which cleaned up some syntax. It also made it possible for the receive operation to not store something in a variable, but to just be an expression. And of course that was important for someone with a C background to just have receiving a value be an expression. And then also, I was very proud of this, in the Pascal notation that New Squeak used for declarations, you declared a variable by saying x colon int equals 1. That declares a variable called x type 1, type int value 1, but it's obvious that 1 is an integer, so why bother to type all that? So in New Squeak you could drop the int out and then that made colon equal a kind of pseudo operator that declared and initialized the variable. And that lingers on and go, and it's a very nice convenience that turns out to be pretty important to the way it works. So maybe this is my major conservation of computer science, I don't know. Here's the prime sieve, the famous prime sieve, the concurrent prime sieve, it's really not the sieve of erotostomies, but it's in the CSP paper in CSP. I didn't show it here because it's quite difficult to understand in CSP, it's a little easier here. Again, I'm not going to talk through all this, but there's a couple of important things to recognize in here. First of all, these are three process definitions.  Filter, which does the primality filtering. And sieve, which is the thing that composes a chain of processes to do the sieving generally. What's interesting here in this program is in the middle, it says sieve is a program of chan event. That of chan event means that the value of the sieve program is a channel of integers. And this is actually the moment in this story where something different happens. Because having a function that returns a channel gives you a power that was not available in any of the other languages, at least not with nearly this sort of clarity. So this was a bit of a breakthrough for us. This is the way to write the prime sieve. It doesn't matter how many primes you get. You don't have to pre-declare a thousand primes or something like that. This gives you the programmatic ability to stitch an arbitrary dynamic structure out of channels. And so channels here are first class values. And this is the fundamental difference on this arc. The thing about a channel's first class value is not only can it pass it around, use it as a return value for a function, there are two important things that come with that. One is that I can send you a channel on a channel. If I have a channel, I can give it a type channel, and that means I can send a channel along, just like in a regular channel, I can send an integer. And that gives me the ability to communicate, the ability to communicate. And of course, everything in computer science that matters is an indirection. We've just built that indirection and communication, which is fundamental to a lot of these models. And secondly, that channel is itself a form of capability. If I give you a channel that talks to me, then you can talk to me on that channel, but you also have the capability to give that channel to somebody else. It becomes a handle, a bit like a file descriptor. Whoever prepared that channel can hand it off to anybody who can continue to hand it over to somebody else. That indirection of capability to communicate is really important to doing things like building multiplexers, constructing arbitrary security barriers between processes and things like that. It's a very, very important idea. Now, things like that exist in languages like Erlang, but not as generally. In Erlang, the notion of process ID is a first-class value, and I can receive capability away by handling that process ID as a value, but it's not fully symmetric. The send capability is actually missing. So the problem with Newsquake was it was just a toy that ran very fast, and we liked the idea so much, we wanted to actually use it. And there, Phil Winterbottom, who was working with us at the labs, decided to take some of the ideas from Newsquake and make them work inside a real systems language, which he called LF. And LF, superficially, you can think of as just C with this concurrency stuff built in. You wouldn't be very far off the mark. And it was a lot of fun to write in because we finally had an efficient language you could use these concurrency and communication ideas in, but the problem was it was a C underneath, and so you had to deal with Malik and free on your own. And all the other languages we've talked about up to now, memory allocation is sort of implicit in the language, which is another way to say it's garbage collected. LF was not, and half of the code in an LF program that did the communication had to figure out who was responsible for freeing this object you were passing on. Not having garbage collection available in a concurrent language turned out to be a bit of a deal breaker. And it wasn't the reason LF died, but it was a reason why it wasn't, as useful as it might have been. Without garbage collection, it just wasn't as nice to use as it should have been.  But for his own reasons, which were probably good, he didn't do it, and that sort of was a problem. But a year or two later, Phil, along with Shrondor and myself, did a language called Limbo as part of a project at Lucent to do TV set-top boxes and stuff like that. It was exactly contemporaneous with Java. There was a little VM, and it had all this nice... It was quite a nice little language to work in. And it was probably the most successful language on this stream so far, on this branch of the sequence so far. Because it was a true embedded language with communication primitives, concurrency. It was garbage collected, of course. It was very nice to use in a lot of ways. And it was successful within its limited domain. I think not as successful as it should have been given the quality of the work in it. It was pretty much sort of rethinking New Squeak 10 years later with a much better grasp of what needed to be in a language to make it work. And again, channels were the fundamental thing here. The Limbo had channels as first-class values. But then things happened, things starting with J, and sort of died away. So about 15 years go by. And I gave a talk about three or four years ago, which is on YouTube, about New Squeak, really about New Squeak in a language series there. And it got me thinking that it was time to revisit these things. So a few years ago, Robert Griesen and Ken Thompson myself started talking about this stuff again. And we thought for reasons that are... I'm going to talk about a lot more tomorrow in the Oskan keynote. It was really time to rethink the whole language approach in general. But as a consequence of that conversation, we've now got a language, which is called Go, that is a compiled, object-oriented language with concurrency built in. And it's got... It's a modern language with these CSP ideas available as first-class ideas inside the language. And it's wonderful. And when people say that it's novel and unusual, I think they're right. What they're missing is how much delight you can get from programming with these things in a real world. And so we now got the power of CSP in a particular model that the sort of channels as first-class values branch. And you get garbage collection, but you have a compiled language, and I don't know who does cryptography calculations or graphical calculations or something like that. They will run very efficiently. And so you get the power of concurrency in an environment where fundamental computation is really efficient. And that's a really, really nice mix. Then the object-oriented stuff makes in too, but that's not what I'm talking about today. And so you get the best of all worlds in one easy package. And it's actually pretty nice to use. So here's that card reassembly example. Slightly simplified. I took out an edge condition that makes the code longer, but not more interesting. And you can see that it has some of the flavor of the CSP version. There's the copy guy, the assembler, and the disassembler. And there's the composition guy down the bottom. You actually just relaunch the three things we call them go-routines. The three go-routines together. And they do the work. And this code actually works. I ran it. It functions. It does the... Whenever I need to reassemble punch cards, this is the code I'll run. But you can see that it's changed a lot from the CSP version because you've now got a syntax that feels a bit C-like. You've got the arrow operator for communication. You've got colon equals and types. You've got channels. But fundamentally, this is the same idea. This is the idea of writing programs as a parallel composition of communicating sequential processes is now available in a language that you can actually use. And that's pretty nice. It's a long history. It's conceived by some people as being very novel. It's actually not... I think it's novel in its context, but the ideas go back longer than I care to recount. And it is nice to have these ideas available. But there are other languages out there, too. Erlang being probably the most famous that has very similar ideas rooted in the same paper. Channels as first-class values, though, are unusual, not unique, but unusual, and I think mostly on the branch of the New Squeak. And it's also nice to have all of the combination of high-level modern language capabilities available along with the communication things. CSP was about communicating. GO is about using communication inside an environment with modern language features available. And the fundamental point here is that in order to make this work, you have to have garbage collection and you have to have things like automatic stack management available. It's very hard to graph these onto another language like LF. You get into... It just doesn't feel right, doesn't work very well. And there's a lot more to go than concurrency, as I think I've hinted, and I'm giving actually two more talks tomorrow, which is a little shocking, in the Oskan branch. So unfortunately, it'll conflict with some of the sessions here, but if you're interested in learning more about GO, you don't want to go to the talk tomorrow where I'll talk in a lot more detail, but many of the features of the language, of course, golang.org has everything you need to know. If there's one thing you get today, I want it to be, I should read that CSP paper. It is an amazing paper. It is worth every minute you spend with it. And here are some quotes from it. Remember, this is 1978. I will honestly say that some of you probably weren't born in 1978, but some of you probably were. Not everyone here is as young as the people I work with. First of all, notice the first line, processes may not communicate with each other by updating global variables. That's no shared memory. Don't think like that. In the second quote, he says that co-routines, which we call go-routines, sort of in-go, are more fundamental than subroutines. I think when you realize that, you understand the power that you get out of it. And then this bottom one may be hard for you to parse, but what it's saying is that a process that you communicate with in isolation is isomorphic to a similar class or a Java class or C++ class, for that matter. There's a fundamental sort of isomorphism there. That's pretty important and good to know. So I'll leave those up and take any questions you may have. How are we going to do questions? Do I just repeat them? Yes. How does CSP relate to the Pi calculus? That's an interesting question. When I did New Squeak, I learned, because I didn't know, that it relates pretty directly because the fundamental process control stuff inside New Squeak is an expression of the Pi calculus in a certain way with operational semantics and all this kind of stuff that I am not an expert in. But people in the talks I gave about New Squeak would come up and say, do you realize that? I think the CSP paper is the godhead for a lot of that stuff. It wasn't the only thing around at the time. There were other people working in related things, but the CSP paper seemed to distill those ideas as something that you could understand if you were reasonably intelligent and get the whole idea in one paper that wasn't totally impenetrable. Yes. The question is why the Go type system isn't the same as everybody else's type system. That's a fair question. And to be honest, I'm going to talk quite a bit about it tomorrow. But the basic reason is that I'm sorry, tipping my handle a bit for tomorrow. I think that the modern type systems have a lot of power, but I think that that power is overstated and one of the reasons that there's so many people in this room who've invented new programming languages is because they're frustrated with the complexity of the type systems in the standard languages. Let me just cut it off there so it doesn't turn into a discussion of tomorrow's talk. You may be right. Yes. How do you know the code you write in Go is going to have no deadlocks or race conditions? Or be correct. The answer is there are no tools. Specifically, there's a problem that I didn't mention, which is also in this branch that Gerard Holtzman wrote that lets you use CSP to express and verify correctness of algorithms. And you can translate Go algorithms into Promenade if you want and so on and so on. And I think that's actually a useful thing to do for certain problems. The thing that is hard to understand until you've tried it is that the whole business about finding deadlocks in programs like this doesn't come up very much. It comes up all the time. And that's because it's just too low level. If you program like this, I'm not saying deadlocks don't happen, of course they do, but they don't happen very much. And when you do, it's very clear why because you've got this high level state of your program expressing. This guy's trying to send it here and he can't because he's here. It's just very, very clear as opposed to being down at the mutex-shared memory level where you don't know who owns what and why. And so I'm not saying it's not a problem, but it's not harder than any other class of bug that you would have in a Go program. And until you've tried it, you don't really see it. I'm going to put words in Robert Griezmer's mouth because he's sitting right here. But he's never written concurrent programs before and he worked with us on Go. He did a lot of the type system work and implementation stuff. And he'd never written concurrency code before, but he found using this thing that not only is it easy, he just finds that it's just sort of very natural. Am I being fair? Do you find it difficult? Yeah. Try it. You'll find that it's surprisingly nice to use. Yes.  Because of the memory system and the type safety, it's actually a statically safe language to very high precision. There's a way you can cheat, which is called unsafe. You import a practical unsafe, but if you import unsafe, you're cheating. But there's no type punting. You can't turn a ninja into a pointer. There's just none of that stuff. It has pointers, but no pointer arithmetic. And so we believe that if you don't use the unsafe package, it's easy to demonstrate safety in the program. You can get SegFalls if you use uninitialized, but safely uninitialized variables is the only kind you can get. But the program catches them, the runtime catches them. You can't derive... Basically, it's impossible to correctly write a memory incorrect program. Yes? There's a fair bit of... It's only been out for a few months in the public. And some people have built websites and web services built entirely on top of it. Golang.org website is entirely a Go program. But the most interesting example is one I can't describe, but we are using it internally for some production work inside Google. There's fairly high traffic stuff, and the people of use that are pretty happy with it. I think it's ready for prime time for certain categories of problems. I think we've reached that point. Yes? Can I give an example of why the channels are more powerful than Erlang's mailboxes? No, because I don't think they are. I think they're just different. I think Erlang mailboxes have a certain expressive power. They do certain things well, certain other things not so well, and channels sort of are different. Process IDs cannot capture is this idea of a general capability to communicate. You can capture the send capability, I mean the receive capability, but not the send capability. And I'm sure you can prove that they're isomorphic. But the feeling you get with a channel is this thing I have in my hand is the ability to communicate. And I can build data structures with it. I can send it to somebody. I can receive it from somebody. It's a very sort of a nice encapsulation of the idea. And Erlang encapsulates it in a completely different way. And I wouldn't want to go to the mat saying one is better than the other. But they feel very different in how you use them. Yes? Do I think Go is appropriate for language runtime implementers? Probably.  It's got a runtime that's under... It is... People get confused by this because Go is a compile language with a runtime. But it's not like a JVM, right? It's actually native code, but essentially it's got a runtime library that lets it manage memory and do communication, concurrency and stuff like that. I know at least one person who's using it to build some VM experiments to play with. So I know it can be done. It's probably an interesting choice. It might be an excellent choice. Yes? Has the state-of-the-art advanced the point where co-routines can be broken up and put back together as efficiently as regular subroutines? I think the short answer is no, but they're much cheaper than you probably think. The things we call go-routines, we gave a new name because they're not really the same as co-routines. They're not the same as processes. They can be extremely lightweight. Their lightweightness depends on how you use them. So just creating a co-routine to do something and throw it away is basically the cost of a malloc, which is pretty cheap. As far as general performance, it depends very much on the problem you're solving. But no, of course, go-routines have more runtime weight than a subroutine, but not a lot more. And it can actually be pretty efficient. One of the things I didn't really talk about is that Go manages stacks for you automatically. So you don't have to declare how big the stack is. It grows in strings on demand and stuff like that. That allocation requires basically allocating a stack block to launch the go-routine into. And everything else is a fairly small number of instructions to get one going. They're pretty lightweight. Yes. Just go make sure the messages are immutable or copied. It depends on the type of the channel. If the channel is a channel of immutable values, then yes, they're immutable values. If it's a channel of shared values, it's a shared value. They're like any other value in the language. If you've got the address of it, you own its address. If I have a channel of pointer-destruct of some structure, remember, channels are tight, so you can only send things a certain type. If the channel is tight, it's a channel of pointer-destruct. When I send that pointer to somebody else to work on it, I can forget about that structure. It's very different from locking to access this thing at the same time. I literally use the channel to hand it away and forget about it. You could remember it, but that's not the way... Well, then you're sharing it, and you don't want to do that. It's a bad idea. This is a systems language, which means you should have the choice to do efficient things if you know what you're doing. You shouldn't be told you can't do that because you might get it wrong. Let me explain. The model for sharing and locking and all that stuff is like having a big piece of paper. We'll gather the paper and we make notes on it, but who owns what when, and we scribble and erase and rewrite and work on it, and so on. This model is you don't have one piece of paper, you've got lots of pieces of paper, and you write a message on a piece of paper and you give him that piece and he goes away, and you don't have it anymore.  Because the individual pieces are broken up, there's no concern or worry about who owns what at any one time. It's whoever's got a hold of it at the moment. It just doesn't come up as an issue that for efficiency reasons I want to pass a pointer on the channel because once I've passed it, I forget it. And the only person who has it is the person whose business it is to deal with it right now. If you're worried about it and you really care, don't pass a pointer. Pass the value. Make it a channel of struct rather than a channel of pointer to struct. It will be a copy and there's no way you can share. But that's your decision, not the languages. The language makes it easy to do the right thing well, but it also makes it easy to make it efficient. And I think that's a really good point to end on. Thank you.


So today guys, I have been giving you 5 things to farm for that easy money pulse patch 1.1. So let's go. How's it going guys? My name's DPJ and to give back to you guys, I'm giving away 10,000 marks of fortune. To be in the chance of winning them, simply make sure you are subbed to this channel and have those notifications turned on. Drop a like on the video and leave a comment down below. Okay so since the latest patch to 1.1 patch, many instances of the game have changed. Trading prices on certain items have gone crazy, while other prices have dropped. And today guys, I've been giving you 5 things you can easily farm which you'll see you earning good money. And this is something more or less anybody can do, but it's made so more for the people who struggle making that gold coin. Now each one of these items today I am showcasing, I will state you can easily earn between 1 and 2k gold coins using these methods so let's get into it. So firstly guys this is an item I did mention to people that they should have farmed and brought for those pennies in prep for the 1.1 update because once that hits, this is an item that's going to be needed for many many more things and its price will go up. And it did. The 1.1 patch is now here and the price of Heist Up has definitely gone much much more expensive and rightly so. It easily sells on my server between 0.30 and 0.80, it just fluctuates throughout the day and this is a server that is seriously populated. Now before going into any guide guys, like I say, from any guide you see from me or anyone else, make sure you check prices on your server, if it isn't worth it obviously don't waste your time doing them. Now Heist Up comes from herbs, herbs can be found anywhere on the map, while certain areas will offer you even more profit due to there being additional herbs tied to Heist Up, for instance as you can see on the screen now, different areas drop different kinds of herbs as well as the Heist Up so it's probably best to check your server of prices on these additional herbs before making your mind up where to farm. But you can see some great spots on the screen now which I spoke about in a previous video so check that out. As you can see on the screen now are locations in my opinion the best locations for farming those herbs, firstly Monarchs Bloth, this area here in Monarchs Bloth is full of herb, head here, rotate around this area and you'll find a ton of them. Next up first a light, this area right here is incredible for herbs and I rarely see anybody else here. Next up guys they're great spotting everfall, I've used this so so often and again I barely see anybody here. And lastly guys this is a spot in Ebenscale Reach which is by far the best spot for those herb plants, I mean there is absolutely tons here as you can see on the screen now, all these little markers are herb plants, the only problem with these places though, time and ginger well on my server at least don't sell for much money, but if you're only interested in that high sup there's no better place on the map.  Okay so next up people we have oil, oil always will be a great seller in my opinion, well that is unless amazon make it useless like a couple of other things they have done. Yeah but oil people cannot get enough up and with buy orders everywhere use this opportunity to make that money people. Now using this spotting with this fen there's just an unlimited supply of that oil via those seeping rocks. Now oil on my server always sells but at different times of the day prices go up, so don't be afraid to list it between a 0.50 and a 0.80 it will definitely sell for sure. But yeah guys use this spot with this fen to farm those seeping rocks for that oil, this area is absolutely littered and I mean littered with those seeping rocks. Okay so next up guys we have malts, life, death, earth, fire, soul, you name it they're here. Now these sell for absolutely ridiculous money. Now within the 1.1 patch amazon changed up how you could earn these by adding them to the loop or those mystic wolves, bears and stags but they quickly eliminated that via disabling the possibilities to farm them. Now as a result it seems as though malts have gone back up in price with individual types selling for like 0.80 each and considering some of the routes to farm you'll be earning upwards of a thousand of these in a little over an hour. You can seriously make some dust out of these people. Problem is there's a good chance that when you run these routes for these not all will be there. The best thing you can do is use the new world map website which I'll link down below, search for those certain malts and where they come from and then run your own route but obviously make sure price is on your server decent enough first. So next up guys the bulrush cubs these for some reason are selling for decent money considering how easy they are to farm as well and the plants that these come from around a one minute timer you can farm thousands of these in no time at all. So with this all you really need to do is more or less find any water source on the map and around it will be tons of bulrush plants simply farm away and you will start seeing those bulrush cubs drop which we farm any spot for a minute and within that time the plants will have already respawn back in which is crazy. You'll get tons of reads too these on my server don't bring in tons of money but will sell at the same time. Also near those water sources are briar branches these two will drop those briar buds which can bring you in good money also guys so yes more or less head to any water source I like the one this one you'll see on screen now right by everfull I mean if you run one route around this by the time you run around it everything's respawn you can just keep doing this for as long as you want so yep any water source guys farm these and make that money and lastly today guys we have salt salt still sells for crazy crazy money and that's because it drops from one source and that isn't a guarantee that source is provisions creates mainly provisions creates within everfall and brightwood are where these are at now I made a route a video you could follow about two weeks back where you'd earn between 35 and 60 salt per run I'm not long uploaded an updated video where we run around brightwood and everfall and you get my mate did it with me the other day and he got 115 of the salt per run takes you about 45 minutes to an hour to run it by the time you run it you can just because there creates reset you can run it again so you can do this route for hour upon end and you will earn tons and tons of salt guys so the route you're seeing me take on screen now it's just a snippet of the full video which you'll find I'll link it in the video description but you'll also find it on my channel too so check it out like I said it takes you roughly 40 minutes to run probably when you first do it probably 45 50 minutes but by the time you've run it once you can more or less reset it because the chest reset after an hour run it again earn unlimited salt people but yeah the full video because it is quite lengthy I run the whole route is on my channel and I'll link it in the video description but it is absolutely easy money you haven't got a word about anybody else picking these up they're always going to be there for you so salt is definitely the best money earner in my opinion so go get it and sell it guys and there we have it people five amazing things to farm and sell after the latest 1.1 patch within the new world yes I know some people watching this video uh this to those end end end game players won't seem that great but for players out there struggling to make that gold who think making 1 to 2k gold per hour is decent these are definitely for you and that's what basically most of my guys are I try and put guys out there which represents the whole of the community for everyone can make money using these and not just like the top 10% but yes guys the end of the video has arrived if you enjoyed it leaving a like really helps out if you're new around here want to see more new world be sure to subscribe and if you never want to miss a video upload you can turn notifications on by hitting that bell button my guys thanks as always for stopping by and hopefully I will see you on that next one


That whistle is your signal for the signal oil program, the Whistler, rated tops in popularity for a longer period of time than any other West Coast program. And signal gasoline is tops too, tops in quality. It takes extra quality, you know, to give you extra mileage. And signal is the famous Go Farther gasoline, available wherever you see the signal circle sign in yellow and black that identifies independent signal dealers from Canada to Mexico. I'm the Whistler, and I know many things for I walk by night. I know many strange tales hidden in the hearts of men and women who have stepped into the shadow. Yes, I know the nameless terrors of which they dare not speak. And now the Whistler Strange Story, letter from yesterday. Seating by the window of the streamliner as it sped through the night toward Los Angeles, Arthur Wilson seemed like any average middle-aged businessman. But there had been a time when Arthur Wilson was something else, somebody else, Jack Foley. And though it had been 25 years ago, Jack Foley now Arthur Wilson would never forget it. The plaintive whale of the train whistle drifting back at him now somehow recalled that other time and place exactly as if it were now this moment. Perhaps it was because another whistle had marked the time when it all began. The night that Jack Foley was given a chance to reach out to grasp a new life that night 25 years ago in a prison machine shop. Clean up the shop. Right. Well, Dave, that about does it. This truck's practically got a new motor in it. Yeah, she's in fine shape, Foley. Come on, let's get this stuff cleaned up for the way. Foley. Yeah? The ignition keys. Hand them over. What? Look, I don't want any trouble. Give me the keys. I'm getting out of here. Prison break? Well, now, wait a minute, Dave.  It's all set. Everyone's on harass to buy the delivery gate. I'm picking them up with this truck and we're getting out. You want to come along? Hey, what? Make up your mind foley fast. The guard will be coming back here and I got to take care of him. What do you say? It happens suddenly, doesn't it? A chance for freedom thrust into your hand. You have three more years to serve on your sentence for manslaughter. A sentence that was the result of a moment of blind, unreasoning anger. You still feel it was unjust, don't you? That the judge's decision was too harsh. And now, in an instant, it's up to you to make your own decision. Come on, Foley.  The guard's on his way back here now. All right. I'm with you. Let's go. Dave, the guard back there. You should have gone easier with him. Maybe I should have let you do it and killed the guy, eh? Are you sure this is going to work? Stop worrying, will you? I told you I took care of everything. Look up ahead. It's Evans and Harris waiting. And there's the gate guard out cold. You better slow down, Dave. The alarm. They'll never get us now. Swing on, you guys. We ain't stopping. There's a one-way ride and none at all. You're on a train now. It was a very different ride you took that night. But when it was over, you were a free man. And Jack Foley Convict became Arthur Wilson, hardware clerk of Medford. Later, Arthur Wilson proprietor. You were never recognized or challenged. And now, many years later, you're able to journey toward Los Angeles to attend the wedding of your daughter, Sally. The trip is uneventful, calm. The hour before the storm. But you have no way of knowing that. And on an evening a week later, you're thinking only of Sally as you dance with her at the home of Mrs. Alice Terhune Franklin, mother of her fiance, Stephen Franklin. Oh, Dad, isn't it wonderful? I'm so happy. I know you are. You sure? I guess I do. The best part of the whole thing is you're here. You think I'd miss it, dear? My only daughter. To think in four more days you'll be married. I wish mother could have been here. Yes. So do I. Do you like Stephen? Of course. He's a great kid. Your future mother-in-law seems very nice, too. Mrs. Franklin? She's swell, Dad. Come on, let's go join Stephen. He's in the library. You can't leave that man of yours for five minutes, eh? I'll leave him later for a dance with you. All right, dear.  Thank you, Mr. Wilson. Enjoying yourself, sir? Yes, I'm doing fine. I bet you do a lot better with a little refreshment. Oh, Jameson. Yes, sir? What'll it be, Mr. Wilson? Creme de menthe? A stinger? What about you, mother? A stinger sounds exciting, but just a small one, Jameson. And please have him to serve the sandwiches. Yes, ma'am. And you, sir? A sting will be fine for me, too. Bring them out on the terrace, Jameson. I want Mr. Wilson to see the way we've lighted the garden. Oh, now be careful of mother, Mr. Wilson. Dangerous woman. Now you two run along and dance. Sally, take him away. I'd love to. That son of mine. He's a fine boy. Yes, he is. Here, we can go this way. Oh, thank you. This is nice. Yes. And it was a good excuse. I wanted to talk to you, Mr. Wilson, alone. Oh? This is rather difficult for me to talk about, Mr. Wilson. But, well, quite frankly, I'm concerned. Now, I don't want you to think it's because we don't all love Sally. We do. But, um... But what, Mrs. Franklin? Well, you've run a hardware store, Mr. Wilson, in Medford. Anything wrong with that? Oh, no, no, not at all. I'm sure that it's a very fine store. But, um... But before that, who were you? What did you do? Who? Who was I? Well, what I mean is, we know so little about you. Sally herself doesn't even seem sure. I only wondered if you... It's quite natural that you'd wonder, Mrs. Franklin, but I can set your mind at ease. I was brought up by an uncle. Ran away like so many youngsters did in those days. Went to sea for a while. Oh? And your uncle? Where is he now? He's dead. He was my mother's brother. As for my father, well, I scarcely remember him, but... Mr. Wilson, I don't mean to recall unhappy moments to you. I know you must think I'm terrible, but you see, my son... I think I understand. I feel the same way about my daughter, Mrs. Franklin. I'm proud that she's marrying Stephen. Thank you. And I'm sure you can see that I would at least inquire so that the children shouldn't make a mistake that they might regret. No regrets, Mrs. Franklin. No reason that there should be. Believe me. Very well, Mr. Wilson. We won't discuss it any further. And thank you. After all, the important thing is that Stephen is going to marry a fine girl. I'm glad you feel that way about Sally. Oh, I do. And now, if you don't mind, I'll just go back in. Stephen knows that I've been worried, and I want to tell him that everything is all right. Well, thank you. Can I hear a few minutes? Oh, yes, you, by all means. It's so nice and quiet that it gives a person a chance to think. Yes. Oh, and here's Jameson. You can serve Mr. Wilson here, Jameson. Yes, ma'am. I'm just going back inside. I'll take mine. Thank you. I'll be along shortly, Mrs. Franklin. All right. Your drink, sir? Oh, yes. Thanks. Thinking of something else? But it doesn't matter. I think it would, sir. To her. What are you talking about? Delightful woman, Mrs. Franklin. Pleasant. Friendly. But very, very devoted to that son of hers. All she has in the world, you know.  Presumptuous? Oh, no, sir. Not at all. I wouldn't dare be presumptuous to one of Mrs. Franklin's guests. She could cause a lot of trouble, you know. To anyone who wasn't right in line.  I don't suppose you've been sampling these stingers. No, sir. I never drink when I've got business on my mind. But I don't want to be confusing. I want to be perfectly clear. She was asking questions, wasn't she? Wanted to know all about you. Oh, say here, Jameson. I'm talking, sir. You'd better listen quite carefully if you know what's good for you. Because I could break up your daughter's marriage in a minute. Mr. Jack Foley? Jack Foley? Yes, sir. We know the gentleman, don't we? Now shall we talk about him? Or do you think Jack Foley'd prefer to go back behind those prison bars? With the prologue of Letter from Yesterday, the Signal Oil Company brings you another strange story. By the Whistler. Now here's good news for you drivers who will be needing a new battery this winter. Did you know that there's now a new, finer battery which lasts up to two and a half times as long as ordinary batteries? I'm referring to the new Signal Deluxe Battery, which is guaranteed for a full two and a half years on a service basis. The secret of this amazingly long life in Signal Deluxe Batteries is their improved design all rubber separators, the finest type known to battery engineering. But longer life is only part of the story. In addition, Signal Deluxe Batteries deliver up to 35% more power and require water far less frequently. So much for their quality. But how about price? Well, considered on a per month basis, which is really the only way to figure battery costs, Signal Deluxe Batteries actually costs less than many ordinary batteries. No wonder drivers with an eye to economy, as well as those who demand tops in performance, are both heading to Signal Service Stations for a Signal Deluxe Battery, the new, finer battery, backed by a full 30 month guarantee. And now back to the Whistler. It was a sudden thing again, wasn't it Arthur? Like the moment of anger that resulted in your sentence for manslaughter, more than a quarter of a century ago when you were still Jack Foley. The sudden decision you made a few years later to join in that prison break. And now this startling recognition by a servant in the home of your daughter's fiance who calls himself Jameson. He can destroy everything, can't he? Your daughter Sally's coming marriage, your business in Medford. He can even brand your whole life as a masquerade.  Jack Foley, my old classmate. And I'm not mistaken. I've been very careful, Jack. My name is Wilson. Arthur Wilson. Sure. And mine's Jameson. Now it is. Used to be Sanders. Remember me? Three cells down from him. Same section. Number 34192. I don't know what you're talking about. I've lived in Medford, Oregon for a quarter of a century. I never heard of you. Oh, come now, Foley. Put on your thinking care. My name is Wilson. I never saw you before. I would have contrasted in memory. Boy, I recognized you instantly. But it's understandable. I was a very young man. And you only knew me a short time. You left us rather suddenly, Jack. Stop calling me that. Sorry, sir. That better?  Lucky Jack Foley. Now Arthur Wilson. Successful businessman. His daughter about to marry into one of the best families in the state. What are you after? The memory's getting better, isn't it? What is it? What are you after? Is this some sort of blackmail pitch you're giving me? Now, you know, that's an interesting thought. It might be, if I were the man you think I am. The man I know you are. How long have you worked here, Jameson? Or Sanders, if you prefer. Six months or so? You must be out of your mind. Do you think for one and that the Mrs. Franklin or anyone else would take your word for it? No, sir. Certainly not. Then what are you driving at? Why all these ridiculous suggestions, Jameson? Sir, I have what is known in the trades as a black on white. Surely you remember Professor Slips Dolan, Dean of Forgery. He was in another section, but in the apartment just below. I'm getting tired of this, Jameson. Great man, Professor Dolan. Any written document was a black on white. I, um, have such a document. Regarding Foley? Regarding you, sir. Yes. The light's very good out here. I'll show it to you. Just remember the light's also too good for you to start anything. You seem to think of everything. Take a look at this and you'll really think so, sir. Yeah. The letterhead will convince you, I think. Look at it. Bureau of Identification, Washington, D.C. Department of Fingerprints. The Bureau of Identification sent my fingerprints to you. Oh, no, sir. It was the other way around. I sent your fingerprints to them. But... It was quite simple. My training, you know. I'm sure that as a hardware merchant, you were grateful, shall I say, to our armamater for your work in the machine shop. I've used my training and photography to advantage many times. Taking fingerprints is a very simple process. Hold on, James. Where did you get my fingerprints? Oh, they're all over the house, sir. Naturally, as a servant, anxious to please, I'd go all over the house. I picked up your prints the first night you were here. Water glass, wine glass, night fork. Then I sent the photographs off to Washington. It's incredible. But true, huh? The answer here arrived this morning. The fingerprints of Jack Foley escaped convict, and Mr. Arthur Wilson hardware merchant are exactly the same. Amazing coincidence, don't you think? What are you going to do? It's a question of what you're going to do, Jack. For me. Call me Wilson, Arthur Wilson. Gladly, Mr. Wilson. You'll cooperate then? My daughter is getting married in four days.  Oh, I'm very common as a blackmailer. I want money. Twenty thousand? Twenty thousand dollars? You might as well ask for a million. I haven't had more than two or three thousand dollars in the past two years. Oh, come now, a prosperous hardware merchant. I don't even own the store, Jameson. Most of the stock is on consignment. You'll have to sell things much faster than you ever did, won't you, old chap? I can't raise that much money, Jameson. Now, I'm the one who's getting tired. You'll raise it Foley every dime, no more, no less, and I want it by Tuesday at four o'clock. Two days? That's impossible. What am I going to do? I'm going to the police. You're right ahead, and I'll go to Mrs. Franklin with this letter. That'll wreck both our futures. Then I, uh, I haven't got my daughter's happiness to worry about. Tuesday at four, sir? I've got to have a chance to think, at least. Certainly, sir. As I suggested, put on your thinking cap. Good evening. Pleasant chats. Very pleasant chats. There it is, Arthur. I understand that places your future in your daughter's happiness squarely on the block. It's all over if you don't meet Jameson's request for the money. And you haven't the slightest idea where you're going to get it, even part of it. But you have to try. The next morning from a booth in a neighborhood drug store, you put through a call to Walter Reynolds, president of the Medford Grain Exchange Bank. Hello, Walter. This is Arthur Wilson. Something's come up. Well, I can't go into details over the phone, but, uh, I've got to raise some money. Certainly, Arthur. It's an unusual amount, but when I... I'm sure we can take care of it, Arthur. We'll be glad to credit your account with a couple of thousand. Well, it's more than that. I need twenty thousand, Walter. I know it's a great deal, and I... Well, I figured that banking with you for over twenty years meant something. It does, Arthur. Of course, I just agreed to a couple of thousand, but my personal endorsement would make it five thousand. Five... five thousand? Is that better? I'll wire it to you down there if you have the interstate trust and savings. Five thousand. All right, then. Thanks, Walter. Thanks a lot. It doesn't mean much, does it?  Jameson said twenty thousand. And you know that's his price for delivering you the letter from the Bureau of Identification that will bring your past to light. You put through another call to your closest friend, Ward Weston, only to discover that he's away on business and can't be reached. It's sixty-five hundred or nothing, isn't it? And the next morning, returning from the interstate trust bank, you tell yourself that you're going to get that letter. Later, you're nervous and trembling as you face Jameson in the library. You brought the money, have you? Look, Jameson, give me a break. Will you if you only realize... The money for him, or I'll start talking. You can't. You can't do that. Can't I? Sally, her happiness. You can't do this, Jameson. It would ruin everything for her. I understand, Foley. I really wouldn't want that to happen. And it won't, as long as you hand over twenty thousand. Well... I wasn't able to get it. You weren't able to... All right. How much did you get? Sixty-five hundred. Sixty-five hundred? Well, that's absurd, Foley. Not even half what I asked. Keep your voice down and stop calling me Foley. Oh, I should have told you. We're practically alone. We went down town. Stephen's out with your daughter.  I want that letter. Now, don't get impulsive.  A gun? What's that for? Detection. I know I'll have brought you... a temper, your sudden way of doing things. They put you in jail, got you out. I don't want anything to...  That gives me an idea. All right, my old classmate. Drop it. Drop the gun. Drop it. Break my arm. Well, Arthur, after all these years, you've done it again, haven't you? You stand over in the rage, slipping away into fear. You didn't try to kill Jameson, but you could never prove it if you were found here.  The letter. You must get that letter. You stoop down, rummage through his pockets, and then turn the start out of the room. That's when you realize what Jameson meant when he said you were practically alone. There's a frightened girl standing there, killed of the maid. Her eyes wide, moving back and forth from you to the silent figure on the floor. No, Hilda. It was an accident. You've got to believe me. I saw it from the hall, with my own eyes. It was self-defense. I had to do it, Hilda. You've got to tell them that. The door. Someone's at the door. That's a stall, Hilda. Try to send them away. I've got to have time to think this off. I'd like to see Mr. Jameson, please. I am from police headquarters. Mr. Jameson? He's Mr. Wilson. That's Mr. Jameson on the floor. He's dead? Yes. Mr. Wilson there just killed him. I saw it with my own eyes. I did. Well, what do you know? I come to pick up a blackmailer and catch a killer right in the act. He stole a letter from Mr. Jameson's inside pocket. I saw him when he'd done it, with my own eyes. Let's have it, Wilson. Bureau of Identification, Washington, D.C. This letter must have meant a lot to you, Wilson. Come on. Let's go. The Whistler will return in just a moment with a strange ending to tonight's story. Meantime, two points. It'll pay every driver to remember if you want to be sure of the tops in quality when you buy gasoline. One. In gasoline, it takes extra quality to go farther. And two. Well, is the famous Go Farther Gasoline? Yes, it's a fact. Mileage is the best yardstick of gasoline quality. After all, there's only one way any gasoline can give you quicker starting, faster pickup, and smoother power. That's by helping your motor run more efficiently. And when your motor runs more efficiently, naturally you see proof of it on your speedometer. In Mileage, the very thing Signal Gasoline is famous for. That's why we're so proud of Signal's Good Mileage, which has made Signal Gasoline known from Canada to Mexico as the Go Farther Gasoline. And it's why we say to be sure of the tops in gasoline quality, there are just two things to remember. One. In gasoline, it takes extra quality to go farther. And two. Signal is the famous Go Farther Gasoline. Now back to the Whistler. Well, it's all over, isn't it, Arthur? Your long years of living a double life, the end of the masquerade is Arthur Wilson, the name you took up some 25 years ago when under your real name, Jack Foley, you escaped from prison. And now, in a sudden moment of blind rage, you tried to disarm the butler, Jameson, who had known you in prison, a man who was blackmailing you, threatening to expose your almost forgotten past, and the struggle for the gun had ended with an explosion. And death. After a sleepless night in your cell, you're taken to the office of District Attorney Grant. Your one thought is for Sally. Yes, your daughter's approaching marriage means more to you than any punishment which the District Attorney might have in mind for you. As he faces you across the table, you barely understand his words. You're thinking only of protecting Sally and her future happiness. I sympathize with you, Mr. Wilson. Blackmail's a dirty business. But you should have let us handle it. The minute Jameson or Sanders wrote that letter to the FBI, it was all over for him. For him? That's right. Those boys down there never overlook a bet. Any time they get a suspicious communication, they look into it. In this case, they naturally examine Sanders' note for fingerprints. His prints were in a dozen different spots. Sanders' prints? Sure. On both the letter and the envelope, he mailed it in. From there on, it was a cinch. We've been looking for Sanders for a long time. When the bureau tipped us off that the butler Jameson was Sanders, I sent one of my boys out to pick him up. If you waited a few minutes, he'd been out of your hair. You should have come straight to us, Wilson. I can see that now. Mr. Graham, could you keep this out of the papers? Keep my name covered for a couple of days until after my daughter's wedding, then I'll play any hand you deal. Your daughter's wedding? Yes. Being married? Oh, yes. I guess you haven't seen the morning papers. Your daughter eloped to Las Vegas, Nevada, with young Franklin yesterday afternoon. Yesterday afternoon? Yeah.  Seems the kids didn't want all the father, all of a big wedding, and just took things into their own hands. Married. That's wonderful. Wait, does Mrs. Franklin know about me? My pastor? Oh, yes. She's retained her personal attorney to represent you. She's sure it was an accident. And Sally and Stephen. She's satisfied? She's quite happy. Thinks your daughter's a great girl. Too bad you've always been so impulsive, Wilson. You'd have been a lot better off you'd have come to us right away, even if it meant finishing your jail sentence. I know. But I just had to have that letter to Jameson from the Bureau of Identification. My daughter's happened. You... didn't read that letter, did you? No, your man took it before I had a chance. Take a look at it. Dear Mr. Jameson, regarding the fingerprint photos accompanying your inquiry as to the further identity of one Arthur Wilson, please be advised that information of this kind is available only to duly authorized agencies for the enforcement of the law. Let that whistle be your signal for the signal oil program of Whistler. Each Sunday night at the same time. Brought to you by the Signal Oil Company, marketers of signal gasoline and motor oil, and fine quality automotive accessories. Signal has asked me to remind you to get the most driving pleasure, drive at sensible speeds, be courteous, and obey traffic regulations. It may save a life, possibly your own. Featured in tonight's story were Ed Begley and Tom Collins. The Whistler was produced and directed by George W. Allen, with story by Edward Bloodworth, and music by Wilbur Hatch, and was transmitted to our troops overseas by the Armed Forces Radio Service. Remember at the same time next Sunday, another strange tale by the Whistler. This is Marvin Miller speaking. This is CBS, the Columbia Broadcasting System.


Why are we at Ilri so actively engaged with international water management and with many other regional and national partners on this issue? Traditionally when people think about water management, they think about irrigation and they think about crops. If much, they think about fodder crops. If you look at the literature, livestock systems are being challenged about their efficiency in the use of natural resources, climate change implications and so a few years ago, their first numbers being distributed. We're talking about 100,000 liters of water needed to produce a kilo of beef. These were estimates produced in the Midwest under feedlot conditions with irrigated alfalfa. Now if you look at this part of the world, the Nile basin, livestock are very important element of the farming systems. Obviously the issue of understanding how grazing management, how they use of crop byproducts, how water health, human health issues are impacted by livestock management seemed a very important area of research if we're looking at water management in a comprehensive manner in these watersheds. Let me briefly sum up some of the history of Ilri's interaction with EME, the Challenge Program and a number of partners. This whole development started about 2001 when we started to look at these interactions in the framework of the first phase of the Challenge Program for Water and Food. In 2002 actually of this campus, we had a key workshop with staff from the Ministry of Water and the Ministry of Agriculture and a number of other partners. And this led to an initial agenda on what were the issues, lots of work to place and we I think downloaded a lot of that in this famous document, the comprehensive assessment on water and agriculture, which really brought together a lot of work from many of the partners. Over the years, many projects were undertaken, lots of activities led to new insights and this is very much sort of the stock we're using in this new program. But we also, I think, engaged very actively in capacity building. Many young people did masters, PhDs, postdocs around these issues. That all led to a very productive scientific environment and that was presented to the world, if you want, in 2008 at the second International Forum on Water and Food, organized by the Water and Food Challenge Program here in Addis Ababa, which was, I think, a very very successful stock-taking exercise. I would like to put this new program a bit in context for the CJER in the CJR reform. The type of science which you are going to embark here very much aligns with the efforts to reform the CJR in the direction of producing much more integrative science, addressing complex problems related to poverty, food security, and particularly also sustainable use of natural resources, in this case, water. Ideally, we've been moving in this direction for a number of years. I think we have a tradition of strong systems work, because we realize that livestock is intimately related in most of the poor farmer systems with crops, with natural resources, etc. So crop livestock integration has been a key thrust for us. We absolutely go beyond technology. We recognize the intimate interaction between technology, policy, institutions, and we've moved from just addressing science issues to thinking about innovation, and as a corollary of that, we've engaged in complex partnerships with development partners. Water management, particularly the case of the Blue Nile, fits very much that type of problems which CG wants to contribute to. Mixed crop livestock systems are at the core of the watershed. Livestock are very important, particularly all of you from Ethiopia. I think are very aware of that. We're talking mainly about rain-fed systems. And particularly livestock has a key role to play in the management of the upper watersheds. Issues of water infiltration are very much related to livestock grazing and civil management practices. So as you can see, water and livestock are very close concepts that need to be looked in an integrated manner. I'd like to share with you a few lessons which we have learned at ILRI over the past years in dealing with these types of projects. Maybe some of them might be useful in this context. As I said before, the issue is not just one of technologies. Very much an issue of understanding policies, institutions, and investments. We have learned that gender is absolutely critical to understand household behavior in response to many of these interventions. We frequently hear that NRM interventions are considered location-specific and that this really is a challenge. So frequently they are stated to be of limited impact and not comparable, for example, with plant breeding. So I think this program would have to put a particular effort to have good baselines and good impact studies because that's going to sell this type of science. I think one of the lessons we have learned in a hard way is that you really have to go beyond the diagnostics and small-scale pilots. We need to identify drivers of change and key tipping points. This is absolutely critical to be effective in our investments. We can spend enormous amounts of time and money in characterizing systems, but if something is to change, we need to identify these key drivers and tipping points. Let me give you a few thoughts on how we're trying to do that. Computer modeling and simulation have clear roles to play, as has action research on the ground. And finally, a lot of it is serendipity. But that serendipity feeds on the previous two edge of the simulation, the modeling, and the action research. But furthermore, that serendipity requires an open mind to look at new issues, unbiased, avoiding the usual sort of confirmation bias we frequently have in our science, and accepting surprises, not expected results, in a very open-minded way. I think here, both SIDERS frequently can play a very important role because they have different experiences. This is very much what we have learned in the CJR, that one of our contributions is that, being international, we have seen many of these systems in different environments, under different conditions around the globe, and that gives us an opportunity to think maybe out of the box in terms of many of the things we find in a specific watershed. I think one of the important angles of this program is the fact that it explicitly addresses the problem at a range of different levels. And this, we know from system science, is absolutely critical. If you want to understand the system, you need to look at the nested system within. Here, we will be looking at individual plots, at farms and households, at watersheds, at the regional level, at the value chains. This is very good, but the real challenge is to see how you bring these different perspectives to interact and to talk to each other, and to fertilize the thinking, the mutual thinking. And here, I think in this program, we'll have a key role in this. Communications, knowledge management are absolutely critical to really add value to these analyses at the different levels. I think at ILRI, we can certainly contribute some of our recent experiences. I think we have a very strong team based at this campus working on knowledge management and information. But in the end, it all has to lead to impact at scale. And that means that it's not just a researcher's job. This requires strong alignment with other development partners. And this is why I understand many of you are joining us this morning. It requires an attitude of stewardship of issues. And what really I think is the most challenging part, NRM requires changes in mindsets, in mindsets of policymakers, in mindsets of farmers. I think over the years, we have learned that that is one of the biggest challenges. And I think social marketing, for example, as is being done in health programs on HIV-AIDS and many others, probably has a lot of lessons we need to learn when we want to bring about change in natural resource management. So I think we will have to address and learn about those issues as we go. So this program will be working in the Blue Nile watershed, but I would really like to stress that if successful, this can have very important downstream contributions to the region. And more broadly, I think we are all aware that water is going to be one of the major sources of regional conflicts. And this region has quite a few of those. So we can help diffuse some of those conflicts that will be a very welcome impact of this program. And I think we have quite a bit of evidence that there is value in what's called sort of science diplomacy, getting scientists from different countries to work together, learn about the issues, and learn about how to deal with the trade-offs. Because most of these conflicts will have to be addressed by handling the trade-offs between different interest values, etc. Again here, I think the CGR has a clear role to play. We are an international body, we act as neutral facilitators, and we have scientific credibility. I think this enables us to facilitate a lot of these dialogues. Thank you very much.