Osamah Mohammed Ali: [39:57] And the most exciting thing… FPGA is a very exciting thing for me right now, but I believe [unintelligible 00:40:03.06] of SDR and FPGA together - that’s what’s gonna change the way we push AI o the edge. Because imagine - you don’t have the limit of a certain technology that already sits on this device; just because the technology changed in a few weeks, or we’ve found a silicon-level issue with the design itself… Since FPGA, it’s easy to rearrange. It’s just firmware that you can actually push, and make it easier, a lot easier to control.

SDR also, pushing SDR - which is software-defined radio, basically. That’s gonna make 5G technology, LTE technology and IoT technologies without being stuck in a limit. And imagine if you actually let the machine decide the control of the waves, and the control of which band to actually use, to make sure a swarm of drones, for example, stay always connected. So AI is gonna get pushed to that, and I believe FPGA – I mean, we’ve been in the network industry for a while… It started with FPGA, especially on the network side, because it’s easier than building a complete ASIC, go to the market. But with FPGA pricing going extremely down in the last 5-6 years, until introduction of a new type of FPGAs that are actually built for intermediate devices… It’s not just input/output features; you have more cores from the technology that’s available to you.

I believe, [unintelligible 00:41:33.01] Python being able to actually utilize, to control SDR and FPGA - and we did some research on that - on the edge of the network. It’s extremely amazing. It can push AI capabilities a lot more to the edge, and use more sensors capabilities, utilizing that FPGA and sensor fusion. You don’t need a lot of sensors. You can use less channels by fusing your data together, and having like – we refer to it as the edge of the network, which we refer to it as MAEC (multi-access edge compute) today. But we also believe there’s another layer, so not everything is gonna be in the cloud. It’s in the edge, but also furthermore on the device itself.

There will be some decision-making happening there to eliminate the amount of bandwidth we use. Otherwise, all these connected devices will send so much data; no matter what technology we have, it’s not gonna be enough to process it.

Chris Benson: [32:13] Yeah, those are super-computers from NVIDIA, and also the work station, which is essentially half of a DGX-1… At least that’s what it was; the specs may have changed. Those are all very expensive, but those are for training at scale very complex models, and it’s great to see – I think right now we’re seeing so many players getting into the space with ASICs, and TPUs or the equivalents… There’s now choice in hardware, and that is really commoditizing the entire field.

I think it’s becoming very reasonable to get into deep learning for small projects, the way we do in software engineering, where you might go to work and have a primary, large-scale project you’re working on for your employer, but then you come home at night and on weekends and work on something that’s really passion-driven… And I think that is becoming more and more viable for data scientists who are really into deep learning, and for software engineers who are getting into deep learning. I think we’ll continue to see that. I still think we’re gonna have incredibly expensive AI super-computers. The DGX-2 is substantially more powerful and more expensive than the DGX-1 was. We’re seeing a breadth of what’s available out there.

Jerod Santo: Linux users get the first crack at running Mojo locally (Mac and Windows coming soon). What’s Mojo? “A new programming language for AI developers that will grow into being a superset of Python over time.” They’re calling it ‘Python++’ because…

“Python is pervasive, but not the right tool for tasks that require high performance or exotic hardware. Mojo enables high performance on CPUs, as well as support for exotic accelerators like GPUs and ASICs, providing performance on par with C++ and CUDA.”

This first release of the Mojo SDK includes a shell with a REPL, a VS Code extension & Jupyter kernel so you can run Mojo notebooks.

Kelsey Hightower: But again, remember what their objective was; their objective probably was to save the most cash possible. If they left the cloud to save 10%, I don’t think that would have been enough. But if you think about them leaving the cloud to save – I don’t know what percentage of their budget this was… That’s significant. And I think the only way you get to those numbers though - you may have to order your own server from Dell, and you may have to consider custom tooling to take full advantage. If we throw VMware on top of that, there might be a little bit too much overhead for what you’re trying to do. Those licensing fees may add up a little bit…

So this iteration - because we’ve also got to think about this. This is just iteration, one of what they’re doing. So iteration one says “Hey, get the biggest server you can. We can carve that thing up with basic –” KVM is really good these days, if people haven’t checked it out. KVM is actually pretty solid in terms of its APIs for creating a managed VM. And so if you take that, plus the fact that they had container images already, they have a good description of what they want to do, they’ve already done the heavylifting to make sure that their app can work well in an environment like this… So it’s no surprise that in their iteration one - I think they did what most good engineers should do… Start with the minimal thing you need. Go buy a big server from Dell. And what’s the minimum we need to do to that Dell server to get what we need? And I bet you someone probably went through a few prototypes and was like “Yo, KVM is freaking good right now. You can just create a VM with a two liner. Alright, so we take that plus Docker. What do we get?” And I think that’s what they showed to us.

Gabriel Ortiz: Well, cartography is the art and the science of trying to model the reality, and abstract the reality, and plot it on a flat surface. It’s a science that has been developing for a number of centuries, from many centuries. And up until now, it was highly dependent on the human ability to trace and to draw everything on the surface of the Earth. As the technology has been developed from the ’90s, we started to move very rapidly into digital technologies. And the automatation of the cartography has taken place not only with the advent of AI, but several decades before. However, this is a revolution, because we have never been able to produce such high degree of quality, using so few people working.

There are some similar technologies, like remote sensing, which is the part of the technology in charge of analyzing from imagery of satellites, and producing cartography also. It recalls many things of the artificial intelligence, but it can match their results in many other fields.

So that revolution continues… It started, as I said before, in the ’80s, ‘90s, but now it’s a complete revolution, and I think that, for the first time – we have an example that you can check it out in the description of the podcast, where we have been able to produce a map with basic coverage, where you have trees, where you have shrub, where you have no vegetation, where you have buildings, or roads, or railroads, completely generated by AI. Of course, it has some mistakes, but we left those mistakes on purpose, because we wanted that the rest of the community could evaluate the capacity and the ability of the models to work alone.

Kevin Ball: Grid Critters. Okay. So you’ve got sort of basic layouts you’re kind of going through… Now, let’s say somebody is – they’re comfortable laying things out in a standard design, they are familiar with basic properties, how to change color, and font family, and these things… Where do you go next? What’s your sequence beyond the basics?

Jon Calhoun: I was gonna say, in the U.S. at least, I can say that most teachers don’t get into it – basically, they love teaching kids and helping them grow, and they don’t get into it for the money, because there’s not any money in teaching… So like you said, I think most teachers have the right incentives most of the time, but unfortunately, they’re kind of limited with resources.

Our daughter is not in school yet, so I haven’t experienced it first-hand… But it is something that concerns me, and something that I talk with my wife about, is like - this homeschooling makes sense part of the time.

And it’s also hard for me, because personally, when I was in school, I feel like I got lucky. Our school had a gifted program, and I somehow got into it in the first grade… And basically, that was really rare. And for the most part - I’ve learned this later. Most of the kids who got into the gifted program were teachers or children. It was rarely other kids in the school. So it opened the door and allowed me to experiment with other stuff. Because basically, one day every two weeks I would go to a completely separate class, with other kids who were supposed to be in this gifted program… And we’d do things like logic puzzles; that’s where I was first introduced to programming with BASIC. And a bunch of things that really shaped my life.

But there’s probably a bunch of kids who deserved to be in a program like that, who would have thrived, or something like that, but they just didn’t get the chance… And seeing that now, I’m like “Well, that really sucks.”

Erik St. Martin: I knew it was gonna be Basic, with this theme…

Matt Holt: Kind of both… I mean, if you have a databasing application and it’s really slow, you’re gonna get low requests per second. You should probably optimize that. Actually – so Caddy had a performance issue in the early days of v2 with HTTP basic auth. You know how that works, where the client sends a password over plain text in an HTTP header; the only reason that it’s even secure is if it’s over TLS, which obviously Caddy does by default. And with Caddy 2, we changed the way of configuring this. Typically, to configure basic auth you specify a username and a password in plain text in your config file… And we stopped doing that with Caddy 2. You have to hash the password, because otherwise it’s basically like starting a plain text password in your database. That’s stupid. That’s just a bad idea and you’re asking for trouble.

So you have to hash it with a secure hash, like bcrypt, which is slow. So you get these requests coming in with basic auth, and as you know, with basic auth every HTTP request, even images or whatever page resources - they all have this header test and they all need this hash computed in order to check the authentication. So actually loading a web page with basic auth in the very first release of v2 is really slow. And yeah, that kind of thing matters. The bottleneck was the web server. We’ve fixed it since then, but that is maybe the only time the metric matters… But if you’re comparing who can serve a static file faster, no one cares.

Preston Van Loon: [48:03] So the Prysm project is fully open source on GitHub. We try to do all of our stuff in a transparent manner, so that’s either posting updates, talking in public channels, we have a Discord community of about 10,000 people… So there’s a pretty big community there already; if you’re looking to come with basic questions, that’s a great place to get answers. But really, checking out the project, running the code, trying it in a test network, and really just – if you look at it and you’re like “Oh, this doesn’t make sense to me. Why is it this way?”, that kind of feedback has been extremely valuable to us. As a contributor, you can say “Alright, well this has some friction, and I have an idea to fix it” and you can propose that change, and most of the time, almost every time, we’ll take that and say “You know, this is a great perspective and feedback” and help get that merged into the project.

Evan Welbourne: Oh yeah, it’s been going on for quite a while, in research at least. More than 20 years people have been just experimenting with simple things like accelerometers, or motion sensors, and then can we use – I was using decision trees quite often, just the most basic of models. You can get pretty far with basic models, but of course, when you’re really trying to scale something and make it work for everyone, you’ve gotta use the more sophisticated approaches.

Maxime Vaillancourt: [04:24] Right. So Shopify was started almost 15 years ago now, and this all started as a simple Rails application, the majestic monolith approach, where everything would be into that one application… Which we’re still using today, 15 years later, and that’s the main place where most Shopify developers tend to ship code into.

Of course, with scaling you run into challenges with how you get to handle multiple hundreds of developers working on the same platform, shipping that codebase at scale, but also dealing with should go in the monolith. And as we eventually ran into a point where it was impossible to use Rails as it is into its base form, we hit the limits of what we could do with basic Rails.

As you mentioned, Shopify is a multi-tenant application, so just dealing with the implications of that, and making sure that there’s no cross-tenant access for data - that sort of thing required some patches to the monolith. So the monolith is an application where most of the code is present in there. We’re now splitting it into separate components, so that we have business domain-specific components in the monolith, and that makes it so that for example Storefront and online store specifically was this own component, where everything would be into that directory. So it kind of gives us a nice way to create these boundaries between the different components, so that there’s no cross-component access, and hopefully eventually everything has to interface between each component, and there’s no violation.

There was one article on the Shopify Engineering Blog that we’ve just posted about this, that explains how we’re starting to enforce more the boundaries between those components to make sure that we don’t run into issues with different class names that don’t make sense, or that sort of stuff.

Brad Fitzpatrick: I started off with BASIC and C. But neither one – you know, in BASIC you hit limits pretty quickly, and C is not very fun. It’s like, it exists to do things when you need to use it, but I don’t enjoy writing in C. It just feels tedious.

So when I discovered Perl, in ’93-’94 or something like this - it was Perl 4 at the time - I was like “Whoa, I can do things really quickly!” But this was also the language everyone at the time was doing CGI scripts in too, so it was also the language that let me do cool, dynamic web stuff.

[28:07] So I was very in the Perl community, very involved, and all of LiveJournal was pretty much all Perl, except for little bits and pieces that needed to be C for performance reasons. Memcached was originally in Perl, but it fell over within like a second, as I suspected it would. The prototype was in Perl, but then we quickly rewrote it in C.

So I love Perl, and I never really jumped on the Python or Ruby trains, because they were just not different enough from Perl for me to care. They had all the same pros and cons; they weren’t much better. They were still like explode at runtime, and no type checking… Python and Ruby were even slower than Perl, so performance wasn’t a reason… And maybe the syntax was a little cleaner, but at that point I didn’t care, because I already knew Perl.

And then I joined Google, and they use lots of Python, C++ and Java, so I wrote in all of these kind of out of necessity, but I didn’t really love any of them. I worked on Android for a couple of years and wrote a lot of Java, and a lot of Google frontends were often in Java, and Google backends were often in C++… I launched a service that was a whole mx of things. It was like Java, C++, Sawzall which was Google’s language for logs analysis, which Rob Pike worked on prior to Go… I kind of hated it, but that’s what everyone at Google wrote their logs analysis in at the time. Nowadays they’ve migrated off Sawzall onto Go.

Yeah, so I was never really excited about any of the Google languages. I wrote in them because I had to, because there was no choice… And then I saw Go come out. I went to a bunch of the internal talks on Go, and I was like “Yeah, yeah, whatever…” Google had a bunch of internal languages, and most of them were so-so… So I was not super-excited at the time.

Somebody had a question from the audience, like “Does Go have closures? Do you have first-class functions?” And the answer was a very dismissive “No, we don’t. You don’t need them”, or something. And I was like “Well, okay… I’m out.” Perl had them, and I had this book “Higher-order Perl” that I really loved, that taught me a lot of what people would probably actually learn in Lisp in school, or whatever, but I never really had any exposure to it until that book. So I was totally in love with higher-order functions, and stuff like that. So when Go didn’t have it, I was like – I kind of wrote it off. And also was like “I don’t really invest much time in another Google internal language, because I’ll just leave Google at some point and I won’t get to play with it anyway, and I won’t get to use it for my personal projects…”

But then when they said they were open sourcing it, I was like “Oh, I should look again. And then I noticed they had added closures in the meantime. I guess Russ Cox just went in one day when Ken Thompson was on vacation, and couldn’t object, and Russ just added them. [laughter]

Peter Wang: Like I said, I’ve been programming a long time. I know a number of languages, I started with BASIC and Logo, as so many people do, children of the ‘80s… But I learned a lot of languages. In fact, my professional work had been in C++, and I was a huge performance nerd, and all that stuff. When I first clued into Python, it was version 1.5.2, and it was a Slashdot post, and I was like “I’m tired of all these Slashdot posts on Python. Let me finally take a look at what it is, because Perl 6 looks like it’s gonna take a little while to get here, and I might as well play with Python.” But when I started using it, I realized “Oh, my gosh. This is very nice. This is executable pseudo-code, and furthermore, I can use Python to script my low-level C++ graphics engine and be way faster than sitting there, beating my head into C++ templates, which back at that time they were not very well-supported by any of the compilers… So I could get more abstraction, I could prototype very fast, and it was just pleasant to work in, and I felt like I could do stuff without slogging through a pile of syntax.

So that ease of use and that friendliness, even for a seasoned professional programmer like myself, was very nice… And what ended up happening over the course of the 2000’s was that you could see people who are not traditional programmers - and this is gonna be a very important thing as we talk about Practical AI and talk about the demographics of the next generation of practitioners - the people who made Python good for science, and data science and all this, they’re not professional software developers. So Jupyter was born as IPython, created by – well, I mean, Fernando, for instance, is an applied physicist… There’s a lot of physicists actually around the ecosystem.

Jerod Santo: What's pretty cool here - you talk about the experiment that you are doing, Ben, and you guys have Octobox free for open source projects, with basic notifications for private projects. Of course, it's also open source, you run your own instance, so if you wanna do it that way, that's all good. We're talking about Octobox.io. And then it says "To add enhanced notifications for private repositories to your organization's account, there's two ways to pay", and I think this speaks to what you were talking about, Ben, where they'd rather provide funding to a community versus to a commercial enterprise that's really supporting that community, but is somehow distinct from it in terms of limited participation… So you have an Open Collective donation, and then you also have the GitHub Marketplace option.

Adam Stacoviak: [16:08] Or they’re even doing special things with their data more so than simply like “Hey, we have a web app with basic CRUD.” MySQL, Postgres - those databases are perfect and great and fine for those types of apps, but once you’re past a certain point, you won’t actually make more sense, or get insights, or analytics that really draw relations or different things from a database. You may want to experiment, and even use in addition to, versus simply replacing.

Brian Ketelsen: Barely… So I have a story to tell that will help us kick off one of the main topics for our show today. I was walking home from Golang UK this afternoon; it’s like 6:30 or something like that, and I’m kind of sneaking out because I didn’t say goodbye to 600 people all at once, and it was so that I could come to the podcast. And as I’m turning around the corner to get on the main street to walk back to my hotel, I hear “Brian! Brian!” Some guy was shouting “Brian!” So I stop, thinking “Well, there probably are other Brians, but I guess it could be me.” So I stop and I see this guy running towards me; he goes “I just wanted to let you know that I’m a big GoTime.fm listener, and I love the podcast, and somewhere around episode 42 you were doing a interview with Asim Aslam about Micro, and he was mentioning these companies, and it reminded me, because I was walking really close to this company, that hey, I used to work there, and I know people there, and now they’re doing Go. I think I should call them and see if they’ll hire me to do Go.”

So this guy, randomly listening to our podcast, calls his old boss and says “I hear you’re doing Go now. Hire me back”, and they did, and now he’s doing Go because he listened to Go Time. I found that to be just – I was giddy, I was so excited. That’s awesome. We brought a person who wanted to be doing Go directly into a paying job, which is the best segue that I could possibly build for Carolyn. That’s why we’ve got Carolyn on the show today.

Carolyn’s doing awesome work over on Dep as a maintainer for the Dep project, which is arguably the most important Go project on the planet right now…

Jaana Dogan: Very cool. I kind of feel like we were the last generation who has some sort of privilege to understand everything, from end to end. When I was a child, the personal computers were so small… I remember having a Spectrum, and its manual was basically starting with BASIC programming language. The computer architecture kind of like gives you all the main components and how they work and how they interact with each other. The final chapter was an instruction set, and how you can write optimizations and things.

By looking at the current complexity of the things, I think the current generation doesn’t have the same privilege to learn and understand everything from end to end. What Raspberry Pi was trying to do was trying to make things more accessible. I think all the Linux boards are doing a better job now, but everything is just too complex at this point; there’s just so many layers, and it’s so easy to get lost.

When I introduce myself, that I’m supposed to be a power Go user, and giving people, the team, usability API design feedback, maybe initiating libraries and tooling to fill the gaps… If there’s any experimentations required, probably I have more time to run experimentations, so it’s part of my responsibility. And I’m still in this transitioning period, and while I’m there, I’m just trying to listen to the community and gather some feedback, actionable items.

[20:02] One of the things that Brian was mentioning is this feedback around tooling. I wanna understand, rather than specific bugs and complaints, what are the bigger picture problems. If we would like to rethink our tooling, what should we fix and how should we fix it? This involves an understanding of the current workflow of the users and what is missing there, and trying to understand more of a bigger picture, rather than focusing on little things.

I’m kind of surprised by the number of people who actually returned back to me and wrote about how they feel about certain things, things that maybe need to be redesigned or can be supported by experimental tools or extension tools. I’m really excited to hear more, and I do believe as a community or as a language we will never succeed if we cannot create this type of feedback channel and question what we are doing once in a while.

Anthony Eden: Yeah, we could say essentially languages that have enough use at DNSimple that an engineer needs to know them, or at least if they’re going to run the whole stack. The answer is most of the engineers spend most of their time in Ruby. The vast majority of changes – the Ruby code, what the customers see, changes a lot faster. So it has the highest rate of change. The other two languages have a much slower rate of change. And so the reality is they don’t get constant practice. And then now what we’re trying to do is get it so that they can ensure that locally they can stand up the whole stack, so that they can get practice with each one of those things and make changes with each one of those things. If an engineer needs to do it every once in a while, most good engineers will be comfortable switching languages. They’ll be able to pick it up. It won’t be instantaneous, they’re not going to write the most idiomatic code, but they will be able to pick it up and do what they need at the most basic level with it. And especially if there’s good tests that they can run and ensure that whatever they’re doing doesn’t break things horribly.

Daniel Whitenack: Yeah, I think that people anecdotally at least, if not explicitly in their own evaluations, have found very many cases where, like you said, it’s very frustrating to try to put things in your prompts, and just not get it. And what’s interesting also is a lot of this is boilerplate for people over time, like “You are a helpful assistant”, blah, blah, blah, and they have their own kind of set of system instructions that, at least to the best of their ability to get what they want.

So I think when you’re seeing inconsistency in control from the prompt engineering side – I always tell people when I’m working with them with these models that the best thing they can do is just start out with trying basic prompting. Because if that works – that’s the easiest thing to do, right? You don’t have to do anything else.

Bryan Boreham: So the basic idea with a tool like pprof is you’re going to run your program, you’re going to have it doing its thing, and the profiler is going to interrupt like 100 times a second. And every time it interrupts, it’s going to take a note of what was executing. And then statistically, over a few seconds, or however long you leave it running for, you could – that’s why we call it a profile; you build up the numbers, you say “Well, it ran for 10 seconds, I interrupted 100 times a second, so I have 1000 counts in total. Of my 1000 counts, half of them were in this one function. And 10% was in this other function, 10% was in this other function.” So that’s the profile. The mechanical step of interrupting 100 times a second and making a note, and then adding up all those counts, and then you draw it on the screen. And I like a particular visualization called a flame graph, where - it’s not very good for a podcast. I’m waving my hands around, but it’s not helping. Honestly, go find videos where people show these things off if you’ve never seen it before. But basically, you’ve got rectangular bars, and the bigger the bar, the more time it spent in that function. So you just - you bring this up, and you look for the big bars. That’s it.

Chris Benson: Gotcha. Is it fair – you know, as we’re talking about this, it sounds a lot like you’re also solving one of the bigger challenges we’ve talked about over time, which is that there’s so much domain expertise in the AI space in terms of being able to manage models, but if I’m understanding you correctly, it sounds like minimally, with some basic software skills, and knowing how to use APIs and stuff, you can probably without deep expertise and deep learning manage to get some fairly productive output through Protection Guard, by implementing it that way. In other words, it becomes just another part of your software workflow. Is that a fair characterization, what I’m saying?

Alex Russell: [01:01:48.18] Yeah, so I’ll try to break them apart a little bit, and say that if you’re an individual who has skills in JavaScript, and you’re looking for how to improve, again, the most important thing you can do is learn to be putting the user that you’re trying to serve at the center of it, and then start to think in terms of hitting frames, every 16 milliseconds; hitting that interaction target that you would like to have hit on your extremely expensive device, on that cheaper device, and for that marginal user. I promise you can do it. Computers are fast. And you’ll find out where your framework might be a stumbling block, or where React will generate way too much GC in a critical section or something, and it’ll hurt you. And that will turn into a challenge and you’ll learn to solve it… Maybe inside the framework, maybe you’ll learn to go around it a little bit… But those are incredibly important learning opportunities for you to understand the trade-offs.

And then I would suggest, again, as an individual, if you’ve been living up in JS land, where you’re kind of doing everything in user land, the most important hours you can spend are not learning another framework; they are learning the system underneath you. Every hour you spend learning how the browser actually processes your content and actually thinks about it, actually thinks about the networking and actually thinks about how we take DOM and CSS and we construct them together, and we create the layout tree, and then we paint out of the layout tree, and then we rasterize that out in the GPU - that flow and how we do that every 60 hertz, every 16 milliseconds, learning the pieces of it and the sensitivities of that system to what you do in CSS, and JavaScript, and through your HTML, will make you a better developer in every framework.

So it’s extremely important that you learn to think about that knowledge not as something that you don’t have to think about anymore, but as something that now that you’re not a beginner anymore is extremely valuable to you… Because you’re not at the end of your career, so it’s going to be important that you be able to adapt on the basis of shared knowledge across all of it.

And then for teams and for organizations, I’d say that that hiring thing - again, that’s trope; it’s not reality. I promise you there’s a fire sale on talent right now. Go look. You could just pay for it, and you’ll pay less than you think you would. But in terms of the choices that you make in terms of stacks, I would encourage folks to be a little bit more data-oriented, right? Again, step back and look at the actual experience. How many of these tools that you think are necessary are there to solve problems that the tools that you thought were necessary created, right?

if you start with simpler output, one of the cool things about it is – okay, let’s just say you move from taking your static marketing website out of Gatsby, which is going to go with some huge GraphQL query to return a bunch of React components, and render that on the server side, and do all this stuff. And then you have to think about how you’re gonna smush all these things out, and like do the CSS minification, and all that stuff… Whereas if you just output the same basic HTML, with the SQL query, and some PHP, or some Python, or some Ruby, how much more headroom would you have in the output in terms of the cost of the output, before you ever had to think about applying a tool to start tamping down on those costs, right? Because once you start thinking in terms of budgeting, latency budgeting, complexity budgeting, you can start to think about the trade-offs as being not about like for like, but it’s about being different in ways that structurally set you up for success if your system is simpler.

Now, once you get to a very complicated product, when you know you have a really complicated product, then you will need sophisticated tools, and they will need a lot of management. But going through that process of evaluating those things, and doing bake-offs, and learning the properties that emerge out of those simpler versus more complex systems will teach you something, it’ll give you a finger feel for whether or not one style of construction is going to be more appropriate here or there, and maybe help you make more informed trade-offs in the future about the style to build in for a particular kind of use case.

[01:05:43.08] And then I’d say at a community level, we need to step back, and I think we need to think about our relationship to society. And I don’t think that that’s going to be a thing that is traumatic, or even hard, right? We’re all here to build great experiences. I believe that. I truly believe that. I think Laurie’s piece in response to mine said something about how I think that developers are stupid, which is hilarious, on a couple of levels. But I just don’t. I work with extremely talented people all day long, and I’m grateful to get to work with them. And if we take seriously that it is evidence and science that are going to get us to a place where when we apply our skills, they turn into good things for the people that we wanted them to, that’s a fundamentally optimistic way of thinking about this technology.

We don’t have to accept what has happened, or accept that it happened for good reasons, or even accept that the people who are so attached to it are correct, or worth having in the conversation, in fact. But once we put the evidence at the center of what’s working and what’s not, I think we can start to reevaluate our relationship to the technologies, and acknowledge on the one hand we’re more than our choice in Java framework… [laughs] I promise you, there’s life after the framework that you love right now. And also, that as a discipline, the more we are reliably delivering good things for users and for businesses, the more likely it is that there’ll be more work for us, more good things that we’re going to be able to create in the future, and more users that we can help. And for me, that’s the goal, is to be able to help users. So when we put that at the center, and we put the marginal user at the center of that question, then I think we get to a good place. So I’m optimistic.

chg: Yeah, I think there was definitely – early on there was a big disconnect between rich content and then hypermedia content. So hypermedia stuff was relatively - and still is, in many cases today, pretty basic forms, with some pretty simple form controls. At the most elaborate it was often just hypermedia documents you were clicking around in. And then there was this other world that had much richer event handling, and typically it was canvas-based, or there was some infrastructure built on top of it. A pretty raw canvas that you had access to. That’s what Flash gave you, and it’d let you do much lower-level graphics programming. And actually, in many ways, Flash is a really cool technology to go back and look at, because it had a lot of very interesting things going on inside of it… So some low-level as well as high-level tools for building these things.