Sean Parent 0:00

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.

Conor 0:18

You've got the creator of Rust saying that it's the language that he wished he created.

Bryce 0:23

I'll ask it more directly. Are you building a Rust competitor?

Sean Parent 0:26

I mean Dave Abrahams and I decided just this last week that we're gonna stop referring to Val as as an experimental language. Uh you heard it here first, folks.

Conor 0:47

Welcome to ADSP the podcast, episode 137, recorded on June 29th, 2023. My name is Connor, and today with my co-host Bryce, we catch up with Sean Parrot, live from C on C 2023. 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 He's a Franco and also obviously the He's a Franco dinner. Yeah. What was your favorite thing?

Bryce 1:26

Uh the drive. The drive over the mountain.

Conor 1:28

Yeah, the drive. I mean, if you do not like windy drives and you need gravel. Alright. But enough about Slovenia.

Bryce 1:35

Enough about Slovenia because we have this is a big deal, people. Oh wait, our wires are it is the return of the king.

Conor 1:43

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.

Bryce 1:54

We're bad friends, Sean. It's like every every like ten episodes, we're like, oh yeah, we gotta have Sean back on.

Sean Parent 2:00

But we're too like you guys are just completely trolling me. I'm like, like, you keep saying you're gonna ask to have me on, but then you don't actually ask to have me on. See, just don't mistake incompetence for malice.

Bryce 2:16

So I see. So how have you been doing?

Sean Parent 2:20

I've been doing well. So since last time we talked, I think I started Software Technology Lab. Yes, yes, which is huge. So what is what is the Software Technology Lab? So it's a group at Adobe, which is currently myself, uh David Abrahams, uh David Senkel, and Nick DeMarco, which is my small dream team. Yes, I was just about to say, what a dream team. Yeah, so uh our charter is improving software engineering practice, uh full stop, which I'll explain in a moment. Um 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? Uh we're taking a three-pronged approach or three-pillar approach, which is uh uh 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. Um uh uh somewhat based on my Better Code series of talks, we're all working on the book, which is part of our educational emphasis.

Conor 3:46

It can be pre-ordered on Amazon.

Bryce 3:48

It can be, but don't, because it can't ship till I'm Connor. Have you pre-ordered the book?

Conor 3:55

I may have pre-ordered it a couple years ago.

Sean Parent 3:57

Yeah, don't don't don't tell my publisher. Um so yeah, but we're making progress. More progress than I was making alone, that's for sure. Uh uh our our next pillar is tooling, so we're we're renewing our effort in the ST Lab libraries, which are out there in open source as well as the ASL libraries. And we're working on uh a language called Val. And then our third pillar is uh uh uh research, so which includes university collaboration. Uh I've got an ongoing collaboration with Yaku Yarve, but we're looking for other universities to to kind of restart our efforts in this area. And and uh back to the full stop, the original charter of the team or the old software technology lab, which I managed before with Alex Stefanoff and Paul McJones and Matt Marcus and Pastor Brereton. Our charter then was much the same. It was improved software engineering practice at Adobe. And this time around, uh we had a VP with enough insight to say it should not be at Adobe, it should be industry-wide. So do this publicly invisible.

Bryce 5:20

So we are all gonna get to benefit from the great content that Mr. Sean Perrin and his dream team are gonna put out. That is our goal.

Conor 5:29

That is our goal. Yeah. 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 Whore, had comments about the Val language that I did not know about. Share with our listeners what the original creator of Russ, Graden Hoar, said about Val.

Sean Parent 5:47

Yeah, so you can look at this up on Twitter, you can put it in your your pod, in your show notes. Uh so Graydon uh posted on Twitter that Val is the language he wished he created.

Bryce 6:00

Wow, what an endorsement. So what what should we know about Val? What is what is, you know, uh my my colleague Andre, our colleague Andre uh, you know, likes to say that a language has to be 10x better than the competitors on some axis to really survive. What is the 10x for 10x?

Sean Parent 6:20

So I think our 10x is pushing the idea of mutable value semantics, which is really the idea of regular types that Stepanov was promoting as part of the STL. Uh pushing that as being the fundamental uh uh way that you describe objects and computation within the language.

Conor 6:40

Right now, what's happening, folks? Sean Perrin 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.

Bryce 6:53

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 gonna have to be carried out of here.

Conor 7:01

We're four minutes overdue. We have to leave this room. Yeah, we do have to leave this room.

Bryce 7:04

And we got JF.

Conor 7:05

He's got his Apple Watch, even though we've got that company.

Bryce 7:08

He did.

JF Bastien 7:10

How does it feel about having to get your animations approved? Oh, it's great. I haven't got an Envil Drop in my presentation, it's awesome.

Bryce 7:17

And they didn't let you do that at Apple.

JF Bastien 7:19

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.

Bryce 7:36

Alright, we're gonna we're gonna uh camp out right here. Before we were so rudely interrupted, Sean was explaining the like what makes that what gives Val the 10x advantage.

Sean Parent 7:48

So Val is centered around value semantics and basically how far can we push that paradigm? Um 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 uh uh Dave's contribution there was bringing some of Alex Stepanov's ideas into Swift. And so if you look at Swift, it's a little bit of a bifurcated language. It's got uh a reference reference semantic portion which is there for compatibility with Objective C. And then it's it 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-C11, not the concepts we have in the current language for anybody who's too young to remember. Um so Doug Greger took Jeremy Seek's ideas and incorporated those into Rust, and so so arguably Rust has kind of better concepts than than than C has.

Bryce 9:16

Um I don't I don't I don't think there's much arguably there. I think it's just a true fact.

Sean Parent 9:22

Yeah. So um uh uh uh Dimmy R Dimi Recordon, who's uh uh postdoc out of of Northeastern, took the idea of kind of value semantics Swift and did her thesis work 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 uh safe by default even under uh uh uh mutation, and so you would have many of the benefits that you would have with Rust as far as uh worry-free concurrency, you can't introduce a race condition because you can't have uh 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 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 in within a 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 uh uh 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 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. Um, 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. Uh uh an object that I hand off to a thread is no longer in scope within my my my current scope. Um well at the you know, at the same time that you that you have you know that whole environment going on, you're doing that all without without additional annotation and decoration. Right? So it becomes, our argument is it is if you look at how people use Swift and how you 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 Dimmy 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 the non-interference pattern, which means it or non-interference property, which means it's a a system that has all the safeties, all the memory safety, all the security, all the concurrency that you would want, but in a much more efficient way than you would get in a language with no mutability like Haskell.

Bryce 13:56

Could you just uh could you give the definition of that non-interference principle that you gave in the in the talk?

Sean Parent 14:01

Because I think that may be helpful for Yeah, so the non-interference property is basically that 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 that level of interference. Rust doesn't allow that in level of interference either, it's just more complicated to get to.

Bryce 14:56

But does this mean that doesn't this mean that you have some restrictions? Like can you can you how would you write a linked list in Val?

Sean Parent 15:04

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 a linked list is you're trying to refer both frontwards and backwards in a doubly linked list within your within your within your cells, which means you require immutable 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 that Rust can pull those those things off. Um right now within Val, unsafe is only at the statement level. We don't have block unsafe, which uh 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 is Rust mutability is to an entire heap allocated object, right? It's 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, uh uh uh we're not dealing with reference semantics, we're dealing with value semantics, and that means if you have right access to the object as a whole, you can slice that up. And you can say, oh, I want to grant right 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 right access to these two things so that they can coordinate between these parts. You can say, no, no, no, I can grant right 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 I can pass off mutability access to the first element of the vector without passing off mutability to the vector as a whole.

Bryce 17:31

Right, right.

Conor 17:32

That makes a lot of sense. Yeah. I've got a a quick question here. So back at CPP North 2022, when you gave your keynote of uh I think it was C a tragedy in two parts, which was gotta be one of the best talks that I've seen from you in your I mean you've got so many good talks.

Bryce 17:49

Yeah, that was one of my favorite Sean talks.

Conor 17:51

I mean, you gotta we'll we'll link in the description all of his best talks, obviously C seasoning.

Bryce 17:56

My my favorite still is that keynote at C now. A vignette in three parts?

Conor 18:01

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 we'll link all of Sean's greatest hits in the show notes. But in that talk, you mentioned Val, and you mentioned Val as 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 Bryce chatting you're saying that the the need for unsafe is a lot less, and you don't even have unsafe locks, 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 Val changed, or is it it's still the same and there's just like a lot of upside? I'll hand it over to Bryce.

Bryce 19:07

I'll ask him more directly. Are you building a Rust competitor?

Sean Parent 19:11

So not quite yet. I mean Dave Abrahams and I decided just this last week that we're gonna stop referring to Val as as an experimental language. Uh you heard it here first, folks. Uh in part because we think the hypothesis we wanted to vet is 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 that don't know, if you declare a 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 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 that's coming along. We're hoping to get Val available on uh GitHub. I was just talking with Matt Godbolt at this conference about the process for that. Um we think we have enough in place that we can actually make that happen. But you said GitHub, did you mean compiler explorer? 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, uh, 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 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 dwarf for your 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 that Val has pro or that Swift has proven that that's a much more approachable model. And so Apple, um, if you were at C now, uh John McCall, who's who's one of the creators of Swift, was at C now, and he was talking about, you know, 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. Um and Apple has 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 on things called property models, and the language around that is called Adam and the 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 bytecodes, so they're interpreted systems and not compiled systems. Uh Dave Abrahams is the one person on our team with who has who has been involved in the uh creation and evolution of a few different successful languages. Yeah, so so so Dave Abrahams has the chops. Uh uh, like I said, Dimmy's a postdoc, she's super smart, um, very impressive. I've managed to get her funded uh at least through through November, which is the end of Adobe's fiscal year. I'm hoping to get her funded after that. Yeah, so 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, and that's kind of wrapping up. Uh we're hoping to make it you know 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. Uh 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 uh uh image processing and AI. Um so it makes a lot of sense that Adobe would be involved in that. It's basically a collaboration between Adobe, Google, and MIT.

Bryce 25:47

It's a very Halite's very cool, and it's it's when he says it's uh in C, it's a domain-specific language in C, but that compiles down to very, very optimized code.

Sean Parent 25:56

Yeah, and it it it can target uh uh both you know CBU, 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 the fastest way to execute this piece of code would be to do it on the GPU or or on this particular GPU. If that GPU isn't available, we'll run it locally running under under AVX512 or something like that. So so we have a fairly significant investment on that front. But you know, we're not a tooling company, we don't make our business selling tools. Uh we do s have some STKs around our products, uh, but it's it's a fairly fringe piece of our effort. Uh so and my team's very small, it's just there's just four of us.

Bryce 26:56

I was just I was just about to mention, so your team's small, so does that mean that for Val 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 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?

Sean Parent 27:17

Yeah, I think we need to grow 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 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. Um we've certainly piqued the interest of a lot of people in the industry. We mentioned before, you know, the creator of 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, we 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. Um so we have a lot of experience kind of building those bridges and sucking things through uh a fairly primitive straw. And you know, looking at Rust, my team right now is doing some experiments in Rust. So part of the ST Lab Concurrency Libraries we plan on contributing to the Rust community too. We've got our our default executor, which can we have a portable version of it, which is a high performance thread pool, um uh which can run anywhere, but we uh can also backend to the Windows Thread Pool or to Apple's lib dispatch. Um 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 with ours. On Windows, you can run it with Windows Thread Pool. Uh 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 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 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 doing that experimentation as well. And you know, my hope is it's you know, 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.

Bryce 30:45

I gotta I got a feeling, Sean, that you'll be able to punch above your weight here.

Conor 30:52

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. You want to say something to the fans?

MYSTERY SPEAKER 31:17

Yeah, the British closing times are very disappointing. I completely agree. There's lots of wine on the tables. I don't understand what's happening. Yeah, not enough time to drink at all.

Conor 31:33

Where did that come from, right?

Bryce 31:36

Low quality, high quality. That is the tagline of our podcast.

Conor 31:41

That's not the tagline. Our tagline is chaos with sprinkles of information.