Algorithms + Data Structures = Programs - Episode 137: 🇬🇧 Sean Parent on Val (vs Rust)!

Episode Date: July 7, 2023

In this episode, Conor and Bryce interview Sean Parent live from C++ On Sea 2023 about the Val programming language and how it compares to Rust, Swift and C++.Link to Episode 137 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Sean Parent is a senior principal scientist and software architect managing Adobe’s Software Technology Lab. Sean first joined Adobe in 1993 working on Photoshop and is one of the creators of Photoshop Mobile, Lightroom Mobile, and Lightroom Web. In 2009 Sean spent a year at Google working on Chrome OS before returning to Adobe. From 1988 through 1993 Sean worked at Apple, where he was part of the system software team that developed the technologies allowing Apple’s successful transition to PowerPC.Show NotesDate Recorded: 2023-06-29Date Released: 2023-07-07C++ On Sea ConferenceAll Sean Parent ADSP EpisodesAdobe Software Technology LabASL LibrariesThe Val Programming LanguageThe Rust Programming LanguageThe Swift Programming LanguageMutable Value SemanticsLLVMRust TraitsCppNorth 2022 Keynote: The Tragedy of C++, Parts One & Two - Sean ParentC++ Seasoning - Sean ParentSean Parent: “Now What? A vignette in three parts” - C++Now 2012Adobe ASL Adam & Eve ArchitectureHalide LanguageIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

So we think there's an opportunity and a need for another language that's more approachable than Rust, more safety than Carbon or CPP2 or anything that C++ could do in the next decade. You've got the creator of Rust saying that it's the language that he wished he created. I'll ask it more directly. Are you building a Rust competitor? I mean, Dave Abrahams and I decided just this last week that we're going to stop referring to Val as an experimental language. You heard it hereth, 2023. My name is Connor, and today with my co-host Bryce, we catch up with Sean Parent live from C++ on C2023.

We chat about the VAL programming language and how it compares to programming languages like Rust, Swift, and C++. We love Slovenia. What was our favorite thing in Slovenia? Bled Lake was amazing, and also I don't know the name of that drive, but the name of the drive to Hisa Franco, and also obviously the Hisa Franco dinner.

What was your favorite thing? The drive, the drive of the drive to Hisa Franco and also obviously the Hisa Franco dinner. Yeah. What was your favorite thing? The drive, the drive over the mountains. Yeah, the drive. I mean, if you do not like windy drives and you need gravel. All right. But enough about Slovenia. Enough about Slovenia because we have, this is a big deal, people.

Oh, wait, our wires are, it is the return of the king. So wait, should we look up the last do you sean do you know the last time we had you on i don't know episode one something like that we're bad friends sean it's like every every like 10 episodes we're like oh yeah we gotta have sean back on but we're too like you guys are just completely trolling me. I'm like, you keep saying you're going to ask to have me on,

but then you don't actually ask to have me on. See, just don't mistake incompetence for malice. This is solely incompetence. I see. So how have you been doing?

I've been doing well. So since last time we talked, I think I started Software Technology Lab. Yes. Yes, which is well. So since last time we talked, I think I started Software Technology Lab. Yes. Yes, which is huge. What is the Software Technology Lab? So it's a group at Adobe, which is currently myself, David Abrahams, David Senkel, and Nick DeMarco, which is my small dream team.

I was just about to say, what a dream team. Yeah. So our charter is Improving Software Engineering Practice, full stop, which I'll explain in a moment. We define that as being distinct from process, which means we're not concerned with agile or other methods of software development. We're concerned with how do engineers write correct and efficient code when they sit down at the keyboard, and how do we make that happen. We're taking a three-pronged approach, or a three-pillar approach, which is education.

So we have a series. Right now they're internal seminars, but they will become external seminars, and we kind of polish them up. Somewhat based on my Better Code series of talks, we're all working on the book, which is part of our educational emphasis. It can be pre-ordered on Amazon. It can be, but don't, because it can't ship until I retire. Connor, have you pre-ordered the book? I may have pre-ordered it a couple years ago.

Yeah, don't tell my publisher. So, yeah, but we're making progress. more progress than I was making alone, that's for sure. Our next pillar is tooling. So we're renewing our effort in the STLAB libraries, which are out there in open source, as well as the ASL libraries and we're working on a language called Val and then our our third pillar is research so which includes university collaboration I've got an ongoing collaboration with Yaku Yerve but we're looking for other universities to kind of restart our efforts in this area. And back to the full stop, the original charter of the team, or the old software technology lab, which I managed before with Alex Stepanov and Paul McJones

and Matt Marcus and Foster Brereton. Our charter then was much the same. It was improved software engineering practice at Adobe. And this time around, we had a VP with enough insight to say, it should not be at Adobe. It should be industry-wide. So do this publicly and visible. So we are all going to get to benefit from the great content that Mr. Sean Parent and his dream team are going to put out. That is our goal.

That is our goal. Speaking of Val, we were having dinner on Tuesday night, and I did not know this, but you said that the creator, the original creator of Rust, Graydon Hoare, had comments about the Val language that I did not know about. Share with our listeners what the original creator of Russ Graydon Horse said about Vow. Yeah, so you can look this up on Twitter. You can put it in your show notes. So Graydon posted on Twitter that Vow is the language he wished he created. Wow, what an endorsement. So what should we know about Val?

My colleague Andre, our colleague Andre, likes to say that a language has to be 10x better than the competitors on some access to really survive. What is the 10x for Val? What is our 10x? So I think our 10x is pushing the idea of mutable value semantics, which is really the idea of regular types that Stepanoff was promoting as part of the STL. Pushing that as being the fundamental way that you describe objects and computation within the language.

Right now what's happening, folks, Sean Barrett just filled my glass of wine up Probably twice as full as it should be So Connor topped up his wine And then Sean topped up the top up These two men are locked and loaded and ready Let's go find some chairs Because I don't think I think you two are going to have to be carried out of here

We're four minutes overdue We have to leave this room Yeah we do have to leave this room And we got J.F. He's got his Apple Watch, even though he's not that company. He did. How does it feel not having to get your animations approved? Oh, it's great.

I have an anvil drop in my presentation. It's awesome. And they didn't let you do that at Apple. No. Are you allowed to say why? Yeah, it's only for Craig. It's on Twitter. It's on Twitter. I explained it. Fun fact, it's my most popular tweet. My most popular tweet is how Apple would not let me use Anvil Drop.

So, yeah, good job, me. All right, we're going to camp out right here. Before we were so rudely interrupted, Sean was explaining what gives Val the 10x advantage. So Val is centered around value semantics and basically how far can we push that paradigm. But if you look, so Chris Ladner, who created LLVM, also started the Swift language, and Dave Abrahams kind of left the C++ community to work on Swift

and to do the Swift standard library. And one of Dave's contribution there was bringing some of Alex Stepanoff's ideas into Swift. And so if you look at Swift, it's a little bit of a bifurcated language. It's got a reference semantic portion, which is there for compatibility with Objective-C. But the entire standard library is written in terms of value semantics. And that's Dave Abraham's work. And Swift also takes the ideas of concepts and kind of the work that Jeremy Seek did. And then Doug Greger did for Concept C++, which was concepts pre-C++11.

Not the concepts we have in the current language for anybody who's too young to remember. So Doug Greger took Jeremy Seek's ideas and incorporated those into Rust. And so arguably Rust has kind of better concepts than C++ has. I don't think there's much arguably there. I think it's just a true fact. Yeah. So, um, uh, uh, uh,

Jimmy, Jimmy record on who's a, a post doc out of, of Northeastern took the idea of kind of value semantics swift and did her thesis work on, on basically how far could you push value semantics and could you make value semantics a first part of the language and make the language safe by default even under a mutation. And so you would have many of the benefits that you would have with Rust as far as worry-free concurrency.

You can't introduce a race condition because you can't have dual access to an object under mutation, and those same ideas, but in a much simpler package. So if you think about, one way to think about Rust is Rust is a simpler form of pure functional programming, because in pure functional programming, you're always thinking about things in terms of mutation, but you can't actually express mutation. So you have to express mutation in terms of rewriting the universe to affect mutation.

So in some sense, Rust is a simplified form of functional programming. They're interchangeable, by the way. There's a fairly trivial transformation to go from Rust to FP, but Rust is an easier model to think about because now you can actually think in terms of mutation. The problem is within Rust, you have to do that through annotations and a borrow checker, and it becomes very complicated into how do you describe that you have right access to this object. Whereas Valve takes everything in terms of a whole part relationship, and through the whole part relationship, it can track, oh, if you have right access to the whole, then you have right access to the parts, and if you have right access

to the parts, then you can hand out right access to some of your parts to this process and some of your parts to that process and so you can get kind of the benefits of rust without all of the decoration and all the complexity you start to think about things just in terms of a model that you have in most programming languages which is your built-in types like your ints, if they're not boxed, are these types that are just on your stack that you just use. And in Val, you can think about it as everything behaves like an int. But you have all the protection there to say, I can't create a race condition on my int. But I have all the efficiencies as if I were handing out references, but they behave as if I were handing out values. So within the Rust

model, things like move is implicit. So if I assign one thing to another thing, that's just a move, and it's a destructive move. I can't reference that object anymore. It has fallen out of scope. An object that's under mutation during an exception disappears. An object that I hand off to a thread is no longer in scope within my current scope. Well, at the same time that you have that whole environment going on, you're doing that all without additional annotation

and decoration, right? So it becomes, our argument is if you look at how people use Swift and how people use the Swift standard library, people view that as being a simpler model and it's easier to program and it's very approachable and you have like the Swift playground and people jump into it very quickly. And so DIMI took that and basically put it on a strong theoretical foundation, proving its correctness, proving that it satisfies the frame rule, which I talked about in my previous talk, which means it satisfies that you would want, but in a much more efficient way than you would get in a language with no mutability like Haskell. Could you give the definition of that non-interference principle that you gave in the talk?

Because I think that may be helpful for... Yeah, so the non-interference property is basically that an operation can only affect objects that are passed directly in its interface and can't affect other objects. So this relates to the whole-part relationship. If I pass something to... you know, through my interface,

I can only affect those things in the interface. I can't affect other objects. In a reference semantic language like JavaScript or Python or something like that, that reference is shared. And so if I access the object through my interface, I'm also touching the object potentially that somebody else has access to. The objects intersect. And so Val does not allow that intersection.

So it doesn't allow that level of interference. Rust doesn't allow that level of interference either. It's just more complicated to get to. But doesn't this mean that you have some restrictions? Like, how would you write a linked list in Val? Yeah, so it has many of the restrictions of as rust there which means that in order to implement a linked list for anybody who doesn't know the problems with the linked list is you're trying to refer both front

words and backwards uh uh you know in a doubly linked list within your within your within your cells which means you require mutable access to both and it has to be shared between both. Val allows you to step out into an unsafe construct and then build safe mechanisms on top of that. So we can build that with unsafe constructs and then put a safe API around that in the same way that Rust can pull those things off.

Right now within Val, unsafe is only at the statement level. We don't have block unsafe, which Rust does. And that's because we actually think the need for unsafe is less than it is in Rust. And part of that is Rust mutability is to an entire heap allocated object. It's still a reference semantic language. You have heap allocated objects. You want access to that object. You need access to all of it, all of its parts, everything. Within Val, we're not dealing with reference semantics. We're dealing with value semantics. And that means if you have

write access to the object as a whole, you can slice that up. And you can say, oh, I want to grant write access to just these parts over here and just these parts over here. So the need for doing unsafe code is greatly reduced because you don't have to say, oh, I need to grant write access to these two things so that they can coordinate between these parts, you can say, no, no, no, I can grant write access to this portion for this piece of code and this portion for this piece of code. Okay. And those are isolated access. And so they're just parts of the same object. So you can think about it within a vector just because I can pass off mutability access to the first element of the vector without passing off mutability to the vector as a whole.

Right, right. That makes a lot of sense, yeah. I've got a quick question here. So back at CPP North 2022 when you gave your keynote of, I think it was, C++, A Tragedy in Two Parts, which was got to be one of the best talks that I've seen from you. I mean, you've got so many good talks. Yeah, that was one of my favorite Sean talks. I mean, we'll link in the description all of his best talks, obviously C++ seasoning.

My favorite still is that keynote at C++ Now. A Vignette in Three Parts? Yeah. So I was about to, like, before Bryce interrupted, I was about to say that one. Because I feel like, honestly, a vignette in three parts was, like, eight years prior to you giving this talk. Kind of like you echoed the same things of, like, how GPUs are underutilized and how that's the... Anyways, we'll link all of Sean's greatest hits in the show notes. notes but in that talk you mentioned val and you mentioned val has kind of just like a research language that didn't have any large goals of like superseding any other languages and if if the if

the greatest impact that it had was influencing c++ into a better direction that that would be like a successful goal but now you've got the creator of rust saying that it's the language that he wished he created i'm listening to you and you and Bryce chat, and you're saying that the need for unsafe is a lot less, and you don't even have unsafe blocks. You only have unsafe at the statement level. So my question now is, I think we're about 11 months or 10 months since your keynote at that conference. Have the goals of Valve changed, or is it still the same, and there's just like a lot of upside? I'll hand it over to Bryce. I'll ask it more directly.

Are you building a Rust competitor? So not quite yet. I mean Dave Abrahams and I decided just this last week that we're going to stop referring to Val as an experimental language.

You heard it here first, folks. In part because we think the hypothesis we wanted to vet is, can you write significant applications in this kind of pure value semantic world? And we actually think that that question has been answered at this point by Swift. So like I said, Swift is kind of this bifurcated language. It has many of the properties of Val. For people who don't know, if you declare struct in Swift, it's kind of copy on write. It has value semantics.

It doesn't quite have all the guarantees that Val has, but it's close. And so we actually think that that hypothesis and that model is proven out at this point. The other thing that's happened is we've gotten to the point where we have an LLVM backend at this point that's functioning for Val. Dave Abrahams is busy working on the Val standard library, and so that's coming along. We're hoping to get Val available on GitHub. I was just talking with Matt Godbolt at this conference about the process for that.

We think we have enough in place that we can actually make that happen. But you said GitHub. Did you mean Compiler Explorer? I'm sorry, Compiler Explorer? I'm sorry. Compiler Explorer, yeah. So we want, Val is available on GitHub, but we want to make Val available on Compiler Explorer so people can start playing with it. The other thing that's happened in that time frame,

which is what my talk was about here, is that safety has become a much more significant issue. And that's partially around legislation and what's going on in that domain. And so we're looking at the industry is going to have to make, in our opinion, a fairly significant shift, at least sections of the industry, towards more memory-safe languages. And the only language out there right now that's commercially viable that meets the requirements that the security industry actually wants is Rust. And we think Val has, you know, and if you talk to C++ developers who have tried to learn Rust, it's a little hit and miss. It's certainly better than, the uptake is better than

C++ developers who have tried to learn Haskell, but learning Rust is still a bit of a mind warp for your typical developer. And a big part of that is just reasoning about lifetime and ownership is a problem where we think if you say everything behaves just like an int it's is it all of your classes are just like built-in types okay and so like all the things you know about an int and the thread safety of an int and all of that that just works um we think that that's a much more approachable model and we think think that Swift has proven that that's a much more approachable model. And so Apple, if you were at C++ Now, John McCall, who's one of the creators of Swift, was at C++ Now. And he was talking about Apple in response to the legislation that's

pending around memory safety and around security is looking to move critical subsystems of Apple's OS into Swift and specifically into the value semantic area of Swift. And Apple has some issues with perception around Swift, which is they're trying to make Swift open source and publicly available. But every time kind of push comes to shove, the priorities are around what's Apple's next product, not around the community around Swift. And so if you look, this is why, you know, Chris Lattner left Apple to go to Google to create Swift for TensorFlow at Google. That didn't happen

because Apple kept the reins too tight on Swift. And so we think there's an opportunity and a need for another language that's more approachable than Rust, more safety than Carbon or CPP2 or anything that C++ could do in the next decade. So there's a gap. So we're hoping to fill that. Have you ever built a programming language before? I have built small programming languages. So I've worked on things called property models, and the language around that is called Atom, and a layout system called Eve, and those have heavy use inside of Adobe, not so heavy use

outside of Adobe. They're very interesting systems. They both compile-to-byte codes, so they're interpreted systems and not compiled systems. Dave Abrahams is the one person on our team. Who has been involved in the creation and evolution of a few different successful languages. Yeah, so Dave Abrahams has the chops. Like I said, Demi's a postdoc. She's super smart, very impressive.

I've managed to get her funded at least through November, which is the end of Adobe's fiscal year. I'm hoping to get her funded after that. So in my view, it's like yeah, things in the last 11 months have changed and our team is putting more

of an effort into Val. That's kind of wrapping up. and our team is putting more of an effort into Val, and that's kind of wrapping up. We're hoping to make it publicly available. I think the only way it has a chance is if a community develops around it. Adobe is not in the programming language business. The closest thing we have is Adobe is very involved in the development of Halide, which for people

who don't know, Halide is a GPU C++-based language for doing image processing and AI. So it makes a lot of sense that Adobe would be involved in that. It's basically a collaboration

between Adobe, Google, and MIT. Halide's very cool. And when he says it's in C++, it's a domain-specific language in C++ that compiles down to very, very optimized code. Yeah. And it can target both CPU with SIMD or GPU. And so within our products, we're able to write things like, you know, image processing kernels and compile them in a half a dozen different ways and then benchmark them all and determine, well,

it would be the fastest way to execute this piece of code would be to do it on the GPU or on this particular GPU. If that GPU isn't available, we'll run it locally running under AVX 512 or something like that. So we have a fairly significant investment on that front. But we're not a tooling company. We don't make our business selling tools. We do have some SDKs around our products, but it's a fairly fringe piece of our effort. So, and my team's very small. It's just, there's just four of us. I was just about to mention, so your team's small.

So does that mean that for Valve to succeed, it's necessary for you to build a community around it? If you look at something like Carbon or Rust, you know, Carbon's got 10, 12-something engineers at Google on it, but you've got a smaller team. So what is necessary for Val to succeed and to grow to become more than just a research prototype? Yeah, I think we need to grow the resources behind Val. I think we need to hit critical mass. In my mind, critical mass is not even as big as Google has under Carbon. I think a team of somewhere between three and five people who

were dedicated full-time on Val would be sufficient, probably with one or two additional people whose role was community building. We've certainly piqued the interest of a lot of people in the industry. We mentioned before, you know, the creator Russ says this is the language he wished he created. Eric Niebler has gone on record on Twitter saying of all the successor languages, he thinks Val is the most interesting. We don't have even a, well, interestingly, we don't have a C++ interop story for Val. In fact, at one point it was listed as a goal on our website and we decided let's just cross that off because nobody's working on it. And honestly, I don't think it's that

important. Adobe already bridges to a huge number of languages from C++, and almost all of those are through the C straw, right? So if you look at Photoshop running inside the browser, the back end is all C++ running in Wasm, and the front end is TypeScript. And on Mac OS, the back end is all C++, and the front end is either Objective-C or Swift. And if you're looking on Android platforms for our products, the back end is C++, the front end is Kotlin. So we have a lot of experience kind of building those bridges and sucking things through a fairly primitive straw. And looking at Rust, my team right now is doing some experiments in Rust.

So part of the STLAB concurrency libraries, we plan on contributing to the Rust community too. We've got our default executor, which we have a portable version of it, which is a high-performance thread pool, which can run anywhere, but we can also back end to the Windows thread pool or to Apple's lib dispatch. So if you're running on Linux, you can either run with Apple's lib dispatch,

which is open source, or you can run it with ours. On Wasm, you can only run it with ours. On Windows, you can run it with Windows thread pool. We're re-implementing that core dispatcher in terms of Rust and seeing if we can do it entirely in safe Rust as kind of an interesting exercise and get the performance where it needs to be. And our plan is, right now it looks doable. And if we pull that off and everything looks good, I don't think there's anything in the Rust community that we've been able to find that is a library that has that capability where it's an elastic thread pool.

So you're able to block within it and it will spin up additional threads if you do. And it can back end into the system thread pool so you're not spinning up multiple thread pools if you're on Windows. So we're doing that experimentation as well. And my hope is, frankly, Val is not going to be this big corporate funded effort, right? Even though Adobe's kind of behind it, it's really my group behind it and me personally figuring out ways that I can carve out budget for it. I got a feeling, Sean, that you'll be able to punch above your weight here. This is part one of a three-part conversation that we had with Sean Parent at C++ on C.

Be sure to tune in next week for part two. And if you are looking for any of the links to topics that we mentioned in today's episode be sure to find those either in your podcast app or at adspthepodcast.com thanks for listening we hope you enjoyed and have a great day we're here with gideon gideon you want to say something to the fans yeah the british closing times are very disappointing half past 10 what's that i completely agree there's lots of wine on the tables. I don't understand what's happening. Yeah, not enough time to drink it all up. Wait, Bryce!

Where did that come from, Bryce? Low quality, high quantity. That is the tagline of our podcast. That's not the tagline. Our tagline is chaos with sprinkles of information.