Transcript
Williams: Welcome to the 21st Century Languages track. We're going to do a panel and we've got a bunch of awesome people here. We are expecting one more person, so we've made an asynchronous fetch for that fellow. But we'll have some eventual consistency with there being four panelists here. So my name is Ashley Williams. I am on the core team of Rust, but for the purposes of this panel I am going to be asking the tough questions.
This is going to be more like a fireside chat level of professionalism, which is totally fine. Keep it cozy. I have a couple of questions prepared and I think they require some subtlety to answer, so let's see if they fill up the time. But potentially towards the end, I'll be happy to take questions from the audience. I have one rule. The first sentence of your question must be a question.
Hosfelt: I have a question about that. Can your first sentence be, “Can I make a comment?” Because that's technically a question.
Williams: With an easy answer. With that, I think I'll have our panelists introduce themselves. Diane, would you like to kick us off?
Hosfelt: I'm Diane [Hosfelt]. I work at Mozilla. I'm on the mixed reality team. I work with Servo Rust, different things, privacy, security. I have two cats named Batman and Watson and I'm here representing Rust, I guess.
Cantrill: Bryan Cantrill. I'm the CTO of Joyent. We are historically the company behind Node. js, but let's say that our relationship with Node.js is a little complicated. I am probably not here representing Node though I'm happy to field Node-related questions. I was a little bit sheepish when Diane asked in her talk, who likes implementing in Assembly? I did raise my hand. So I guess I'm here to represent Assembly.
Hosfelt: Hand optimized Assembly. Let's give it a hand.
Williams: This is already going well.
Cantrill: I implement in Assembly, C, and I have a new found love for Rust.
Phelps: I'm Jay Phelps and I'm the co-founder of a company called This Dot. Before that, I worked at Netflix. My primary thing is WebAssembly. I gave a talk this morning about that and I'm on the WebAssembly community group and pretty obsessed with it. So I'll try my best not to insert WebAssembly into every conversation in the panel, but don't be surprised. But I'm a lover of all languages really. I mean I know and use lots of languages and kind of an arm chair compiler enthusiast, I guess I would say. But yes, that's me.
Parikh: My name is Aarti Parikh. I'm an engineering manager at PayPal, six months, newish manager. Mostly worked at startups before that. I've written a lot of Java. I've always been mostly on the application side. And then I wrote a lot of Ruby. Now I'm really excited about Go, because I feel like it's bridging the gap between application and systems programming. All my life, I was like, “Hey, you don't get to work on that stuff,” but I feel like now I can, and you can't stop me because it's easy. So I'm pretty excited about Go because I can do system stuff.
Language Trade-offs
Williams: My first question for you: one of the things I really love to describe languages as, is tools, because it's so easy to forget that that's really all they are. And so when we talk about tools like libraries, frameworks, we always talk about trade-offs. So my first question for you, and you can pick whichever language you'd like to respond for, what would you say is the key trade-off of the language?
Hosfelt: I'll go first because I'm next to you, if that's okay. Also, apparently I'm the only one not sharing a microphone. I'm here representing Rust. And when Ashley said the word tooling, she reminded me of something that I usually insert into any Rust talk that I give. I know that this isn't your question and I'm so sorry, but Cargo is amazing. If I could just pick a language based on its package manager, that's my new bar. The package manager for Rust, it makes my life joyful.
Phelps: And how generic is Cargo? Can Cargo be theoretically used by other languages or is it pretty tied to Rust at this point?
Hosfelt: Ashley, do you know that answer?
Phelps: I'm interested in using Cargo because I love cargo as well. I looked into trying to use it. I know there were discussions about this, but this was probably three or four years ago when I was looking at it. I don't know if there have been any topics or anyone talking about it recently. Just there's so much work, it's such a shame that something so good can't be shared.
Williams: Do you mean you want to put any type of CSS in a Cargo package or something like that?
Phelps: Not necessarily. I just mean that if another language came along, let's say, whatever lang and whatever lang decided, I need a package manager. Could it use Cargo?
Williams: I think there are definitely possibilities for that. Cargo is written in Rust, so you're going to want Rust in there. When you publish stuff with Cargo, Cargo is going to build your package and so it is running the compiler and stuff. But you could configure it. Similar to the way with NPM, you could put whatever you want in an NPM package, you can really put whatever you want in a Cargo package. The question would really be just what do you want Cargo to do in the other ecosystem? Because Cargo is a build tool, a tester, adopt tool, and it uses the Rust compiler for doing that.
Hosfelt: Like I say, it's magic.
Williams: So now that we've talked about package management, just briefly, I am going to redirect back to the question I had, which is, what is the key tradeoff of your language? Second time, Diane, let's do this.
Hosfelt: Sorry, Ashley. I think that a big tradeoff with Rust - we get this memory safety, we get all of this painless concurrency and we have a great type system. That said, it can have a learning curve. Like I said in my talk earlier, I still don't understand lifetimes. If I have to explicitly annotate a lifetime, I just stick static everywhere until it works and then I go to a friend and have them fix it.
Williams: You said the bad part. What's the good part?
Hosfelt: The great part is the rest of it - memory safety, concurrency, the tooling's great, the community is great.
Cantrill: Just speaking for Rust, I would elaborate on that trade off a little bit. Sorry I disagree. One thing I really love about Rust, I have spent more of my life debugging the code of others than writing my own code. That's just the reality of my career as a software engineer. And I kind of want to even the Karmic score a little bit, and the folks I know that have faced production-facing code begin to feel pretty dour and frustrated because they feel like I am constantly ... my pager's going off, because of a mistake that someone else made. You may not try to personalize it and you don't usually, but it does feel like there is this hierarchy and you're at the wrong end of it.
What I really love about Rust is it forces so much upfront that it is so much harder to induce technical debt in Rust. We talk about the memory safety. I actually like the signed extension safety, which is something that, I don't know how much it is talked about. But I mean, anal retentive is the wrong word around signed verse unsigned in terms of Rust is persnickety in the best possible way. You were asking your talk, who can write memory safe code? I can write memory safe code. I'm not standing if you say, who can write code without signed extension bugs? You’ve got to be gutsy to stand for that one, because it is really easy to have signed exception bugs in C, C++ other languages. So I think that the tradeoff that Rust makes, to answer your question, is that Rust forces that cognitive load upfront. It can be more painful for the programmer, but Rust in the end, the artifact that you get is so much more satisfying because so many of these issues have been worked out in advance.
Phelps: I would second that as well. I mean, not to turn this panel into a Rust panel, but to turn this panel into a Rust panel. I agree that Rust is actually a fairly unique language in that respect. Usually the tradeoffs I'm going to talk about, and I think it's good to touch on this, is just the somewhat obvious things, obstructions, right? You add an obstruction into the language itself, garbage collection being probably the most obvious. You pay for that obstruction in some way, whether it's runtime cost or pauses in your application, non-determinism, all those types of things. Usually the differences between languages come down to that more than anything; just what level of obstruction do you get. Whereas Rust, it's very unique in that it is an obstruction about the memory management and lifetimes and safety guarantees on those sorts of things. But it's different. It's kind of on its own category of languages. It is, I think. A really great example when you're talking about these sort of things that you have to learn something in Rust that you won't learn in any other languages. But it's actually a really great thing.
Let me kind of tangent for a second, and I apologize, but I've written a lot of C++ multithreaded code in over the years and I thought I was pretty good at it. Everyone creates bugs, right? I knew that my code has risk conditions. I've debugged my own risk conditions. But when I started learning Rust, it actually taught me about patterns that I had been doing for years that I did not realize were technically not safe, and that there were circumstances. I almost felt like maybe I need to call my old companies and tell them, “You've got some bugs in your code that I've discovered”. And I'm sitting there, I'm not kidding. When I was learning Rust, I opened up the issue ticket tracker to tell the Rust folks, ''Hey, you've got a bug. This is telling me that their lifetime's wrong.'' And I'm telling them, "No, I'm right. I know I'm right." And then I really started to create a minimum reproduction and was like, "No way, I've been wrong this whole time. I've been doing it wrong." It taught me. Tt's challenging. I think sometimes you're going to argue with the compiler and be frustrated, but it teaches you too.
Hosfelt: And the compiler at this point is almost always right. Maybe a few years ago you were finding more compiler bugs, but every single argument I have ever had with the REST compiler, I do not come out on top, unless you consider coming out on top writing much better code than I would otherwise so.
Phelps: But those things you learn. I take it now back to the C++ I write. Even though the compiler is not saving me, my brain is wired differently now. But I'm the same way, I'm not perfect at Rust so there's still plenty of times where I'm like static, static, static, “I don't know what's going on.”
Williams: So we've heard a lot about Rust. Aarti, do you want to give us a different perspective?
Parikh: Yes, this is on. This is a Rust panel and I'm the only one who's doing non-system related programming. I would say that I think that with Go, it's going to be used vastly more than Rust just because listening to them, Go is a simpler language. I'm already afraid of Rust. So straight up.
Phelps: We're terrible sales people.
Hosfelt: It's not scary, it's your friend.
Parikh: I want to write in a language that - so I said that in my talk - it feels like Ruby runs like C. So that's what I love about Go and it's simple. I can ship a single binary and I'm off to the races, I wrote something and it's working and it's performant. I don't need 10 servers to run it. What it doesn't have- it doesn't have generics. I came from the Ruby world and map producers and doing all of that was really nice. And I really missed being able to do those kinds of data related things in Go, with the lack of generics. That was hard. People don't like error handling to a degree in Go. I've been fine with it. I actually am totally fine with it, but I'm putting that out there. Those are two things that the Go team is looking at. And dependency management is something that we don't have our story together on that.
Problems in Modern Software That Languages Aren’t Solving Well
Williams: Potentially to try and shift this a bit from pure Rust, so again, as I said, programming languages are tools and classically, we're trying to solve problems with tools. There are tons of problems out there in software. What are the problems that we are seeing in modern software that no language solves well?
Phelps: Automatic parallelism. We've kind of plateaued with the whole CPUs and we just keep adding more cores. Then with the Spectre, I don't know if it's true or not, because I'm not plugged into that, but I saw a Twitter image that showed the progress of performance over time, and essentially we've been taken back almost 10 years, because we we've had to remove all the speculative execution stuff that the CPU folks have been doing all these years. So for me, I think some sort of magic bullet that people have been trying for years of just scale things automatically for me when I don't have to do anything, I think it would just be the magic thing.
Cantrill: Speculative execution itself is not going away. So we don't have to worry about that. That would be a real problem. Hyper-threading, however, it may be requiem for hyper-threading. So it is a real challenge that we've got. And I think that ...
Williams: You should say what you mean by hype.
Cantrill: Oh yes, sorry. Because unfortunately, I've been way too dialed into this, my entire 2018 has been dealing with spectrum meltdown and all the waves of vulnerabilities. Hyper-threading in an Intel CPU, you have two virtual cores, but they are actually sharing a bunch of units on the microprocessor. The problem is that they are sharing so many units that they are very vulnerable to side channel attack. And I think that that would be actually my answer to your question. In side channel attacks we have, in the abstract, known about for many years. But I think that many of us have a newfound appreciation for them. And I think that, in particular on the microprocessor side, the security researchers were trying to kind of ring the alarm bells for many years, that they're worthy side channel attacks that when you made available high precision timing, when you made available some of these other techniques to arbitrary usable software, that you had these vulnerabilities. I think that there are a bunch of great micro architectural things that are happening to mitigate it.
Speculative execution is going to be okay, I think that Intel has newfound religion on that. But I do think one of the challenges is that we don't know how to write code to have immunity to side channel attacks. And I thought, Diane, you raised a great point. I thought it was very on point in your talk that we interrogate new hires about performance, but we don't interrogate them about security and how to write secure code. And right now, we're not getting assistance from the programming languages on that bit. In particular that's probably why I thought Diane's talk was so interesting.
Hosfelt: Thank you for that. Yes, so side channels are hard. There are new side channels coming out constantly. If you are a security researcher specializing in side channels, you are having a great yea, just briefly touching on the Spectre, because that's in my opinion, the more dangerous of the meltdown and Spectre type bugs. I think I was watching a strange loop talk where someone made the point that even if you go through and you look at the ''dangerous speculative execution'', like the chunks where it could cause a major vulnerability, even if you take the man hours or woman hours, as it may be, the person hours, the cat hours, sorry. Even if you take the time to go through and identify these spots and prevents speculative execution here - I want to say it was a 30% slow down and that's not just turning off all speculative execution. That's not happening anytime soon.
So I think that the new found awareness of just how bad side channels can be, because in the security community it's very much been, "Oh, that seems like a really bad idea," but no one took it that step further to see, “Oh my god, this is such a bad idea.” And so this new found awareness ... sorry, what was the question again?
Parikh: Could you repeat the question? I have no idea what the question was.
Hosfelt: I think I have forgotten the question, Ashley.
Williams: My question was, what problems exist in the world that you think no programming language solves well currently?
Hosfelt: If you're opening it up to the whole world, then there are a lot more. Technical problems would, side channels, huge problem. They are hard and they're incredibly non-obvious. You write something and then some independent researcher is like, ''Hey, if you take this thing from over there, and you take this thing from over there, and then you combine it and do some magic then guess what? I've just extracted your key.'' And you're like, ''How did you even think to do that?'' Also human error. There's only so much a compiler can protect you against. I'm also going to add in things like diversity and accessibility, because programming languages can't help us with that. But by having accessibility and diversity, we actually end up with better code and better projects, in my opinion.
Williams: I'm going to let Aarti, but I'll get into that stuff in a bit.
Parikh: My take is that programming languages are not helping us with education. So we are not teaching our kids - my daughter's taking Java right now. She's in AP computer science taking Java and I'm sitting with her. She took Python last year, she's learning all these languages, but does she really understand what's happening at the machine level? Programming languages, if they're written in a way- that's why going back to Go, that's why I like Go. I feel like I'm closer to understanding what's happening on the hardware, on the machine. So yes, we should write languages that help kids learn how the world works in the machine way, I guess.
Language Ergonomics
Williams: Awesome. I think those are all really interesting open questions because they're open problems.
Phelps: I'll ask you a question if you want.
Williams: Oh gosh, not yet, once I run out of material. In the last talk, which Aarti gave about Go, I think one of the most interesting things that she brought up was that we should be designing programming languages for developer experience. There's the more capitalist version of that, which is called developer velocity, which is what it is.
Phelps: I have never heard that.
Williams: We got this guys, we got this. Developer experience is an incredibly important thing. It's often also known by the term ergonomics. It's the idea of how awesome and intuitive is a programming language to use? Fundamentally, many languages have focused on this. Also, some languages have chosen not to focus on this. For your language of choice, how does your language approach ergonomics? Why does it value it, or why does it not? I'm going to make Bryan answer about Assembly for this one.
Phelps: Well done.
Cantrill: Yes, so actually the reason I cringe at velocity by the way is because the developer is not a projectile. I think ergonomics is a much better term. Ergonomics humanizes us. And fundamentally this is a craft. And when we talk about developer velocity, we dehumanize ourselves and we allow ourselves to be categorized as projectiles.
Williams: I mean, this is why I said the capitalist version. If it's not clear, I'm not pro capitalism. Anyways, continue.
Cantrill: But capitalism and art are not mutually exclusive so ...
Williams: We'll take this to the parking lot.
Cantrill: That's good. I believe I can be a capitalist and a software engineer, but maybe not. You're going to force me to answer ergonomics for Assembly. So I'll give you a classic example. When we look at Assembly, you're not actually writing machine code. You are writing in a very slightly higher level language than the actual machine. We use an Assembler to actually generate the actual machine code. You would think, “What ergonomics are there to be had?” But infamously, the register ordering is actually flipped between what's called the Intel Syntax and the AT&T Syntax. I don't write that much Assembly. I mean, it's unusual for me to write Assembly. You write Assembly when it is either performance critical, when it's using a micro architecture feature that you can't get to encode, or it is [inaudible 00:23:57] you do use Assembly for that.
What I do a lot of, is read Assembly. I spent a lot of time reading Assembly. I wish I didn't, in some regards, but I'm reading Assembly because I either don't have source code or I'm trying to figure out what's going on or I've got someone whose software is not working and I need to figure out why. So I read Assembly a lot. So the ergonomics that I actually need is to make that Assembly readable. When you've got a half of the planet that has a registered ordering flipped, it makes it absolutely brutal to figure out what's going on. They’ve since improved it, which is great. But historically Go used the Plan 9 toolchain and actually came up with their own assembly syntax with registers that didn't exist.
If you look at that Assembly as someone who understands micro architecture, you're just like, “Wait a minute ,what is going on? What are these registers?” It's incumbent upon us when we're looking at Assembly- because I've been forced to answer the ergonomics of Assembly, I just want to emphasize that - it's incumbent upon us to allow what the machine is doing to be readily comprehensible. We actually spend a decent time with disassemblers because Intel is constantly adding new things to the instruction set. So what we focus on is the ergonomics of disassembly and I think that there's a lot more we can do there.
Williams: I will say I did give you a difficult question, and I think I'm going to send this to Aarti next. I started writing a toy operating system in Rust and inevitably because some of the tooling wasn't quite there when I started, I had to handwrite some Assembly. And one of the things that I thought was incredibly refreshing about Assembly - now, I didn't have to jump between different types of Assembly - but was that having a small set of instructions was actually kind of great. I was like, I've got maybe five things I really can do and that they're just going to do them. There were some things that I felt like I'm just down, like I'm out of this cloud of obstructions, and this is just what I have to do. And it's incredibly tedious, but there's something pleasant about having a very simple instruction set. And so I kind of wanted to send this over to Aarti because I think this is one of the key ergonomic decisions in Go, which is have a really simple language. So if you want to talk about that.
Parikh: Sure, I can talk about that, but I'm curious, did they fix that problem?
Cantrill: With Go?
Parikh: Yes, the Plan 9 situation.
Cantrill: Go threw out finally the old tooltrain, so that was done. One of my former colleagues, immediately before retiring to Idaho, wrote a rather inflammatory blog post, which apparently ruffled some feathers, but it resulted in some changes and some tool train changes.
Parikh: So they're taking the feedback.
Cantrill: Yes, absolutely.
Parikh: This is good news. That's what I wanted to know.
Cantrill: Yes, it's good news.
Parikh: Going back to your question, Go has 25 keywords. The cognitive overload of learning is not there. I'm getting older, I don't remember things; how to keep all of like my kids’ things in my head, where I have to drop them and what classes they have. And if I have to think about the conciseness of something all the time, like, “Hey, you could use a four loop or you can also do it with this iterator,” or, “Hey you should do this.” There was a lot of that in Ruby, and I didn't have to do that in Go, where I could just focus on the simplicity and writing my code. I can read my code. I have a team of engineers who are not all senior engineers. I have some RCGs in my team, recent college graduates, we call them, we have interns and then I have a few senior engineers.
With this team, they can jump into a code base that was written by someone who left, and they can be productive. That matters to them because they're there to do a job. There are those of us who are going to be really passionate, like, "Hey, I want write in this." And then there are those who want a job, do a good work, but at the end of the day go home, and this language works for them. That's a different kind of developer happiness.
Williams: Absolutely. We kicked this off with Assembly, so now I'm going to punt over to Jay. WebAssembly, didn't we learn our lessons? Do we want to be doing Assembly all over again? And what is it particularly about WebAssembly that made it work out well?
Phelps: Do you want me to talk about the ergonomics of using WebAssembly?
Williams: Well, you can talk about the ergonomics of using WebAssembly, but we've tried to do things like WebAssembly before and the browser, and we could never really get everyone to agree. I think there are elements of WebAssembly's design that potentially helped make that happen.
Phelps: Sure. It's really pretty low level, WebAssembly itself. If you're writing it by hand, which if you're interested in WebAssembly and using it, I encourage you to do it because you can learn the fundamentals of it. Like they were saying, there's not a whole lot. I mean if you really wanted to memorize every instruction, there are a number of instructions for different variations of things. 32-bit versus 64, floats versus integers. But it becomes essentially the same thing if you want to multiply, use a multiply instruction. If you want to add, you use an add. If you want to load, you use a load, if you want to store, etc, etc. And so, because it is a virtual machine, it's not unlike a real Assembly language. It's a bytecode, so it's not technically in Assembly language, but there's a textual representation.
And as far as the ergonomics of using it, because it's a stack machine - in the sense of the instructions are evaluated into an implicit stack, the machine itself has an implicit stack, there isn't a separate stack - and because that can get difficult for a human to write if you haven't used Forth or you're not just used to … I wanted to plug because I knew he'd get that.
Cantrill: I also represent Forth on this panel, by the way.
Phelps: I knew, he didn't tell me that but I knew it. But if you haven't used stack machine stuff, it can be difficult to follow. So there is some demo developer ergonomics like that. There's an abstract syntax tree syntax that's of the textual representation that looks more traditional, looks more like LISP. Even if you've never written LISP, I could teach you the fundamentals of LISP in five minutes, like how to write LISP.
Williams: Whenever I see that, I am always like, “LISP finally won,” I guess.
Phelps: Yes, accidentally. Because it uses things like S-expressions, if you're familiar with that. So it's just the curly brace, or the parentheses. It's a very simple syntax that I think goes a long way into making it be able to be totally tolerable to write handwritten WebAssembly. And it feels very empowering to do that. Other than that, I'm not sure exactly what ...
Williams: So I have a bit of a followup if you want, which maybe will help.
Phelps: Sure. I want to talk about this as a little bit of a caveat. There is something called source maps for the browser, if you're familiar. It was intended for JavaScript and CSS and things like that. And you can use source maps for WebAssembly, but it doesn't work in every case for every language, especially ones like C and C++. It'll take you to the right line, but there's just some niceties that still need to be added to a super source map specification. There's a sub panel that's working on that. We're actually not totally in a great place with WebAssembly, as far as developer ergonomics.
Tooling, just like machine code, we know we've had years of tooling to make it so that the average person doesn't have to touch it. You're an anomaly and that's kind of your job in a lot of ways, I imagine, right? Like to be that, it's a great thing. For the most part though, we don't have to touch Assembly, and that's a good thing. And we're not quite there with WebAssembly. I would say it depends, if you're compiling some C++ to WebAssembly and it's a known thing, then yes, you don't ever have to learn that stuff. But if you're trying to blaze a path, you absolutely need it to have some WebAssembly knowledge. What was your follow up?
Williams: So my follow up for you was, the media loves to say, “JavaScript is eating the world,” which is a metaphor that I don't understand, because nothing eats the world. I don't know what that's all about. But fundamentally, it means that JavaScript is incredibly successful. One of the things that I think can be attributed to JavaScript for it being so successful, is how accessible a language it is, how low its learning curve is. WebAssembly is not here to kill JavaScript, but obviously of the big things is that we want people who write JavaScript to write WebAssembly. Are there plans for WebAssembly's ergonomics story to be able to create a bridge between folks that are used to writing JavaScript, to folks that would potentially want to write WebAssembly, but are not ready for that learning curve?
Phelps: Sure. And, I apologize if this sounds like I'm correcting you, because I don't intend it purely as a correction, I guess a refinement of one particular thing. If you didn't see my talk really quickly, WebAssembly is a low level bytecode. So normally you wouldn't write it, normally you would compile to it and I just want to make ...
Williams: That's mostly what I'm trying to say.
Phelps: No, that's totally what you're saying. I just want to make sure because this is a very common confusion.
Cantrill: Are we all your puppets on this panel?
Phelps: People go home and they think, “I'm going to write WebAssembly by hand,” and I think it was really critical … I apologize. But ironically with that caveat in mind, just like an assembly language is just above what you're actually writing, it does have some minor obstructions. You can write just above WebAssembly. There are languages like AssemblyScript and Wah and Walt and all these new programming languages that have sprung up that are barely an obstruction ...
Cantrill: Can you spell Wah?
Phelps: W-A-H.
Cantrill: And Walt. Does Wah google well?
Phelps: I have no idea.
Cantrill: And AssemblyScript. That's new. I just need you to give me a moment. So AssemblyScript, Wah and then Walt was the one.
Phelps: There are other ones too. TurboScript, ThinScript, there's a whole bunch of them.
Cantrill: Okay, wait a minute.
Phelps: I can just keep going.
Cantrill: Are you making these up?
Phelps: I could just start making them up, like, power ranger script and red ranger. But you'd be surprised what actually distills down to syntax that looks a lot like JavaScript, but as long as you take away all the dynamic features of JavaScript, you don't have dynamic computed keys and you have things being statically typed, or at least inferred to be statically typed. You can get a lot of the way there and actually be fairly productive in a lot of functionality. Now, you won't be writing your UI app accessing the DOM and stuff like that with a language that low level, but you can get a lot of the way there. And so I actually do think that we're going to see these AssemblyScript type of things get more and more popular to be used by people. Because if you know JavaScript, I can tell you within five minutes you can write AssemblyScript.
Cantrill: That's such a fascinating juxtaposition to me. AssemblyScript, what does it even mean?
Phelps: It's not even a script.
Cantrill: It's so fascinating.
Phelps: It's not a scripting language, it's just JavaScript.
Williams: I'm going to address AssemblyScript and what I think it's doing with ergonomics with a question I'm going to give to Diane. But I'm happy to talk about AssemblyScript with you later. We can have an AssemblyScript panel after this panel.
Hosfelt: You weren't asking me about AssemblyScript, right?
Williams: No. The question I want to talk to you about, which I think is getting at the heart of Bryan's surprise - or potentially I'm completely wrong and just do not understand the surprise at all - is the idea that one of the things I think we're seeing, and Aarti finished her talk with this quote, which I thought was fantastic is, we're seeing a convergence largely driven by language design that's trying to get people who generally write applications and people who generally write systems programs to come together. So one of the things that I know is often used to sell Rust as a programming language is the idea that Rust wants to empower any type of developer to be a systems developer. Fundamentally, that goal is an ergonomics question. So my question to Diane was, how is Rust trying to make systems programming, that low level control, something that someone who generally writes an application, something that they can be productive in?
Hosfelt: First, I want to apologize for yawning. I'm a little jetlagged and it won't stop. To answer that, I come from more of a C and C++ background. My husband is also a developer and he comes more from a Python background. We are both now Rust programmers just from opposite ends of the spectrum. He picked up Rust because I started doing Rust. He was like, "Wait, what's going on there?" The thing about language is we often think of them as on a spectrum, right? We have our “close to the metal” over here. You have some people, fascinating people who decide to write binary, like literal binary. I had a friend in college who wrote zeros and ones for his Assembly instructions. He's hardcore. And we tend to think of C on that end, and then we have all of our scripting languages that are interpreted over here. And REST kind of takes that and throws the programming language spectrum as we've thought of it before out the window, because you can do this low level memory management stuff, but you also have all of the syntactical sugar and the abstractions that you're used to in a higher level language. And then you have all of the performance that you want from something like C, but you don't have to deal with garbage collection or anything like that.
For me, the hard part was actually learning to embrace iterators. I'm so used to doing terrible, terrible things in for loops, that that really hard for me. Coming from more of a scripting background, that was actually a bit easier for my husband to do because he's a bit more used to some of the more functional approaches. So it's interesting because this is in complete contrast to Aarti's comments about how simple Go is and how you just do it this way. One of the things I love about Rust is that if I want to do something in a very functional way with mapping and filtering, I can. But then if I feel that it's more readable to do it in an iterative way, I can also do that.
Parikh: I was going to say, Aarti, do you want to respond to that at all?
Parikh: I think I like both. So this is the thing, I like both, but I think that I like the simplicity of Go still. I would use Ruby for my side projects, but would I put it in production? I don't know, because other people have to maintain it.
Cantrill: One of the questions you asked was how we make the sophistication systems programming more accessible. And I think there’s such deep rocket science in the Rust compiler. I think that when non-lexical lifetimes hits, I think that there's going to be a whole class of people who are going to come to Rust and not know what all the fuss was about. It's like, "I'm using Rust and I never had to argue with the Borrow Checker. I don't get it." And it's like, “You didn't have to argue with the Borrow Checker because of some very deep, important, thoughtful work that was done in terms of…” Because the reason you have to argue with the Borrow Checker is because there are imperfections with a Borrower Checker, where you think you're done with something or you think the ownership is something, and the compiler thinks the ownership is something else.
What I've seen is that the compiler getting smarter and smarter and smarter allows for greater and greater and greater accessibility. One of the questions I’ll get back to you, because there's a question that I definitely have is, where is the place for Rust, in particular, in the curriculum? Because to your point - I think I shared the concern about education and it's like, when do we teach someone Rust?
Williams: I will let Diane answer, but the one thing I will share is I personally have the experience of teaching more than 10 brand new people to programming with Rust as their first language. I don't think we're totally there yet, but it's possible.
Cantrill: Four of them committed ritual suicide.
Williams: I have done it. Everyone is safe and fine but it is possible. So Diane, I know you had something to say about that.
Hosfelt: Yes. I've talked to a number of professors and grad students who were like, ''Hey, so what would you think about if I decided to change my intro to CS class to Rust?'' And I'm like, ''Well, that sounds awesome just don't murder your students with it.''
Williams: No more death metaphors, please.
Hosfelt: Sorry. Don't drive them insane with it.
Williams: Come on, you're really making it tough for me here as a moderator. No mental health or death metaphors, please.
Phelps: Less than happy.
Hosfelt: Yes. If you were here for my talk, you heard some bugs statistics that I've been working on. I've also been working desperately on getting a blog series out about it. And I was talking to a PL researcher about this and he was like, ''Hey, so I'm using Rust in one of my software classes and it's about how we can use programming languages to help solve some of the problems that we have with security," which happens to be kind of in my interest realm. He was like, ''Once you have this published, I would really love to be able to point my students at it.'' So from an educational standpoint, I know that there is a lot of interest. I am not an educator and in fact would not be a very good educator. But I've found that the Rust compiler teaches me. So, yes, why not offload some of the burden on our professors and teachers? Let the compiler teach everyone. It's going to become self-aware soon. We should be afraid.
Phelps: I think one thing I wanted to touch on is that Rust and Elm - Elm is a programming language designed for the web - I think they both collectively have kind of played off of each other. I don't want to give one more credit than the other. I'm not sure which came first.
Williams: No, Rust 100% borrowed from Elm. We copied them shamelessly and we thank them daily.
Phelps: I thought so, but I didn't want to say it.
Williams: It's true.
Phelps: But Elm, in hindsight, it's kind of like, “Duh”. But essentially, Elm, this programming language that was designed for the web, it's kind of like a gateway drug to Haskell, but yes, but it's much much simpler. Sorry about the drug metaphor, I guess.
Williams: It's cool. It's like hurting cats up here.
Phelps: I know it. But anyway, it did something novel that is laughable, but that it actually gave us real good air messages. It actually did not only give you a short description that you could google, but also a long description that a human would read, and pointed you exactly to the line of code and in a lot of cases, gave you examples of what you should probably do, what it thinks you meant or what you might want to put here instead. And that was a number of years ago when it first did that. If you're fairly new to programming, you might not have noticed because in the last many years, four or five years, other languages have borrowed from that philosophy. And I just think that that's a huge thing. It really set the bar just totally different. And it's funny, because if you write a lot of Javascript, you still to this day get undefined is not a function errors.
Williams: It's not, never is.
Hosfelt: I don't write JavaScript much, but I have to do like web platform test stuff. I've been trying to test something and I kept getting that and can I please just say that it took me so long to understand what that error was trying to say. I'm talking on the order of days. Rust has spoiled me for errors.
Parikh: Yes. But I mean the thing to keep in mind is JavaScript was written in a week.
Phelps: Oh, absolutely. The specification actually does not dictate what error messages should be used, thankfully. So theoretically, the browsers could improve them and I have seen some improvement. They've gotten a lot better at detecting function names. Whereas before, when everything was anonymous, not everything, but a lot of things were just anonymous functions, and instead now it's detecting- because that was added in ES 2015, detecting the function from the current variable name. But just improvements in general, I think it just really set that bar a lot higher and I'm really happy about that. I know we've been talking about a lot of negative things. I just wanted to really say that I'm just super happy that we have that new bar.
Killer Features of Programming Languages
Williams: We have about three minutes left and I want to end on a forward thinking, very positive note. So I have run out of time, but potentially you could answer with this, which is, with this track you've probably noticed, if you had sat here for the rest of the day, is that there's a lot of talk about compilers. And I think a lot of languages that are coming out these days are really leveraging what I like to call the magic of compilers. I call it magic because compilers take work that you would otherwise have to do away from you, and that does feel kind of magical. That being said, for each one of you, and we'll start with Aarti, as we move forward and we see languages develop, what is the one killer feature of programming languages that you are super excited to see develop? This could be a technical feature or it could be a community feature.
Cantrill: One that exists?
Williams: One that we can imagine, that you can articulate in a tweet sized thing because we've got three minutes.
Parikh: Yes, sure. Earlier what was mentioned was that the Rust compiler is so beautiful. It prevents you from doing all of these things. I think we live in the real world and we can never prevent all the bad things. We’ve got to write languages in a way where we can debug them, trace them. We can do something with testing better. And testing should be built in the programming language. It should be a first class citizen, just like concurrency is a first class citizen. That is something that I would like to see. And then all of the stuff about security that we talked about too. If it was in there, we'd find these things.
Phelps: For me quickly, I would say reactive programming, just the resurgence of data flow and those types of patterns, the RxJava, the RxJS, those sorts of things, Bacon and all that. I'm interested personally in research, bringing that back into the language itself, instead of creating a DSL with a library inside of a language that's structural and procedural, taking and looking at research from the 70s and 80s before procedural languages. One, looking at those old data flow stuff. So that's stuff that I'm most interested in. There's a lot of research about this personally. I know you said one, but I have to at least say the words. I recommend you look into Algebraic effects which is terrible ...
Williams: This is why I asked this question, so Jay could say this.
Phelps: Thank you so much. I had to get it in. I had to get it in. So it's a terrible, scary name for something that's not that scary. The real quick spill- and this is totally not accurate, but it's a real quick spill- is imagine exceptions, right? You can throw us an exception, it goes up the stack, but imagine if you could continue from where that exception was. So wherever you threw, and an async await can be thought of as a subset of what Algebraic effects can do. But it's a way of writing pure functions that still perform side effects, kind of solving a similar problem or the same problem essentially, as what Haskell tries to do with Monads. So it's a whole panel on its own to talk about. But if you're interested at all about what is super hot right now, just Google Algebraic effects and, yes.
Williams: I just have to say, for a languages panel, time till the word Monad was spoken was 50 minutes and I'm impressed with us.
Cantrill: I think that I look forward to seeing the HOPL talk. HOPL was the history of programming languages conference. I think there have only been three held in history. The last one was in like 1999. I don't know when they happen.
Williams: I was told that there is one coming up, when I spoke at Strange Loop. The Strange Loop organizer was like, "You are going to like this." Yes, it's coming.
Cantrill: Oh my god, the second coming. HOPL is amazing. At some point in time, there'll be a HOPL talk on Rust and I will look forward to it, because I think the ownership model is really, really, really important. I think it's the most important development programming language in the last 30 years. PL researchers, whenever there's anything hot in programming languages, they always rattle off 30 old programming languages that did it. And like, “Oh, CLU did this and the 80s and Argus did this.”
Williams: Simula is my favorite throwback.
Cantrill: I don't hear that on the ownership model. The ownership model, even PL researchers - What's that?
Williams: Google the Clean programming language.
Cantrill: The Clean programming language. I will do that right after Wah and Walt, I will look at Clean. So fine. Rust is a Clean derivative in that regard. I really would say that every programmer really should take the time to understand the ownership model. It is a very big deal. It's really exciting. It's an exciting development. As a systems programmer, it allows me to write code that has all of these terrific benefits of dynamicism without the cost. It's a great development.
Williams: Close this out, Diane - the language feature you're most excited about?
Hosfelt: Thank you for the reminder. Unfortunately, I'm obviously going to be doing a two-parter here, but I will keep it brief. I think that there are two things I'm really excited about. One, I love seeing things that have emerged in PL research make their way over to the main stream. And like you just said, ownership is one of those things where we have affine types, which is just the fancy word for the ownership model. All of a sudden I can do this crazy research thing. That's not something that I would have ever expected. And I love seeing languages look at the research that's going on in the academic community and say, ''Hey, we can bring this into the mainstream and it will improve things.”
Williams: Quick side note, if you are excited about that in particular, the final talk of this track is just about that. So please do stick around if bridging academia and industry and programming language research is something you're into. Sorry, interruption, go for your second part.
Hosfelt: I'm very excited for that. The other part is somewhat related. I love that we are moving away from this post hoc, “Oh no, we've made a huge mistake,” and then trying to fix things after the fact to building things like security and concurrency and everything else. We're trying to think about these things from the start and we're trying to make the languages so that they can adapt, but identify the problems before they become huge problems. And I see that as more general trend in tech right now, but it's very exciting for me in the PL realm.
Williams: Thank you all to our panelists, particularly Aarti who is the one non-Rust. Thank you for sticking in there. I had no idea. Please give them a round of applause.
See more presentations with transcripts
