Bob Nystrom, author of Crafting Interpreters and a software engineer at Google working on the Dart programming language, discusses the key features of Dart that make it an excellent choice for fast apps on any platform. Host Gavin Henry spoke with Nystrom about Dart’s history, hardware out of your control, async-await, concurrency, mobile platforms, threads, isolates, garbage collection, sound null safety, spread operators, collection if, hot reloading, flexible type systems, and when you should reach for the Dart programming language.
This episode sponsored by Shortcut.
Show Notes
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Gavin Henry 00:00:16 Welcome to Software Engineering Radio. I’m your host, Gavin Henry. And today my guest is Bob Nystrom. Bob Nystrom is a software engineer at Google working on the Dart programming language. Before falling in love with programming languages and compilers, he was a game developer, UI programmer, pixel artist, and computer animator. He’s also the author of Crafting Interpreters and Game Programming Patterns, a college dropout, and a fairly decent cook. Bob, welcome to Software Engineering Radio. Is there anything I missed in your bio that you’d like to add?
Bob Nystrom 00:00:50 No, I think that’s all the highlights. Everything else about me is strictly less interesting than those points.
Gavin Henry 00:00:55 A college dropout, a good or a bad thing?
Bob Nystrom 00:00:59 I mean, for me, it’s probably not necessarily a good thing, but I do like mentioning it because I know that there’s a certain number of people that have imposter syndrome about their own level of educational attainment. And I’ve been super fortunate in my career and I like being able to point out that yeah, it’s possible to be a software engineer at Google, even if you don’t have a college degree. So, that hopefully, I don’t know, hopefully that people feel that doors are maybe a little more open than they thought they were.
Gavin Henry 00:01:23 Sometimes you do get that imposter syndrome because you haven’t done the masters or you haven’t done the PhD. Something I feel all the time. I think we all suffer from it.
Bob Nystrom 00:01:33 Yeah. I still wrestle with it at work all the time. I think one of the lessons I learned was just give yourself a break somewhere.
Gavin Henry 00:01:36 Thank you for that. So, the show today is on the Dart programming language. And what we’re going to do is we’re going to talk about why and when it was created to understand when to use it; it’s top three benefits; where it can be used; and I did a previous show with Tim Smith on flutter (episode 437). So, we might circle back and…
Bob Nystrom Tim is great.
Gavin Henry Yeah. He actually put your name forward as someone brilliant how this happened. You’ve got some to live up to.
Bob Nystrom 00:02:12 Yeah, I can promise you I won’t do as good a job as Tim would, but I’ll try to be a tolerable second place.
Gavin Henry 00:02:20 Cool. I think we’ll be fine. So, I’d like to start with an overview of what type of programming language Dart is and it’s top three features and when we should reach for it. On the dart.dev website — so that’s the URL — the headline is “Dart as a client optimize language for fast apps on any platform.” What does that mean?
Bob Nystrom 00:02:41 Oh man, that is a nice brand summary. So, the bits there are: it’s cross-platform, right — so it’s not targeting a single OSPF family or something like swift is — and it’s client focused, which means for me as a language designer, I think it means two interesting things that are kind of in opposition. One of them is that it’s a language designed to run on hardware that the programmer doesn’t control. Right? So, if I’m using a language like Ruby or Python on a server and I’m making a website or a service or something, I generally control the hardware, right. So, if my language is slow, it’s running on my machines anyway, and I can throw more machines at it. Right. So, I have ways to sort of balance cost and performance that are under my control. But if I’m programming for client devices, I don’t have that, right? Like, if the language is slow, if the language implementation is slow, then the application’s slow because it’s running on a machine that I can’t make any faster, right? Like, if it’s running on someone’s low-spec phone in a developing country, if the language compiles to slow code, that means that app is slow. Right?
Gavin Henry So, being focused on client applications means that performance matters a lot.
Bob Nystrom 00:03:51 This may not be the first time I’ve been asked this question, but there’s an interesting flip side to it too, which is that you can think of client apps like UIs, right? Like, we are a language for building programming, UIs, and I don’t know — have you ever done UI development before?
Gavin Henry 00:04:07 Yeah, I’ve done an app start to finish using Flutter and Dart that’s on the app store now. My business sponsor a CEP implementation of Dart on open source project is really popcorn. They only set stock Dart. So, I’m quite familiar with it. That’s probably why I wanted to do this show.
Bob Nystrom 00:04:25 Yeah. So, then, you know what the experience of when you’re doing UI programming feels like where you’re just tweaking a lot of stuff, right? There’s a lot of sort of subjective choices you’re making about, like, layout and sizes and positions and colors. And you kind of need to just see that on screen to get a feel for it. And there’s this very tight iteration loop that you need, right? It’s not like if you’re doing low-level programming, sometimes you can sit down and write 500 lines of code and then run it and see if everything does what you want. But with UI, you need this sort of incremental feedback, which means the developer productivity matters a lot, right? Like you need a language that is pretty fast to compile and reload and get things up and running. Something that feels lightweight and kind of scripty; doesn’t feel like there’s a lot of ceremony and those two goals — being fast on the user’s machine, but also being fast to iterate on and being high level and productive — they tend to be in opposition, right? It’s hard to write a high level language that compiles to efficient code. And it’s hard to make a low level language fun to use. So, with Dart our sort of goal as a language is to try to find the kind of balance point between that.
Gavin Henry 00:05:29 Yeah. That’s something I experienced in our app where I could have done screens and stuff, but it was so fast and the feedback was instant. You could literally just play as you were and just work through what you had in your head, because it was so such instant feedback. That’s something I really liked about it.
Bob Nystrom 00:05:47 Yeah. That’s cool to hear. You know, so before I was at Google, I was a game developer, and you work with game programmers and game designers and there’s this sort of numeric measure of productivity — of how much can you get done in a given day? And that kind of matters at some economic level or something, but the thing that I really care about is, like, I’ve watched people work and if you give them a developer experience that is smooth enough and fast enough, there’s a qualitative difference in what it feels like to do that work and the kind of work that you get out of it. Right? Like if it’s enjoyable and smooth and fast enough to iterate on the thing you’re working on, you’ll try stuff out. You’ll make experiments. You’ll be let’s see if this works out. And I believe you’ll get to a better design than you would if it was more effortful. Right? So it’s not just that, yeah, you ship faster. I think it does affect the quality of the thing you end up making.
Gavin Henry 00:06:42 Yeah. I can totally relate to that because if you had an idea, you could just instantly try it because you could see it straight away. And most nights when I was on, even if you’re not in your zone and as it were, you’ll go till 1 or 2 AM, because you can just try so many things and see it straight away.
Bob Nystrom 00:06:57 Yeah. It’s such a cool feeling, right? To sort of get lost in it, you know?
Gavin Henry 00:07:01 Yeah. So, why and when was Dart created? It’s quite old from a program languages point of view.
Bob Nystrom 00:07:08 It has had a bit of a storied history. So, we’ve been around maybe nine years. Is that right? That sounds right. Somewhere around there. We worked on it for a while internally before we open sourced it, but not that long, we open-source pretty early. And then it was out there and didn’t have a lot of adoption for several years, and we had to kind of pivot in some ways. And then when flutter came along, that was sort of the thing that kind of picked us up. You know, I look at flutter as being sort of like Ruby on rails was for Ruby, right. Where like Ruby was around for a long time before rails, but it wasn’t you need something like a killer app for a language to really thrive in flutter was for Dart.
Gavin Henry 00:07:48 Yeah. There’s quite a few like those on there, there’s the Phoenix web framework, which is the looks are, there’s a lot of owl, which is PHP. And it just seems to be you like that framework and the language just comes along with it.
Bob Nystrom 00:08:00 Yeah. You know, it’s a big ask to get someone to learn a new programming language, right? Like it takes a lot of work. It’s a, it’s an investment in cognitive resources that they don’t get to use on other stuff. And it’s hard to motivate people to do that unless it takes them to somewhere that they can’t get to otherwise. So, if it’s like objective C where it’s at the time, the only way to program for a particularly desirable target, then they’ll learn it. Or if it’s the only way to use a particularly desirable framework like flutter rails, then they’ll learn it. But if you don’t have kind of anything that really drags people over that chasm to get them to learn it, then it’s really, really hard to get people to.
Gavin Henry 00:08:35 And how easy are there for someone to learn? So, for example, speaking about getting up to productive state, I can speak Russ, for example, has quite a reputation of being difficult to get because of certain concepts like borrow checking and other things. My experience correct me if I’m wrong, it was pretty easy just to drop him. Cause it had choir JavaScript ask feel, and then go along or go type feel with the static types if you want to die on the dynamic types. But I think what made it really easy for me was the sort of first class integration with, um, Android studio.
Bob Nystrom 00:09:14 Oh, interesting. Okay. When you’re hacking on your Dart code, you’re usually doing it within Android studio.
Gavin Henry 00:09:19 Oh yeah. When I first started, I never used it, just the error prompting and do this and click through to the class to see what all the methods and heartbeat options are. And the dogs in the actual source code of Dar are fantastic when you get that,
Bob Nystrom 00:09:36 You know, one of the things I’m really grateful is that we have a team at part of the Dart team doing static analysis and doing IDE integration at man. They’re just great. They’re just super great people. And they they just care so much about having a good rich user experience when you’re working with the language to all that stuff comes from them. They’re they’re awesome. So, you asked the question earlier about like how easy is it to learn Dart? And that’s a really cool question because it’s deeper than it sounds. Right. Because the question then is well easy for whom, right. And there’s interesting trade-offs that you make there, right? So, the, the original designers of the Dart, their number one goal was to make a language that’s easy to learn for people coming from JavaScript and Java and Dart looks a lot like JavaScript and Java because of that.
Bob Nystrom 00:10:22 Right. And it has a lot of the same concepts, right. You know, it’s object oriented it’s got classes, it’s got functions, it has the same basic kind of CSUN tacks that JavaScript and Java have. So, for that very large pool of people the feedback that we get, the data that we get from user studies is that Dart is pretty easy to pick up. But there’s an interesting trade-off there when you’re a language designer, which is like the way to make a language, easy to learn is to make it similar to languages that people already know. Right. But if you make it too similar, then, then what’s the value proposition, right. You know, why bother switching at all? So, there’s this tricky balancing act that we have to do where we have to make the language different in ways that are positively compelling. So, that there’s a reason to learn it at all. But at the same time, it’s sort of try to minimize the negative difference from other languages. It’s a tricky balancing act. And it’s also tricky balancing, making it easy to learn for people coming from certain other language families versus maybe making it easier to learn for Python programmers or for people that have never programmed at all. Right? Like each of those people has a different perspective and targeting those groups kind of pushes the language in different directions.
Gavin Henry 00:11:30 Yeah. And it depends what level you’re at to star. You know, if you’re seasoned in a couple of languages are really know a certain language, then certain computer science concepts apply to any language. And then it comes down to the quality of the community ecosystem that you’re trying to figure out, well, how do I do this? Dart, like know how to do in Java or JavaScript, tar another language. Yeah. So, I think we’ve touched on what other languages are similar to Java script. When should a programmer use Dart say, if they’re not using flutter,
Bob Nystrom 00:12:04 You should use Dart all the time for all of your programming needs. Obviously it’s a good question. You know, so at one level we are a general purpose language. We have, we ship with a command line VM that has networking and file system integration built into a kind of like no JS is for JavaScript. So, you can write command line apps, services, servers, all sorts of stuff in Darts, almost all of our tools that we ship with Dart are written in Dart. So, our static analysis framework, our compilers to Java scripts code format or all that stuff, all that’s written in Dart I think it’s a pretty good general purpose language. So, yeah. So, short answer is use it for all this stuff, but we have we do generally invest in it being a client side, UI language to some degree maybe at the expense of other domains then in particular is really, really difficult to compete with other languages when it comes to writing servers and services, that kind of stuff web framework, backend web framework kind of stuff, but not really at the language level, but at the ecosystem level, right?
Bob Nystrom 00:13:07 Like if you’re if you’re writing a web backend in Ruby or Python or Java there is already bindings and mature libraries for every single database and other facility that you need, all that stuff exists.
Gavin Henry 00:13:23 Yeah. It comes down to the libraries you have access to and not having to start.
Bob Nystrom 00:13:28 We’re getting there with Dart it’s growing, but we’re not as far along there as languages that have a 20 year head start on us. So, that ends up kind of being one of the limiting factors. We are in some ways, a high level language languages, garbage, collected, memory safe. So, the performance that we get is is good. I feel good about it, but it’s probably not the best language for stuff that it needs to either be very low level or very high performance. Right. So, you could you can write games in Dart, but you’re probably not going to write a AAA game. And you’re probably not going to want to write, I don’t know, a USB driver or something in Dar where you need access to raw memory, things like that. But you
Gavin Henry 00:14:05 Do have the, is it the FFI? Yeah.
Bob Nystrom 00:14:08 So, we have that FFI we have pretty nice to see in C plus plus interrupt now. So, yeah, you can do that. I mean, you could, but there’s a certain, like I think of every language is kind of having, I dunno, like a sort of grain to it.
Gavin Henry 00:14:19 Yeah. What was that foreign something interface? Wasn’t it?
Bob Nystrom 00:14:24 Yes. Yeah. Foreign function interface. Sorry
Gavin Henry 00:14:27 About that. The show with Tim Smith, I’m going to start moving those onto the next section shortly. Sure. I just wanted to touch on the top three benefits of Dart and your experience
Bob Nystrom 00:14:41 And compared to what
Gavin Henry 00:14:42 I’m not going to give you the answer.
Bob Nystrom 00:14:44 Oh man. So, I can tell you what I particularly like about Dart. And I should say that you can go into the front page of the dart.dev website.
Gavin Henry 00:14:56 Oh, it’s more fun for me to ask you to give me your three.
Bob Nystrom 00:14:58 Yeah. I should say so my role on the Dart team is I work directly on the language in some ways that means I’m a little removed from what the average day-to-day flutter developers, user experiences. Like I have a professional interest in knowing what that world is because that’s, that’s who I’m serving, but that’s I don’t make flutter apps every day. So, I may not be the best person to tell you what’s, what’s amazing about it, but I can tell you what I like about it. So, I like object oriented programming. I’ve been writing code for three-fourths of my life at this point now. And I don’t know, I’m super comfortable when I have to write a large program, organizing it in terms of classes, I think that works well for programming in the large.
Bob Nystrom 00:15:40 I think it works really, really well for UI programming, but I also really like functional programming. You know, I’m very comfortable with closures and higher order functions and stuff like that. And I think that’s a really nice way to model algorithms and smaller scale code. And Dart is one of my favorite languages for combining those two paradigms where I feel like both of those are sort of first-class citizens in the language and they harmonize together well. So, it kind of like the experience of like programming the language. I don’t know. I like writing Dart code. I enjoy it. I feel productive in it. And then kind of at the implementation level the fact that we have hot reload is pretty amazing, right? Like you can make changes to your program and see the results of those changes literally within milliseconds, without having to reboot your app.
Bob Nystrom 00:16:24 And without having to get back into the state you were in is incredible. You know, I used to be a game developer and I can’t tell you how much of my life I have spent restarting the game and then having to like play it or go into the debugger and set a bunch of fields to try to get the game back into the state that I was in before I made some code change. And the fact that we have a VM that can just do that is super cool.
Gavin Henry 00:16:49 Yeah. We’re going to talk to Paul in the next section.
Bob Nystrom 00:16:52 Oh, well then I shouldn’t get ahead of things.
Gavin Henry 00:16:54 We’ve got a good intro there. There’s some, some things I’ve missed, but we’ve pretty much crossed over them in our initial chops. So, take the first headline from the website, which is optimized it’s about what this ad, although it should be spelled than us optimize for UI. Now that we’ve had a good intro, it goes through those top three benefits that you didn’t answer. But then on the website, we’ll let you off.
Bob Nystrom 00:17:19 Sorry. That’s
Gavin Henry 00:17:20 Fine. So, Dar has the concept of async
Bob Nystrom 00:17:24 Await. Oh yeah. I could spend a lot of time talking about that
Gavin Henry 00:17:27 And isolate basically concurrency. That’s a nice sentence. The concept of async await an isolate based concurrently while the heck are these, why are they important for user interfaces?
Bob Nystrom 00:17:40 So, they’re fairly separate from each other, so you can have one without the other. So, Dart has these things called isolates. I don’t know where that word came from. I don’t know if it exists outside of the ecosystem, but they are concurrency primitive, right? So, there are ways of having multiple threads running truly concurrently without having the complexity and the overhead of thread synchronization. Right? So, concurrency is in a lot of ways kind of like the holy grail of programming languages, where it doesn’t seem like anyone has found a silver bullet for how to let people use multiple cores effectively in a really nice usable programming paradigm, right? Like it seems like every model for concurrency has downsides and isolates is one approach to that. So, the way isolates work is you can think of each of them is each isolet is essentially a separate little Dart program that is running concurrently with the main Dart program. And it is running truly concurrently on different threads. So, it’s just each isolate is going off doing its thing. And then we have these things called ports that let you communicate between them. So, you get the performance benefits of multithreading, but you don’t have the maintainability nightmare of shared memory multithreading. So, each isolate has its own heap and they’re not allowed to directly access each other’s memory. So, you can’t get races and concurrent updates and all those sorts of nightmares that you get. If you do raw low-level threaded programming,
Gavin Henry 00:19:04 A really good explanation. Cause I just thought of them as threats, but they sound more like message passing Octa.
Bob Nystrom 00:19:12 Yeah. They’re almost more like processes and in particular they end up not feeling quite like actors because I think the blocking model is a little different, but they are their actor, like two, they’re kind of similar in that way,
Gavin Henry 00:19:24 Thinking like how are along? And it looks artsy things and how it go, good routines work.
Bob Nystrom 00:19:31 This is probably a pretty good way to think about it. They’re a little different from like go and go routines because go routines will block. Right? So, if you, if you send something to a Gerber gene, you will pause until the other thing is ready to receive it. If it’s unbuffered, I believe I’m not a go programmer. Whereas isolates, they run, they really do sort of run concurrently and you can’t really like get them to sort of halt their sort of you can throw stuff at them, but they will sort of run on their own. So, they feel less kind of coordinated and coupled together then something like code routines would.
Gavin Henry 00:20:05 And is this something that Dart and flutter just doing the background or is it something you have to think about and create isolates and
Bob Nystrom 00:20:13 It is something you have to think about. So, you, you asked earlier, like how does this tie into sort of being optimized for UI programming? Yeah. So, one of the other things that is interesting about UI programming and in particular UI programming on mobile devices is that your goal is an implementation is not just to like get as much done as fast as possible, right? You need to be able to break up the work that the programming language does into small enough pieces such that you don’t drop frames. Right. So, it’s not just like like a Java server program is doing this giant batch of work over a terabyte of data. And once it’s done it quits and then you’re just all I care about is the total execution time. If you’re running on a client device, you care about not just the total execution time, but the incremental performance, right.
Bob Nystrom 00:20:58 And especially on a mobile device where users expect to be able to touch and drag stuff at 60 FPS and not drop frames that kind of incremental performance matters. So, it comes into play with concurrency because you have one thread that is drawing receiving user input and drawing a UI. And if you do any expensive computation on that thread, you will stop the UI. Right. You’ll stop the UI from updating and the user experiences that has jank and dropped frames. So, having some level of concurrency, like isolates gives you a way to take long running computation and push it onto another thread so that the UI thread can keep running and keep updating the UI.
Gavin Henry 00:21:35 And that’s why you would need to be in control of that because you’re telling the system what it’s going to take awhile.
Bob Nystrom 00:21:41 Yeah, yeah. In practice you sort of need to know which things are computationally heavy. And then because isolates each have their own memory and they don’t share access to memory. Usually if you’re doing some heavy computation, that means you’re doing some combination over some data and you also need to think about okay, how do I make sure that it’s the isolate that has that data and that I’m not just burning a bunch of time sending data back and forth between them two.
Gavin Henry 00:22:04 And how much control do you have from the OSTP level, because we’ve spoken about not having control over the hardware. Cause that’s the point of client optimized. But if we’re putting things in these isolates, because it’s taking a while, what’s the risk of the operating system, killing them off.
Bob Nystrom 00:22:23 That’s a good question. I don’t know.
Gavin Henry 00:22:25 I mean, how long it just depends on what you sell on your phone and I suppose what Android being tweaked on or what iOS is doing.
Bob Nystrom 00:22:33 Yeah, I guess so this is outside of my area expertise. Sorry, I don’t have a good answer, but this is something that so the Dart, the Dart implementation the VM that that we have that that flutter contains basically implements isolates in terms of the threading primitives that the underlying OS gives it. Right. So, on Android, it will use the threading model, then Android provides an iOS. So, it’ll do the same thing. And in principle, it’s the BMS job to hide the differences between those OSS as much as possible. So, that Dart programmers just see this high-level isolate concept and things work the way they expect in practice as I’m sure platform detailed to leak through, right? Like you can’t always encapsulate that stuff. Yeah.
Gavin Henry 00:23:15 There’s usually some copy of it. Isn’t
Bob Nystrom 00:23:17 There, there’s all these caveats, right.
Gavin Henry 00:23:19 Just point out to the listeners, not because we’ve been talking about flutter, which is generally to make up for an iOS device or Android device, or you can put it on windows or Linux. That’s just why it was talking about iOS and Android there. Because when I think of Dar, I think of those two platforms when it works on lots of different platforms.
Bob Nystrom 00:23:40 Yeah. I think the large majority of our users now writing Dart code or end up running it on Android and iOS devices and then a decent fraction of them running on the web with their Dart code compiled to JavaScript.
Gavin Henry 00:23:50 We’ll stick to those two, if something else comes up and how does this relate to async wait, does that
Bob Nystrom 00:23:57 All man? How much time do we have?
Gavin Henry 00:23:59 Well, we’ve gone maybe three minutes before I need to move on to the next section. So, I should probably, yeah. Five word answer for that one.
Bob Nystrom 00:24:07 So, because isolates are running concurrently and you don’t want to block them, you need a way to send a request to another isolate and then have the code pause until the response comes in and async await gives you a nice syntax for doing that so that you get asynchronous code that looks like blocking synchronous code.
Gavin Henry 00:24:28 So, people haven’t used Dart, maybe cause that’s where they’re listening to this. Or they want some more in-depth information. The language keywords await an async correct me here basically sort of rap a block of code and you define it as something like that away. An answer behind the scenes is that firing up some concurrency there, or
Bob Nystrom 00:24:51 It’s a little complex. So, the async keyword basically just says, it’s a modifier. You put on the function that says in this function, I’m going to be doing stuff, using a weight, sort of opting into that. And then when you use the await keyword, it’s a marker that you put on an expression. What it does is it basically splits the body of the function in half at that point. And it takes everything after the await and wraps it in another closure. And then it says, evaluate the expression that I’m awaiting for and then unwind the entire call stack back to the scheduler. And then when the thing that the, that I’m awaiting on the expression, that I’m the value that I’m waiting for when that comes in, at some point in the future run the remaining body of that code, which has now been moved kind of into a separate function.
Bob Nystrom 00:25:36 The technical term for this is it’s doing something called it’s transforming the, the body of the function into something called continuation passing style, which doesn’t mean a lot to people that are not compiler people. But basically what it lets you do is it lets you have multiple pieces of code that are kind of idly waiting for responses. Let’s you have all those kinds of sitting out there pending without taking up the memory and the resources of having a hardware thread. Because what happens instead is that the call stack can unwind for those. And you just have closures that are waiting to be evaluated at some point in the future.
Gavin Henry 00:26:09 Sure. That was a brilliant explanation of how deep that was. But with the async stuff, when we’re talking about wrapping something and async be a way is an option, isn’t it? Because you might just want to run the, and not caring about the result, but you can use that key word away and say, actually I want to wait until that complete.
Bob Nystrom 00:26:30 Yeah. So, you can always just fire off an asynchronous operation and not wait for the result and then keep executing.
Gavin Henry 00:26:36 Yeah. So, is that similar to what you’d think of a promise and JavaScript?
Bob Nystrom 00:26:40 Yeah. So, Dart didn’t always have async await as native syntax. It used to just have an API called futures. And if you ever wanted to do any asynchronous programming where you were waiting on file IO or networking or something, what you would have is like the low level APIs that you would be exposed whenever you requested something like give me the contents of this file. You would get back a future, which is an object that you can give it a closure and it will invoke the closure later when the value appears. And if you did any asynchronous programming in Dart, that’s the API you’re using, you were just dealing with futures directly. The futures are 95% identical to promises and JavaScript is different name for the same concept and more or less the same API.
Gavin Henry 00:27:22 Yeah. I’ve seen those in some docs and example to voice sound, normal safety. And why do we need that in the user interface?
Bob Nystrom 00:27:31 Wow, that’s a great question. So, no safety in general means using the static type system to keep track of which variables can contain Knoll and which ones can’t. And the reason you do that is if you try to call a method on Knoll, that’s going to throw a no pointer exception in most languages and that’s bad to runtime failure. So, if you have no safety, what you can do then is the static type system can prevent those errors. It can tell you, it can basically turn those into compile errors where it says, Hey, this is a place that you could be calling a method on Knoll and it will make that an error. So, Dart has that a few other languages out there have it now sound Knoll safety when a type system is sound. What that means is that the language guarantees that there’s no way for a running program to violate the rules of the static type system. So, in the case of no safety, it means if a variable doesn’t allow Knoll, the type system promises that you will never ever see no in that variable. What’s nice about that is it means that the compiler can optimize based on those assumptions. So, we can use neural safety, not just to help find user bugs, but to generate faster, smaller code to,
Gavin Henry 00:28:37 Okay. But you also need to know about now safety when you’re doing things, but the, the gear is pretty good. Andrew understood with a Dart analysis tool has pre hard sweats off. I’ve managed to switch off. Cause I haven’t got time to update some of my work, but it does complain a lot. Okay. So, what is a spread operator and is this unique to Dart?
Bob Nystrom 00:29:00 That’s a great question because I designed the feature that added that to Dart. So, it’s not unique to Dart. So, the spread operator is a way of inside a collection, literal like a list literal or a map, literal something, you’re building a whole list of stuff. If you already have another list and you want to unpack it in place in that list, the spread operator does that. It says, okay, take the contents of this inner list and kind of unwrap it and splat it out in the middle of this new list that I’m creating. So, it gives you a really nice short syntax for basically flattening nested lists. It’s not unique to Dart. JavaScript has them Ruby. I think Python does to most of the scripting languages either have them or end up getting it some point,
Gavin Henry 00:29:41 It sounds similar to like when you slice something, put some of that back. Okay. What is collection? And again, is this unique to Dart?
Bob Nystrom 00:29:50 So, collection if and collection for, if you’re going to get to that, they, as far as I know, they actually are unique to Dart. And these are the three features that I designed a couple of years ago. And they all work within the context of collection liberals. So, collection, if let’s you do something that looks like an if statement in the middle of like a list literal or a map literal, and then basically when that condition is true in the, if, then it will create the element that is after that. If right. So, if you have if it’s Tuesday add this element, then only on when it’s Tuesday, do you get that element in the list? That doesn’t sound super interesting, but it ends up actually being pretty useful when you look at flutter code because flutter builds UI using vanilla Dart code, it doesn’t use a separate template language or some other declarative language.
Bob Nystrom 00:30:38 A lot of flutter code is these very large expressions, deeply nested containing lots of big lists, literals you’ll have lists of children for many different things. And it’s pretty common to like in the middle of this big nested ball of flutter code, be oh, I actually only want this button some of the time. Right. And being able to do an if directly inside that, that list literal, lets you kind of put that logic in there will keeping the declarative structure or the surrounding code instead of having to move that out as like an imperative, like if whatever list dot, add this thing
Gavin Henry 00:31:10 And there’s this because flutter is a hierarchical tree structure of widgets. So, I’m sorry. My judge would only need to be part of the big list of widgets F sorry, condition, right? Yep. Cool. Until the next session. So, this is number two of the three that’s on the website and it’s called productive development. So, one of the top things that Dart lists as a major win is productive development. So, we’re going to explore that. You’ve already mentioned this 10 minutes ago, but why is hot reload and how has that achieved?
Bob Nystrom 00:31:41 So, hot reload is this thing that the Dart virtual machine supports where you can make a change to your source code, body of a function, whatever. And while the program is running either locally on your computer or on another device, and it will update the running application with your changed code, right? So, you can change the body of a method and it will replace it in the running application. And then the program will immediately start executing your change to code. You don’t have to restart the application and you don’t, none of the applications state gets reset. So, imagining you’re working, imagine you’re working on a flutter app and you’ve navigated 20 screens deep into some settings, UI or something. And then you’re oh actually that’s the wrong color. You fix the color, which is some Dart code. And you immediately get the change in your running application and you’re still on that same screen. Right? Like you don’t have to re navigate back in. Yeah.
Gavin Henry 00:32:31 I’ve found that when you really break in your stuff, sometimes you do have to restart that because you’ve broken something way up.
Bob Nystrom 00:32:38 So, there’s restrictions if you change the layout of a class, right? Like adding fields, things like that, where existing memory
Gavin Henry 00:32:46 Would potentially get reinterpreted in strange ways. There’s places where it is too big of a structural change for it to update it in place. And you have to, yeah. You mentioned that that’s achieved because thought runs in a virtual machine. We’re going onto another bit. I don’t want to jump too far ahead, but that’s basically how it runs. Isn’t it? The machine starts and then loads your code. Okay. Can we use that hot reload technique of feature and non user interface?
Bob Nystrom 00:33:14 That’s a good question. I believe so, but I haven’t tried it myself and I don’t know much about it.
Gavin Henry 00:33:20 I’m thinking about in production upgrades, but when you don’t need to restart the server side stuff.
Bob Nystrom 00:33:29 Oh, that’s interesting. That’s an interesting use case.
Gavin Henry 00:33:31 I still like how her Alon works. Yeah.
Bob Nystrom 00:33:34 That is like Earlings bread and butter. Right. Is the ability to hot patch live executable. I think we generally think of hot reload as a development time, a feature and a productivity feature and not a deployment feature.
Gavin Henry 00:33:47 I don’t think it would happen in persistence. Would
Bob Nystrom 00:33:49 It? Yeah. So, I don’t know how it persists. And then I don’t know if it works in the context of an optimized build, right. It may only work in development slash debug mode. I could be wrong. This is also not my area of expertise.
Gavin Henry 00:34:07 Okay. So, we’ve touched about this next bit slightly when we’ve spoken about dynamic and static types, which means Dar has a flexible type system, how kind of type system be flexible?
Bob Nystrom 00:34:20 Oh man, that’s a really good question. The static type systems they’re conservative, right? So, a static type system sort of by definition, it will report a compile error. If it thinks that the program could do something bad at a particular location, if there’s any way for a bad thing to happen, that’s a compile error, right. In practice, many programs are dynamically, correct. Like it wouldn’t actually add execution time, do the thing that causes that error. But the satellite type system doesn’t know that. Right. So, static type systems yell at you about some subset of programs. That actually would be fine if you just shipped to them. Right. And that is frustrating for users, right. Because they know their program actually does run. Right. But the static type system, the compiler won’t let them run it. So, being a sort of flexible, usable, static type system means having the type systems rules expressive enough that most of the programs that users know are correct. Don’t have compile errors and they’re able to run them, but
Gavin Henry 00:35:21 You could pick and choose between them or run them together in your code. So, you could opt to say right. Everything I’m going to do, it’s going to be stock tight.
Bob Nystrom 00:35:31 Yeah. So, you can also try to have a mixture of static dynamic time. So, you could have part of your program just be dynamically typed. And oh man, it was a long discussion we could have about that. But there’s just been a lot of academic research into different ways to have a mixture of dynamic and static types in a single program. There is gradual typing, optional typing. It gets really, really complicated and there’s a lot of difficult trade-offs there. So,
Gavin Henry 00:35:57 But would it come by to what you said before with the sound? No safety, but if you thought about everything and did start at types, you could potentially make it faster for yourself if you profile it or
Bob Nystrom 00:36:10 Yeah. So, that is part of the trade-off right. So, anytime you step outside the bounds of the static type system and you rely on dynamic typing, there is a performance hit, right? There’s a reason that Python and Ruby tend to be slower than Java and C plus plus. Right. And a big part of that is the static types.
Gavin Henry 00:36:24 People talk about this a lot my question star tick, do you have any order of magnitude or numbers as this millisecond, slower seconds hours, does it just depend on what you’re doing without code?
Bob Nystrom 00:36:38 It’s a good question. It’s
Gavin Henry 00:36:40 When you get worried about all this stuff analysis paralysis as you call it.
Bob Nystrom 00:36:45 Yeah. I mean the, the trade-off between dynamic and static typing is super complex, right. Because there are trade offs at every level, right? Like there’s performance trade-offs, there’s implementation complexity. Trade-offs there’s like ecosystem level trade-offs there’s learnability trade-offs. And when a language is designed, it’s designed holistically around its choice of type system. Right. So, it’s not like it’s hard to find ways to make fair comparisons about performance between a dynamically type language and a statically typed language because they are different languages outside of just their type system. Right. So, there ended up being kind of a lot of confounding factors. If you’re trying to just figure out like how much faster is a static type, I don’t have good numbers, but I’m confident that static type systems overall sound static type systems do let compiler authors generate faster code than dynamically typed ones.
Gavin Henry 00:37:36 Yeah. I think you touched upon some of the other reasons like we’re thinking about JavaScript and how popular TypeScript is potentially makes things faster, but also you don’t have to think too much about tracing where things are going because it was this before and now it’s not, yeah.
Bob Nystrom 00:37:54 There’s a whole lot of productivity improvements when programming in the large, if you have static type systems, right? Like if you have types, then it means your IDE has a much richer understanding of how the program is connected to each other different parts of it are connected to each other and it can reflect that back to you. Right? You get code navigation you get automated refactoring you change the signature of some method and it will tell you before you run any code, all of the call sites that got broken by that. Right. So, there’s a lot of, kind of large-scale maintainability of benefits that you get when you have types.
Gavin Henry 00:38:25 Cause you’re mainly involved in the backend world. I suppose what’s the tooling like for us mortals, with regards to rich star tech analysis, powerful and configurable tooling, as the website says,
Bob Nystrom 00:38:40 I think we have a great IDE story. You know, I spend most of my time writing Dart code, I use intelligent because most of my stuff is running directly on the command line. But our static analysis framework is designed to be pluggable into a whole bunch of different ideas. So, it works in Android studio. We have vs code integration. I think there’s stuff for Emacs and VIM. And I think it’s solid. I’m pretty biased. And I also I don’t spend a ton of time in modern Java and C plus plus IDs, but we have all the stuff that and expect, right? Like we have a rich set of compile errors. We have all the code navigation you want go to definition, find, call sites, all that stuff. We have automated refactoring. We have a linting framework that we ship with and a lot of links that are based on static analysis that will help you find common mistakes or help you write more idiomatic code. You know, we try to make the language as productive in your editing environment, even before you run code, as we can
Gavin Henry 00:39:37 Totally agree with that. I’ve been doing flora and Tara two and a half years. And I just like right. Clicking and doing Dar farmer and refi to all of that without having to think too
Bob Nystrom 00:39:48 Much, having an automated formatters. Nice. Yeah. And just
Gavin Henry 00:39:51 Kill them with that. So, it doesn’t have out of the box profiling, logging and debugging as well.
Bob Nystrom 00:39:57 Yeah. So, it ships with the debugger and you can debug all kinds of start applications, command line web stuff. We have four web developers in Dart. We have two compilers to JavaScript. One of them will compile to a very optimized shippable deployment JavaScript, but then we have a separate one that compiles to a more readable modular JS that is a little more debug Hubble and then also have Sourcemap support so that you can in your browser step through the Dart code. Yeah. We have a nice profile or integrated with a nice UI for it. So, it will do flame graphs and all that stuff. So, you can see where your time’s going. Yeah.
Gavin Henry 00:40:31 I’ve seen that. And that’s really nice. Is there something special about Darla makes all that easy
Bob Nystrom 00:40:38 At the language level? Not really. You know, one of the things I find really interesting about being on a language is like so much of language success is just work, right? It’s just engineering. You just like built all the tools and wrote all the libraries and tested all the things. And one of the things that’s like a real luxury on the Dart team is we have a large amount of like real deep compiler and VM experts and we’ve sunk a lot of time into it. Right. So, we just have a very mature JIT. Just-in-time compiler a really mature VM debugger profiler ahead of time, compiler to native code, extremely mature Java script compilers. Like we’ve just we’ve been working on the language for about a decade and we just, we just sunk a lot of time into it.
Gavin Henry 00:41:24 How many people work on Dart? Do you know? Oh
Bob Nystrom 00:41:27 Man, I don’t know.
Gavin Henry 00:41:29 I think Tim said there’s a lot. Yes.
Bob Nystrom 00:41:34 I don’t know the exact number. And if I did, I don’t know if I’m allowed to say the exact number, but more than a few and less than a ton. Yeah.
Gavin Henry 00:41:42 I think you was someone around a hundred or over or something like that. I was quite a lot is in the show public knowledge. So, I’ll take that. Right. I’ve got movers onto the last section, which is the third benefit on the website, which says fast on all platforms. So, in this last section, I’d like to close off the show, talking about speed and how Dart can run on lots of different platforms. Do you know of a good place to get some numerical data or public benchmarks or what do we mean by fast is our frames per second? Or how do we understand
Bob Nystrom 00:42:21 It is all things. So, one of the things that’s interesting about being a client oriented language is that performance is a multi-dimensional right? So, we care about throughput just how much overall computation can we do while the program’s running. But we also care about latency. You know, how much can the program avoid pauses? And in particular garbage collection pauses, we care about startup time because users expect client applications to immediately be responsive. We care about memory usage. We even care about code size because download size really does matter, especially for users in developing countries where the internet infrastructure isn’t as strong performance for us means like all of those things. Okay.
Gavin Henry 00:43:02 And fast cars also also mean productive. You can go in with a fast as well. And how does it monster run on lots of different platforms,
Bob Nystrom 00:43:11 Man, we just did the work. So, the Dart team was started by a bunch of people that were senior people on the VA team. VA is the JavaScript VM in Chrome. And we have we’ve acquired and built a bigger team beyond that over the years. So, we have a lot of people that just have decades of experience with virtual machines compilers, and we’ve just put a lot of time into it, you know? So, it’s interesting. There’s if you look around at other languages, you can find a lot of languages that have mature native code compilers C plus plus swift languages like that. And you can find languages that have pretty mature compilers to JavaScript like TypeScript, but there are fairly few languages that have mature versions of both of those. Usually what you see as the language has a really good native compiler and a JavaScript compiler that is kind of a work in progress and it works, but is maybe not super optimized or the other way around where the language is mainly a web language, but then they’re starting to add native support and Dart is one of the few languages where we’ve, we’ve been actively working on and maintaining both of those for about a decade at this point.
Bob Nystrom 00:44:20 So, they’re, they’re both just pretty solid we’ve shipped lots and lots of big apps on them
Gavin Henry 00:44:25 Is that because that’s what you need those platforms for it to run on our external demand in the community,
Bob Nystrom 00:44:32 Both so we Darts initial pitch was to be a web language. And our initial goal was to get browsers, to support a Dart virtual machine natively. So, have them integrate native Dart support and to get there that meant that we needed to be able to compile the JavaScript for browsers that didn’t have that support yet. But then we also wanted a sufficiently sophisticated VM that it would be compelling to browser vendors to integrate the VM. So, we needed to have both mature JavaScript, compilers and a mature VM. We ended up not going down that path for lots and lots of complicated reasons, but the end result is that we have pretty mature compiler technology across a range of platforms.
Gavin Henry 00:45:11 Cool. Can be combined to lessen or interrupt with it was M however you want to,
Bob Nystrom 00:45:19 It’s a really good question. I don’t know the exact current status of it. I know that we’ve been researching it. We can have a longer discussion about whether or not targeting miasm is a good idea versus targeting JavaScript. And I’m happy to talk about that at length, but the short answer is that we have put time and research into compiling . But as far as I know today, the best language to target in a browser is JavaScript for language like Dart Dart has a garbage collector. So, we need to if we compile Dart , then that means we have to ship a garbage collector with every application. And then we have to deal with the interaction between that GC and the garbage collector in the JavaScript VM. Whereas if we compile to JavaScript, all that just works, be essentially get a really nice mature GC for,
Gavin Henry 00:46:05 Yeah. Thus, remind me of a question I was going to ask when we were talking about different platforms in your experience as a language developer or the differences between garbage collection across different languages.
Bob Nystrom 00:46:19 Yeah. That’s a thing, right? Like there are people on this earth that spend their entire careers becoming garbage collection experts, and there’s just a wide range of ways to do it. It’s like any interesting technology where there’s no silver bullet. There’s no perfect solution. Yeah. There’s no standard because every solution has trade-offs. Right. Which makes it a really interesting field. Right. Because it, that’s the kind of stuff that is fascinating to me because if once you can solve it, then it loses interest. Right. But GCs or something where yeah, there’s just lots of different ways to do it. Each of them have their pros and cons.
Gavin Henry 00:46:54 The reason why I asked those, cause I was wondering if it’s a choice between, do I use a language, even if it has this option to manage my own memory or go for a language that have garbage collection, but then you have to actually think how good is that garbage collection in that language? Don’t you?
Bob Nystrom 00:47:13 Yeah. And over time I remember when Java came out and I was programming and CNC plus plus at the time. And I remember people being yeah, a job is never going to catch on because like garbage collection is too slow, right. It’ll just never survive. And that was maybe true ish at the time, but GCs have gotten better and better and better. And the the set of programs where GC is still too slow to be feasible is getting smaller every day. And these days I think, I don’t know, 90% of the world’s programs can happily be written in a garbage collected language and still be perfectly good from the user’s perspective in terms of like performance and stuff. And honestly, I love programming in a managed language, right? Like that is for my experience probably top two or three productivity improvements that I’ve ever experienced as a programmer is just having GC.
Gavin Henry 00:48:07 So, we touched on AOT before ahead of time compiling, how does AOT compile ops to native machine code for Dart?
Bob Nystrom 00:48:16 Yeah. So, it’s funny that we talk about it as AOT. Like that is a important modifier, but like most users just think of it as compilation, right? Like, so a C compiler, a rust compiler, that’s doing AOT compilation. It just means take the program, compile the whole thing to machine code and be done with it. Right. We talk about it as AOT for Dart because Dart doesn’t only have an ahead of time compiler. We also have a just-in-time compiler, which means it works more like JavaScript or scripting languages where your program, you immediately run from source and under the hood, it is compiling it to machine code on the fly.
Gavin Henry 00:48:50 That’s why we could do so many different things with Garmin.
Bob Nystrom 00:48:53 Yeah. That’s why we can do things like hot reload and stuff like that.
Gavin Henry 00:48:56 And can we build static binary?
Bob Nystrom 00:48:59 Yup. Now in compile fully to a fully native machine code executable
Gavin Henry 00:49:04 And just ship that cloud native style onto anything. And I don’t need to manage my own memory.
Bob Nystrom 00:49:10 Nope. It will include the runtime and it you can think of as compilation models, very similar to go, right? Like go has a garbage collector and a runtime representation, but it compiles to a static executable. And what it does is it just bundles that entire runtime in with your executable. And when you head of time compile the Dart program does the same thing. So, it just sticks to the GC and the other machinery needed for object representation in there.
Gavin Henry 00:49:33 And what tool in the ecosystem creates JavaScript from Dart.
Bob Nystrom 00:49:38 So, it ships with the Dart STK, we have two compilers to JavaScript. One is called Dart to JS very innovative name and the other one, I think internally we tend to call it DDC, but I think Dart dev C is the external name. And that’s the development compiler. So, Dart to JS is a whole world optimizing compiler that tries to make your JavaScript as small and fast as possible so that you can deploy it. And Dart dev C is more like an incremental, modular, debug compiler where it compiles quickly to fairly readable JavaScript code. So, while you’re iterating on your roadmap, you can kind of have a nice fast iteration cycle and you can step through the code and kind of read it and figure out what’s going on.
Gavin Henry 00:50:19 Excellent. There’s two part question here to do JavaScript. So, why use Darwin TypeScript exists for JavaScript use case? So, if you just want to spout Thomas and does this mean if I use type safety and compile to JavaScript. I don’t have to have a use type script if that makes sense.
Bob Nystrom 00:50:41 So, the second part is the easier one to answer. Yes. If you want a statically typed language that compiles to JavaScript, you can use Dart and it will give you all the benefits of static types, right? For the former question of why you might, you prefer Dart over TypeScript or vice versa. I think so TypeScript is an incredible language. Anders Hillsburg the designer is one of my heroes
Gavin Henry 00:51:03 I’ve actually never used it. It’s just, I know what it is and I’ve read about him, but I’ve never actually cramped,
Bob Nystrom 00:51:09 Super cool it’s success as well learned. So, I think if users are happy with TypeScript, I’m happy for them. If users are happy with Dart, I’m happy for them. I think TypeScript is an excellent fit. If you already have a bunch of JavaScript code, because TypeScript makes it very, very easy to incrementally convert your JavaScript code over to TypeScript. And it was designed entirely around that goal. Right? And it, it, it nails it, but there are real downsides about that. Right. Which is that because of that, it’s very semantically close to JavaScript, right? It has this high affinity and there’s a lot of stuff about JavaScript that a lot of people don’t like it, it can be verbose in ways. It has semantics. That can be strange things like loose binding of this. And the hoisting and scoping can be weird and it’s gotten better over time.
Bob Nystrom 00:52:02 But there’s a lot of people that don’t like JavaScript and many of the things people don’t like JavaScript are also still true in TypeScript, right? Because it is designed to be so seamlessly convertible from JavaScript. And the other piece of that is that taking an idiomatic JavaScript library, which was not designed for static types and applying a type system to, it requires a really sophisticated, rich, complex static type system. And if you like types, that’s super cool, right? Like TypeScript has all the type system features. And it’s really interesting, but it’s also really complex. It has a very complicated type system. It can take a long time to learn and it can enlarge programs that can take a long time to type check just because there is a lot of machinery going on under the hood there, the type system may actually even be touring complete.
Bob Nystrom 00:52:53 So, there is a cost there there’s a cognitive load to a type system of that level of complexity. Whereas Dart is more of a sort of clean slate language, right? Where if you are starting a new program from scratch and you want a language that feels like it was sort of holistically designed around static types. And it was designed in a environment where it could learn from the mistakes of JavaScript and get, be simpler and easier to understand because of that, then Dart is a good fit for that, right? Like I think Dart is a simpler language and easier to learn language, an easier language to fit in your head.
Gavin Henry 00:53:27 I’ll just close off this last section. I’ve got a couple of other questions. I think we’ve got time for it as well before we wrap up. But do you have any tips for the heart to define where at fast Dart, do we always use types for that? Or was there any rules of thumb?
Bob Nystrom 00:53:45 Yeah. So, in general, avoiding the dynamic type is going to help. But for the most part, your Dart code is already not using the dynamic type it’s most of the time using type inference and giving you the correct static type anyway. So, you don’t usually have to think about that very much. I think about my job as a language designer, as making the code that feels natural for you to write, be the code that is fast, right? Like if I have to spend a lot of time telling you, oh, don’t use this feature even though you wish you could, because it will make your code slow. Then at some level, like maybe we’re not doing our job. Right. And if you talk to like the VM people in the compiler people, they will sometimes tell you tips and tricks of oh yeah, this idiom happens to be slow right now.
Bob Nystrom 00:54:30 But I think overall, they don’t want you to have to sort of make your code more convoluted to satisfy the compiler because their job is to look at the code that people are naturally writing and make that code go fast. Right. So, overall my hope is that most users don’t have to think about that too much, right? Like write the code that feels simple and elegant to you. And our job is to make that be fast enough and then use the profiling tools that we ship with and look for hotspots. And if you do find hotspots, then in those places, maybe make your code a little more verbose or weird in some patterns that make it faster.
Gavin Henry 00:55:05 No, it just highlights that the tools are there for when you need to do the old, make it work, make it right and make it fast. I think that’s the, a couple more questions then I’ll, I’ll wrap up. Will Dar ever become a standards based language? Do you think
Bob Nystrom 00:55:23 We do have an ECMO standard? I think the current state of the languages ahead of the most recent ECMO version of it, when we initially designed the language, the original goal was to be a web language supported natively by browsers. And that does mean that you need a standard, right? So, that browsers can be compatible with each other. So, it was something that early on, we pursued really strongly now that we are not trying to be natively supported in browsers. It’s relatively less important for us to have an open third-party official standard. It’s still valuable and it’s still a useful thing to do. But what users are asking for from us right now is language velocity, right? They want us to change the language quickly, add new features make the language more productive for them. They’re asking for that more than they’re asking for standardization. And that’s kind of how we’re prioritizing. At some point, I could see us getting to a state where if there are multiple independent implementations of Dart and compatibility is becoming an issue, then users will prioritize having an official standard more than language philosophy. But I don’t think that’s where we’re at in the lifecycle of the language right now.
Gavin Henry 00:56:29 Yeah. I suppose that comes down to someone else’s writing to compile on my far to machine. Then you kind of need a standard toward
Bob Nystrom 00:56:36 Yeah. And in particular, if you find yourself in the situation where you have multiple competing implementations from antagonistic companies, you really need a standard so that you can avoid the embrace extend extinguish failure mode. Right. But we’re not in that state. So, exactly.
Gavin Henry 00:56:53 Is there any ambitions for flutter on the desktop to replace like electron? It’s not a thing.
Bob Nystrom 00:57:00 That’s a good question, I suppose, is the question of ambitions for whom? You know, I certainly think that lots of people on the Darton flutter team hope that we can make desktop support for Dart compelling enough that people that would maybe consider electron for some apps would end up choosing Dart instead. And that’s, that’s definitely a goal, but in general, like I don’t personally think of myself as a very competitive person. I like the idea of just giving people more choices and options. And what I hope is that we can make Dart on the desktop, something that enables some set of people to make applications that they feel worried about. And if that, whether that means more or fewer electronic applications, I don’t care too much. I just want to make cool stuff that lets other people make cool stuff
Gavin Henry 00:57:42 Well, should want to be worried about Dart going away, Google stops flutter or something like that, or is it pretty long in the tooth now?
Bob Nystrom 00:57:52 And this is the question that comes up all the time.
Gavin Henry 00:57:54 It’s always the one with go or anything, maybe kubernetes,
Bob Nystrom 00:58:00 But it’s valid though. Right. You know, it’s a valid concern, right? Like when you are learning a language, there’s a real investment of your time and energy that you don’t get back, right. That you could have spent investing in some other ecosystem. Right. So, it’s totally reasonable for users to want some reassurance that their investment is going to be amortized out over a long period of time. Right. So, I get where they’re coming from. I can’t make promises, but I every signal that I’m able to see is that Google cares very much about Dart. You know, the team is bigger now than it has ever been. The investment in Dart is larger now than it’s ever been. We’ve been around a decade, which is half of Google’s existence. A third of Google’s existence.
Gavin Henry 00:58:44 Yeah. That’s a good point. I forgot about when people talk about the age of go and other things that you need to put it in the context
Bob Nystrom 00:58:53 That old, right.
Gavin Henry 00:58:54 That’s true. I think that’s enough of a political answer that we can dig into. I like that.
Speaker 0 00:59:02 Have you ever really been happy with your project management tool? Most are too simple for growing engineering team to manage everything or too complex for anyone to want to use them without constant product shortcut, formerly known as clubhouse is different though, because it’s worse. Wait, no, we mean it’s better. Shortcut is project management built specifically for software teams. It’s fast, intuitive, flexible, powerful, and other nice positive adjectives. Let’s look at some highlights. Team-based workflows, individual teams. Can you shortcuts default workflows or customized them to match the way they work org-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. It takes one click to move from a roadmap to a team’s work to individual updates and vice versa type VCs integrations. Whether you use get hub, get lab or Bitbucket shortcut ties directly to them so that you can update progress from the command line. The rest of shortcut is just as keyboard friendly with their power bar, allowing you to do virtually anything without touching your mouse. Throw that thing in the trash iterations, planning. So, weekly priorities, and then let shortcut run the schedule for you with a company in burndown charts and other reporting. Give it a try at shortcut.com/se radio. Again, that’s shortcut.com/jesse radio shortcut again, formerly known as clubhouse because you shouldn’t have to project manage your project management.
Gavin Henry 01:00:14 Great. Let’s wrap this up. So, obviously Dart is a very powerful language with a strong, enjoyable ecosystem. But if there was one thing a software engineer should remember from our show, what would you like that to be?
Bob Nystrom 01:00:27 I hope that they check out Dart and that they find that it’s a language that’s really enjoyable for them and makes it fun for them to make applications.
Gavin Henry 01:00:36 And is there anything that we missed that you’d like to mention that you expected to come up?
Bob Nystrom 01:00:41 Not that I can think of. No, I think you did great.
Gavin Henry 01:00:45 I think we had a good ad hoc chat about certain things that came up on a good structure. So, I really enjoyed that. Thank you.
Bob Nystrom 01:00:52 Yeah. Thanks for having
Gavin Henry 01:00:53 Me. Where can people find out more? We’ve got your Twitter account. Yeah.
Bob Nystrom 01:00:58 So, dart.dev and flutter.dev are the main entry points. My Twitter handle is munificent Bob, unfortunately munificent, which is my github name was not available on Twitter, whoever that is, who got it first, but really dart.dev in flooded out to everywhere you want to go.
Gavin Henry 01:01:16 Thanks. So, Bob, thanks for coming on the show. It’s been a real pleasure.
Bob Nystrom 01:01:23 Listening. Yeah. Thanks for having me.
Gavin Henry This is Gavin Henry for Software Engineering Radio. Thanks for listening.
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
Thank you for sharing this episode about Dart! I learned a lot about it and am now potentially interested in using it for a project in the future