Duration 35:31
16+
Play
Video

Meet the Authors – Go Language (Cloud Next '19)

Tyler Bui-Palsulich
Software Engineer at Google
+ 5 speakers
  • Video
  • Table of contents
  • Video
Google Cloud Next 2019
April 9, 2019, San Francisco, United States
Google Cloud Next 2019
Video
Meet the Authors – Go Language (Cloud Next '19)
Available
In cart
Free
Free
Free
Free
Free
Free
Add to favorites
25.21 K
I like 0
I dislike 0
Available
In cart
Free
Free
Free
Free
Free
Free
  • Description
  • Transcript
  • Discussion

About speakers

Tyler Bui-Palsulich
Software Engineer at Google
Megan Sanicki
Sr. Program Manager, Open Source Strategy at Google
Brad Fitzpatrick
Участник команды Go at Google
Robert Griesemer
Software Engineer at Google
Ian Taylor
Principal Engineer at Google
Robert van Gent
Software Engineer at Google

Tyler is a Developer Programs Engineer at Google. He graduated with his Master's in Computer Science from NYU and loves detailed documentation, random trivia, and homemade bread.

View the profile

I turn dreams into reality and deliver impact by blending business strategy, creativity, analysis, problem solving and team work. My main strength is to take organizations to the next level.Key strengths:- Business strategy transformation and change management- Solving hard problems with analytics and creative solutions- Delivering results with strategic planning and strong execution- Financial turnaround- Strong emotional leadership of board, staff, community, and customers- Scaling businesses through customer and partner centric approach- Creating impact by building and leading diverse teams- Cross trained in business development, sales, marketing, communications, operations

View the profile

Участник команды Go, автор многих сетевых пакетов стандартной библиотеки. Предыдущие творения: LiveJournal, OpenID, memcached.

View the profile

Robert Griesemer is a member of the Go Team, and one of the designers of the Go programming language. He is the primary author of gofmt, the first version of godoc, and several Go standard library packages. In the past, Robert has worked on code generation for Google's V8 JavaScript engine, and the domain-specific language Sawzall. He is also one of the original authors of the Java HotSpot VM.

View the profile

Ian Lance Taylor has been writing free software since 1990 and Go since 2008. He is a member of the Go team. He is the primary author of the Go frontend for GCC, the gold linker, and Taylor UUCP.

View the profile

Robert van Gent is a member of the Go team. He works on the Go Cloud Development Kit open source project (https://github.com/google/go-cloud), a library and tools for open Cloud development in Go.

View the profile

About the talk

First come first serve
Go is an open source language that enables the production of simple, efficient, and reliable software at scale. Designed by Google for cloud workloads, Docker, Kubernetes, Istio, and gVisor are all implemented in Go. With great built-in concurrency (ideal for cloud services), a best-in-class networking stack, and excellent tools for developers & operators it’s become one of the fastest growing & most loved languages. Meet the minds behind the Go language and participate in our interactive panel.

Share

Is Megan stanicky? I'm an open for a strategist for a Google cloud and I am really excited to be here to where you can meet the authors of go and so why don't I first introduce introduce themselves to you? Hi, my name is Ian Taylor. I've been working on go since 2008 before it became public. I'm a Google employee and I work on the tools and the libraries and many other things. My name is Robert. I am not actually one of the inventors of go but I started programming go about 5 years ago that working on machine management tools inside Google machine management applications

from python to go and I joined the go team last year. And since then I've Been Working On The Go Cloud development kit set of tools for making Cloud application and go awesome. Hi, I'm Robert reason. I've been with the go team since 2007 when he first started which is like 12 years ago, which seems like crazy all the time. I've read a bunch of tools that I'm afraid of you guys might be using like go fund. So if you're not happy with that, you can complain with me may not help though and more recently. I've been working on trying to get

go into that go to face. I am a breakfast Patrick. I've been working on go since 2010 and I work on the standard Library Lots things like I'd HTTP packages and the build system. I wrote like going parts to a lots of Low Places. Hi, my name is Tyler. Buie pile cilek. I work on go on Google Cloud. So my goal is to make it as easy as possible to use go with and on gcp so it's kind of like Robert said if you have problems with going gcp you can maybe be annoyed of me. I might help.

The panelists and I just want to get a sense for the room before we get going. Can you raise your hand if you would never used before? All right. Well welcome. We're excited to start teaching you more about go. Can you raise your hand if you've started using it a little bit? All right, and then raise your hand if you're using it a lot. Alright, excellent. We love that answers for each states that you're in and as I mentioned before this is going to be interactive. We have some questions that I'm going to ask that have come in,

but we also got to take questions from the audience. So if you do have a question, you can just start making your way down to the sides. Both of these team members are going to have microphones. Will you could ask your questions you can just queue up. Okay. So why don't we just get started with a nice easy one to tell me what is go Fest at doing what are all great ways that you should be using go. What's good for everything? Of course? It's very good for a cloud. It's a simple language. It's

easy to write code. It's easy to write go that runs very efficiently. It's easy to write code that runs very concurrently. A lot of the core infrastructure of the cloud is written go Itself by kubernetes with an easy example and I mean, yeah, it's it's well design for web servers good for a lot of things. Great. I think I'll see when I added where you've been seeing go being used really well sensitive in the scale of Google's machines was just getting so large that python wasn't working anymore and go was with release date for a freaking currency and also purchase

managing a large application having a type c language. It's all a lot easier to manage than than Iceland. Something never hear a lot from people is how easy it is to learn go. So it's probably not an exaggeration that if you know how to program within a week you can be productive in go. A minute. It's been a number of years since I was like super religious about go but at the time I was always telling people how I hated the trade-offs of all the other programming languages were like if you wanted to write performance, you know sensitive code you would have the right

kind of a tedious language and if you want to write like in a fun language, then you would have to deal with bad concurrency your lots of and I'll call backs or bad performance or like, you know, run time until you're still like you're missing type information and so is really nice to write in a language that was both fun and fast and that you like let you get going and write code right away. So I'm still kind of in love with it and I haven't found anything that's as fun and like this productive. Right. Now one more one other thing I'll call out is part of

one of her one of the goals of Designing go was to make it easy to develop in large teams over a large amount of time or long enough time so stuff like go from Two and go Imports and kind of standardizing the language and how it's used makes it so that when you're looking to go code in one spot made by one person looks very similar and hopefully easy to understand as go code. You've seen somewhere else. Good snow. Do we have any other questions from the audience just to remind you to come down and go on over? Hi, my name is Pablo. I have a

question for you. What do you think about the basil uses them for you? Where do I think about the basil built system for going? I think I think it's very good for complicated programs. I mean go go come with its own build system in the sense that it's easy to build pure go programs with the tools that are provided by go. But if you want it work on a multi-language program with many different parts. Also if you want to deal with a lot of generator code then I think

basil works really effectively. It does have full support for go these days and I mean lots of people use it we use it internally Google's internal version of it. So, yeah, it's a good system you say it has full support but there's a lot of things in like xtools like the package loader and stuff. That's kind of like in development like a lot of a lot of the tools That existing to go ecosystem kind of historically assumed that you laid out your code on disc the way that goes built-in build system works and said there's an increasing amount of work

recently about making our tools diagnostic about whether you're using basilar. You're using the go tool getting better like only there last year. another question coming in I didn't do what Tyler was talking about the benefits of go or what is what is good for I feel it's very good for collaborative development where you can it's so easy to report. Somebody else's keep helping people and their libraries and Cobra is something that almost everybody who might have used that starts. One

thing that I wanted to kind of point out. The other specific question that I had was of importing like commonly used guitar proposed into the standard Library. On the contrary we want to get rid of things in the standard Library. We even have a fact entry about it right now in the standard Library just because initially there was no like go get Enzo if we wanted to put some code somewhere. It had to be in the Central Library Miller used to be like a space Wars game. There was an

ntp like using that client. There was there was like tons of crap in the Central Library in right before we go on we deleted a ton of it and we forgot to delete like even more of it. So there's a lot of things that are in there. They're kind of an accident and like we didn't have a internal packages or like like private packages of there's a lot of crap that's in there are just for like DLS that's only public because of a CDP and so there's a whole lot of like low-level crypto networking details that are like we wouldn't really want to expose on their own. We might want them to live on

GitHub or something anyway, so I don't I don't think the trend is to like put more stuff in the standard Library. It's really to make it smaller and more modular. But I want to add to that with the go modules work that's going on actively and go right now. We're making it much easier for a program to pull in a reliably determine said sources from an external library and we're also developing better module Discovery and packaged Discovery tools so that people will be able to find the packages that they want and also have a way of knowing that these are packages that a lot of

other people years and are therefore highly reliable. It's tempting to move everything into the standard library, but it doesn't solve the problem if we could actually maintainer for the go team is not particularly large and so we don't want to put something in the standard Library which we can't take care of ourselves. But what we do instead want to make it possible is that you can build your program and know that you're pulling in libraries written in maintained by the people that you know or high-quality because other people. For them, that's the direction we want to move in. That's

great. Okay, we have another question over here me about 10 years ago as well as we will allow me about 10 years ago and but from my point of view support to go in Google cloud and Google app engine flexible environment still looks and sufficient from my point of view. Are you guys prefer Java? Yeah, I think this is something that we really tried to improve in the last couple of years. So a couple things that are new are app engine standard second gen run times like this idea applies for all of the app engine supported languages, but specifically for go

if you ever used a standard before and you had to import appengine, like anyone raise your hand used a couple people. So now you can use whatever Library you want kind of before one of the issues that would come up if you had to use a special package to make HTTP request. So you run your service on a pension you need to make some API call. You can't HughesNet HTTP you need to use URL fetch which was this other package that we maintain latest version of go. That's not something you need to do anymore much much nicer used and that's all based on that same

technology was used for And so we released Cloud functions support for go about a year ago. I want to say starting with an alpha and beta and go 111 for cloud functions just went to GA. So those are some of the ways that we've tried to improve support and then the one other way to run your code is cloud run and not so you can run whatever language you want whatever language version you want. And as long as you're using the cloud plan libraries, hopefully that's nice experience. And then you

mentioned a pension flex but you said it's similar to app engine standard. You can also provide your own container images that you want to run it will scale up for you, but it has a minimum instant count of 101 of steps the default level and then if you're comparing that to Cloud run, which so how many people saw that announcement is in the keynote today. See you to find whatever container Emoji one and I can bundle whatever Go version you want and I'm not scales up and down really quickly. If you deploy it literally takes a few seconds.

It's really really nice. So we're working on it. I hope it's much better than it was say three five years ago. And I I wanted to put in a plug for my project to go Cloud development kit another open source project and we're trying to make go a great language for developing Cloud applications not to not just on TCP but on any Cloud including on pram for running on your local box. So we've developed a bunch of portable apis for cloud services, like blob or pubsub things like that. And then we have limitations for different cloud provider. So you right here

at once using are apis native go apis, and then you kind of plug-in with simple config or initialization time changes, you plug-in whatever implementation you want. If you want to run locally on your box to use that implementation if you want to run on Amazon you plug in at 3 or SNS for Pub sub and so that way you sort of have fun and good development workflow. Anything else bad? If not, would you have a question coming in? I just have a question with regards to webassembly. What is the roadmap for you know integrating go with webassembly is will there be one day where

we can do away with JavaScript if you have go replace it, so I hope so but none of us are really doing the back and go team that are reviewing it but it's mostly done from external contributions. There was just a change that landed at made it smaller and faster doubt, but Say what the status is today is today is the day program for webassembly and you could run it going, you know, alongside nodejs stuff or you can run in the browser and there's kind of a ecosystem of kind of UI framework stuff. So you can write a front-end web

apps and you can you can write it all today without any JavaScript at all. So, you know, it's Nathan, but it's it's coming along. And actually I just want to see if we're hearing a little bit through these questions. What's new with modules and other aspects functions. Could you just tell us I can one big Arkin story? What is new with a lot happening? I can talk a little bit about the changes to the language. So until the most recent release to 112. We have made almost no changes to the language

after an initial phase Rubbermaid small minor changes. So for the last couple of years, we basically have Frozen to language, even when it comes to Smart small Minor Adjustments that would have been fully backwards compatible. But now we're trying to move forward towards what we call set of go to and as part of this process we started to look at the incoming proposals that they come from the open source community and beer review review them and the identify the ones that seemed promising and so for 1:13, for instance. We have started making the first significant change it to

Lambert's an hour you will have with 113. Assuming we're going to actually say yes. If you are very end of the development cycle of binary literals is going to be hexadecimal floating-point numbers. Another thing is we can do now she keeps without non-constant Chiefs without Yuan conversion, which is probably going to clean up a lot of code and that's what liberals can have on the bar. So if you have a very long numbers you can have no underscores in there to space them out apparently something that people really want it and

there's probably going to be some changes to the libraries we try Probably not have the best. I love you at the moment. I was going to add that all these language changes that are coming or kind of like warm up one's for us to work on the process. So they're they're kind of boring and they're kind of small. But if we're going to do a couple additions to the language we're going to do a couple removals to the language and then I'll get practice with that process. There's a couple of constructs in the language that we would like to maybe remove and so modules with you specify on the

granularity of a module what language version semantics you want. So if you say like you're targeting go 112, we can remove something and go with 13 as long as your module spell declares 112. Language feature exists, but once you want some like new feature and go 114, and you say that then you lose the features that we were moved until 1:13. So let's just like slowly evolved the language without breaking any one so they may not actually be a go to ever do we say go to as in like new stuff, but it may just be that like a note generics or something fun lands in my go 170. NM so keep that

in mind whenever we could go to it's probably more of a marketing expression than actually a thing. And just so I call out the three main things being looked at by the team for go to our dependency management. So modules are The Go Solution to that came out starting in 111. Now I got in 112 and then hopefully on by default in 113 and then the others are errors and generics so errors the gold Air is to make it easier to develop and respond to and check errors. And then that's when

generics of basically deciding should we include them? Should we not if we do in what form? Great. Thank you. I think we have a question how few features it has. Which could you give an example of a feature in another language that you really like? That wouldn't make sense in God? Are the Goodwin you get a plushie? Will C. Plus plus for example is a very complex language but it has a number of features that are very nice. IFrogz Apple in C plus plus yocan template eyes based on a constant and use that to compile different versions of your code

based on Concepts that are passed into the template and you can combine that with variadic templates. So you can actually redesign your data structures based on how the temp what is expanded to make that more or less efficient depending on the exact features you need from it is. You can actually change how much memory requires at compile time. So that's a cool feature and I've used that picture myself when I've written in C plus plus in the past, but the complexity of understanding how that feature really works. I don't think it's appropriate for language like oh which is designed

to be, you know, as Robert said earlier. It's a language you can learn very quickly. If you're familiar with all the programming languages languages start with we don't want pictures like that. I think Hang out, but it's a great question though. And in general go tries to give you like 80% of what you want with like 20% at the complexity. Does he know every time you try to solve a little bit more get closer to 100% of what you want the complexities ramps up like way faster than they what you're delivering. There's one feature that's relatively easy to understand I think which is

macros which go doesn't have but you know, there's plenty of times when I really really really wanted to just buy the macro what the problem with the macro is, is it possible to ride code that's almost indecipherable afterwards. So it's easy, you know, it's the right ones understand never it's that definitely is not part of the language that we don't want to have any language because we put a lot of emphasis on readability of go because code in our experiences red much more often than written. And so that's a that's a valuable feature to maintain

Great. I think we have another question coming in. Yeah, so go is about 13 years old now so you can come in a little bit about what were the motivations that drove you to develop go 10 years ago and are these driver still got it today? This is a question. That's been Angel many times on the web. But let me assure that Google there's a lot of coffee with my Google and some of us really felt like at that time. The choice of programming languages was somewhat unsatisfactory. So we were somewhat stuck between a rock and a hard place. He's a real some people call

it job on C plus plus but it's a strong desire to have something better coming up with. Something that felt like a much better solution at that time to the kind of systems programming that we wanted to do because it seemed that a lot of the problems. We're actually solved many many years maybe decades before but we're not actually solved in programming language of several available at that time. And so I think a lot of those things are still may be a little bit

less true today because there's actually a wide variety of languages but when it comes to things like, I'm currently I think I always feel like way in the Forefront. I don't know of any other language but it's so easy to ride concurrent code in terms of compactness. I think Joe is still extremely small language and very easy to you. No grass and understand I think many of these things are still valid and of course, there's languages Ultra Compact and then small and clean but he's also very efficient and I think that's still true. I mean, we're still maybe not at CRC for past

level, but we are close enough for you know, 99% of all applications. I want also eluded something the Tyler mentioned earlier, which is that goes the language was designed for as much as possible for programming in the large for many people working together on one program in a lot of decisions about the language were made with that in mind. You know how well we succeeded at it. I'm not sure but I think it was an important goal at the time and I think it's even more important now especially is open source

is continue to get larger and larger and larger languages that help people work in larger groups. I think it's very important goal for modern languages on I think has aimed for that all along. Anything else? Okay why I know we have a very patient person over here who's going to ask a question? One of the things I really enjoyed about Joe is the community and I'm wondering how y'all stay engaged with the community in health field that especially in the face of contentious decisions are changing the language. Answer the question is about the community and how we

will how we work with it. I guess the community forego has been has been incredible. We've had so much support from you know, from all of you from people all around the world working and going contributing to go and then you ask them. How do we deal with contentious decisions? I think we try to I think we try to be as open as possible about how we're making our decision to completely open about why we're deciding the way we're deciding and make you think so contentious of times.

There are disagreements in the community, of course there been disagreements in the past and we listen to them. I mean an easy example is for the product, you know, the language added a future type aliases maybe 3-4 years ago and before Taipei leases were introduced. We actually had a separate proposal which was a different kind of proposal and we designed it Robert and I both worked on it and other people live in Google we put it out there saying this is something we think will be useful to be that kind of language. You know, it's a lot of pushback in the

community. It did become contagious and I think we tried as hard as we can code to listen to it. We withdrew The Proposal we put out a smaller and simpler. Puzzle which bit and then get out of the language also explain, you know, they use cases for it. And so I think it's been a learning process for all of us to work with the community. But I feel like you know the answer really it's just to be just to be open to explain why were thinking what we thinking we can't take every idea to comes in. We don't agree with every idea that comes in ultimately. You know, what small

group of people is going to make the very final decisions about what's going to happen, but still most of the best ideas are coming from outside. So yeah. Great, you know if it's important. either the number to take a question on this side. Hi, so you guys are great at keeping stuff backwards compatible. But if you go if you could go tomorrow to work and just change something completely without thinking about it. What would that be? Why so if you can go back all

the way to the beginning of go the original go look very very different than the one that we have now and in the early days, we had the luxury to actually make a lot of changes since the very first version of call you have to ride semicolons and now you don't have to write them anymore. Actually, you know for last 10 years if you have to write them and there's a whole bunch of things that you probably would like to remove some of which we can remove right. Now one of them again, a simple example is a right now you can convert it. You can say string off an integer and

that gives you the corresponding. It doesn't give you a string version of that integer value. It keeps to the corresponding Unicode code Point as a strength for the thing that's very confusing it that that was there just for a reason because it was convenient in the beginning at the something you want to ride I want to take out but you can't because it would break potentially things and there's a lot of my head at the moment. Ranging over a string giving you the utf-8 code points rather than the bites of the strain which is inconsistent with the slice of buy it. It seems

like when you do a arrange Loop and you want to capture you have a closure that captures one of the variables the variable stars like the same variable for the whole Loop rather than every iteration of the loop. So you can't safely started go routine with a closure in the middle Ballou that bites a lot of people. So there's a lot of little things that you know, we realized after the fact that we can't really change it. how to get rid of return statements that don't list the values that are being returned From the beginning we tried to make go

really platform-independent. And so most of the language is actually part for me to get it. You can write some code and you can run it on any platform about some basic things like the internship type in or you ain't they are platform dependent, you know, if you were running on a 32b platform e you get a 32-bit in and you can running on a 64-bit flight from your running regarding potential or 64-bit in maybe maybe a 32b then so that's actually something that I think in retrospect was probably a mistake because if you actually move from one iPhone to

another you might incur problems or you may have to change code and things like that. So be nice if we had a better solution for that than one approach could be your contact being maybe that anything is arbitrary size and you never have to worry about it. That's something that would be much much much much farther. I have a few minutes left. So we got a few questions to ask you enough. So if we can go quickly. Answer somewhere else is really quickly. What would you say has been the biggest challenge

and creating go where does the programming language in general? Is it the intricate technicalities or is it an understanding user behavior in creating something to adapt to user Behavior? So what's been the biggest challenge and go I'd say that for me at least the biggest challenge is keeping it simple. It's always so easy to add another feature and you can see so clearly how useful it would be to have this new facility in the language. But if we had every new facility in the language, then we got something so complicated that is very

difficult to use like an existing languages today. And so I'd say the biggest challenge has been to say no. Good, okay over here. I read Outlook. Both of them are now in Google admonitory two party contacts in the first argument and every time champ first of all, I want to know what do you think about it? I don't think we'll be removed in go to or something. I don't know if there are no plans to remove context if anything will become more pervasive. And what about it or passing the context in the first argument? Do you think everybody should do it outside Google? Yeah, probably

Google A lot of it was kind of implicit with a like magic threadlocal stuff. And so it was kind of great when it works because your contacts was threaded through automatically because all all functions just kind of picked it up from Fred local storage. But once you start to do something tricky lot of people didn't know how to stitch together threads their context and they wouldn't even know that they didn't do it until they had a production problem and they went to look at like the the the global Trace dashboard and then they noticed that none of their stuff was stitched

together properly. So if you make it explicit, you get it right from the beginning. So when you have a production problem if you know, it's usable the traces. And as far as whether the context of the first argument or not, it's convenient to have it be the first argument. This just makes the color P stylistically consistent, but I don't have any meaning beyond that. It just helps at the code books similar and different parts of Google one thing I'd like to do is maybe make contacts. Contacts be less stedry. Cuz right now you write in a CTX and so if you're reading it, it's like contacts

contacts. Contacts. And if right now we have one built in type in the language of the one building interface type, which is error, which is just an alias, you know for anything with an error string method sew the first class to be contacts contacts through something. Okay, so when we get scared I couldn't get one maybe two questions and we'll start on this side. High for such a a new language. I think my math is right. There's like over 50 years of experience and knowledge just under stage. Can we get maybe one tip from each

other you like riding and go and getting into the go mindset. I'll start and I'll take an easy one run go from 10 require it on to submit. You should run it on save as you are writing your code same with golden ports. small functions with lots of tests Play wit it on the playground and you know experiment. Be careful with contacts. I've had a lot of bugs with using the wrong contact in the wrong place. Be explicit about what you're trying to do keep your functions. You know don't use implicit information passed between function.

Okay, great. The second one last question then we'll wrap it up. I have a question for Brad you started writing the second Adoration of the night AC package. Can you talk a little bit about the problems you have with the your original iteration of it and maybe what the status is? Well, I have I have a long wiki page about all the things I kind of just like about the first one was kind of grew organically over 10 years or so. So I don't really have time in 30 seconds to go over that but the current status is I got distracted and other fires and stuff. So I

think I should be doing is finishing up the the new hdb client. We're all looking forward to it. Okay, well we're at a time. But thank you so much for joining us and all your great question and I'll try to go can you create experts in the community? That still didn't go?

Cackle comments for the website

Buy this talk

Access to the talk “Meet the Authors – Go Language (Cloud Next '19)”
Available
In cart
Free
Free
Free
Free
Free
Free

Access to all the recordings of the event

Get access to all videos “Google Cloud Next 2019”
Available
In cart
Free
Free
Free
Free
Free
Free
Ticket

Interested in topic “Software development”?

You might be interested in videos from this event

September 28, 2018
Moscow
16
159
app store, apps, development, google play, mobile, soft

Similar talks

Dan Sullivan
Principal Engineer/Architect at New Relic, Inc.
+ 1 speaker
Mike Truty
Technical Curriculum Lead - Hybrid/Application Development at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free
Mikhail Chrestkha
Machine Learning & Data Science at Google
+ 2 speakers
Christopher Crosbie
Product Manager, Dataproc and Open Data Analytics (ODA) at Google
+ 2 speakers
Gregory Mikels
Customer Engineer - Machine Learning Specialist at Google
+ 2 speakers
Available
In cart
Free
Free
Free
Free
Free
Free
Martin Omander
Program Manager (Developer Advocate) at Google
+ 1 speaker
Adam Ross
Senior Developer Programs Engineer at Google
+ 1 speaker
Available
In cart
Free
Free
Free
Free
Free
Free

Buy this video

Video

Access to the talk “Meet the Authors – Go Language (Cloud Next '19)”
Available
In cart
Free
Free
Free
Free
Free
Free

Conference Cast

With ConferenceCast.tv, you get access to our library of the world's best conference talks.

Conference Cast
558 conferences
22059 speakers
8213 hours of content