Sean Parent

There. And one of my complaints about C for a long time has been that although it gets used in the GPU space widely, it hasn't embraced the GPU space. I have criticisms of other languages. You know, my only criticism of Val is that it's it's not mature yet. Right? In many ways, Val is my dream language, and and and I say that from somebody who's largely outside, right? It's not the language that I created, it's the language that Demi and Dave Abrahams created.

Bryce

If we could combine the composability and elegance and conciseness of an array programming language with the familiarity of a more general programming language, something that would be easy and natural for your average system programmer today to pick up. That is the name of your podcast.

Conor

Yes, yes. ADSP is officially a discussion with Sean Perrin. So what I'll say is that I've been listening to this. We I mean Sean and I have chatted a couple times because it's it's Thursday now and we've both been in Folkson since we've both been in Folkson since Tuesday. And I gave a talk I can't remember, it must have been back in 2019 or 2020, which was entitled Haskell type classes versus Rust Traits versus Swift protocols versus D type constraints versus C concepts. The details of the talk don't matter, but at the end of the talk, I compared these five languages, and much to my surprise, I gave there was one metric that was like developer happiness. And uh I knew a lot about Haskell, a lot about C, and not too much about D and Swift and Rust at the time. I know a little bit more about Rust now. But of all the languages, Swift had the largest like happy face on that developer happiness. And that was because just as a C developer, before I hit the stack overflows, I would just try to program what I thought was sensible in the uh Swift playground that they had kind of a gobble-like thing, which would suggest you stuff. And like 90% of the time, I guess correctly and it just worked. Whereas Rust, I'd hit a bunch of errors, Haskell, I hit a bunch of errors, D, I hit a bunch hit a bunch of errors. So what I'm hearing here is that Val sounds like the best parts of Swift. And the major problem with Swift, like I had a uh programming languages virtual meetup at the time, and I was broadcasting to the 50 members that were attending online at the time that were saying, We're gonna wrap up, we're wrapping up, because we gotta the buildings we the room closed down, now the building's closing down. But but I was pitching to the people in my group that Swift was super amazing. The problem was that it wasn't cross-platform, and I was on Linux at the time, and when I tried to develop on Linux, I hit a wall. But it sounds like Val is taking the best parts of Swift. I don't know if they're a like what their story is for Linux and stuff, but based on Eric's comments and Graydon's comments and the fact that we gotta leave, we're gonna hand the mic to Bryce, who's gonna put it in front of Sean. I'm very excited for the future of Val, is my point.

Bryce

Well, I was gonna say one of the things that seems very exciting to me about Val is that the Value semantic model seems like it makes Val a great language for concurrency and parallelism. I don't know if that's something that you designed for with with it in mind, but it seems like it makes it it will make it very easy to write parallel and concurrent code.

Sean Parent

Well, like surprisingly, that was our our initial reason for going this direction. Right? And how much NVIDIA funding do you need? So the uh you know the what started my team was Adobe was having trouble uh uh as we added more concurrency to our project and and as we moved our projects to a wider diversity of devices. Um we should walk and talk. We should walk and talk.

Bryce

We've done it before. We've done it before.

Conor

We actually walked and ran.

Bryce

We walked and ran through Venice.

Conor

Well, no, we talked and ran.

Bryce

Hang on. You you can uh you give me the one. The building's closing down. What do you mean? Okay.

Sean Parent

I can hold the mic. Okay. So the the stats were showing a noticeable uptick in problems in concurrent code versus problems in straight line code. And Adobe cares deeply about the quality of our products, and so the question became how do we address this? And if you look at concurrency models, in C they're horribly broken. In other languages, they're not great. Um the recent stuff that's going on in Swift is is passable. Um everybody talks about worry-free concurrency in Rust, but there's no standard library with Rust that interfaces with the system standard library. So from a product standpoint, there's not enough there yet.

Anastasia Kazakova

No, I think that's incredible. Oh, wait. Plus, all the podcast people are following us.

Sean Parent

Yes.

Conor

You're now on the podcast.

Sean Parent

So our original interest in Valve was around how do we build a better language for concurrency. Right?

Conor

Which wait, do you want to be on the pod? Yeah, we've got the uh are you building security or just building management? Manager, a bit of a manager. Hello, everyone. Hello. Um What would you like to say about the uh the venue here? Should people come to C on C in 2024?

Anastasia Kazakova

Uh you're gonna be in for a treat. We'll look after you well, we'll have a great time, welfare, drinks everywhere, it's quite great, great fun for everyone. Come on down. What's will you be here next year? What's your name? Uh my name's Hugh, I'm the events manager, actually. So, yeah, I'll probably be here next year. Um Yeah, it's a pleasure.

Conor

Absolutely fantastic. Thanks for being on the pod.

Anastasia Kazakova

Absolute pleasure. Have a good evening, guys. Thank you.

Sean Parent

All right, back to you, Sean. So our focus was on concurrency, and if you look, the problems with concurrency come with shared mutability. If you have shared mutability, you require synchronization. Synchronization imposes a penalty. If you can get rid of shared mutability but keep mutability, there's huge performance benefits. You get parallelism without the cost of synchronization. Okay? So that was our initial interest in Val, at least my initial interest in Val is. How come you didn't mention that in the keynote?

Bryce

You like literally Bryce would have jumped up and been calling the CEO being like because I don't think you even need to mention it because I think it's it's a very evident.

Conor

It's not evident from Rust, though. Like, and Rust has got a lot of similar interests.

Sean Parent

Yeah, so that's where we were going. And you know, what happened recently was an executive walked in my office and said, so the White House issued this report on safety, uh, memory safety. So what do we do about that? Well, it turns out uh there's a significant overlap between memory safety and the non-interference property and what's required for concurrency. So, you know, just a bit by luck, it's like, well, we have the answer. We happen to be working on something. Right, we happen to be working on something. Is this what you want? And, you know, that at least got us funding through November to continue our work on Val and hopefully pass that. So, you know, I will take it. I still want to focus on concurrency, which kind of lands back in in your two court. I know we were talking. I'd like to get uh folks at NVIDIA excited. And are we going back to the this place or are we going out somewhere?

Bryce

Well, I mean, I do need to go to my hotel and I do need to I do need to finish slides for my keynote tomorrow, but you know, I can't miss a discussion with Sean Perrin. So maybe we should go in and wrap it up. That is the name of your podcast.

Conor

Yes, yes. ADSP is officially a discussion with Sean Perrin. Okay. I don't actually know that that's correct, but that's what happened when I was here late the other night. I love that we have taken this podcast from road trip to interviewing people while walking. I mean, this podcast is just flown off the handle, you know. We had structure nominally, and now there's no.

Bryce

Now it's just chaos. We're gonna go over here. Oh look, we've got folks, we've got folks here.

Conor

People are still up. Yep. So you're you're hoping to get folks at NVIDIA interested in Val.

Sean Parent

Yeah, because I think I think the basic model lends itself to concurrency and I would like to make sure that we have a strong sit in there. We're not sitting here? I would like to make sure we have a strong model for uh you know GP GPU computation.

Bryce

And although we're not allowed to say GP GPU anymore. Jensen Bandit, they're just GPUs. They're just GPUs. GPU doesn't stand for anything, it's just ask Wikipedia, see what they say.

Conor

Yeah, it's general purpose unit, what it is.

Sean Parent

There we go. So, you know, I was talking with Connor earlier. I'm actually interested in how we take some of his interest from array languages, which have huge benefits under SIMD and GPU processing and image processing, frankly. And I think that very tight syntax, we have an opportunity to do kind of a general-purpose programming language that that incorporates Bryce is excited to be.

Conor

Well, it's all the mic from Sean, folks. If you're wondering why is Sean no longer talking, it's because Bryce literally grabbed the mic out of Sean's hands.

Bryce

I mean, if we could combine the composability and elegance and conciseness of an array programming language with the familiarity of a more general programming language, something that would be easy and natural for your average system programmer today to pick up, but also have all the power of an array programming language. Oh, that would be gameplay.

Conor

You have to understand that Bryce is staring deep into my eyes when he says when he says the familiarity.

Sean Parent

So I think in Bryce's uh uh speak that means more parentheses. Yeah. Yeah, but you know, I think there's there's huge value there. One of my complaints about C for a long time has been that it hasn't, although it gets used in the GPU space widely, it hasn't embraced the GPU space.

Conor

And and even that's a quote there.

Sean Parent

Yeah, and even in the you know, when you look at at the work that's been done on vectorizing compilers, it's been what I refer to as performance through optimization and not not performance by definition.

Bryce

I mean I mean, yeah, the the i it's it's funny that that C and C have become the de facto language for writing performance-sensitive code, where while at the same time it's one of the worst languages for optimizing loops, for for compiler optimization of loops. Um because you have you have like problems like aliasing, you know, you have uh with the with the compilation model, you could have functions where you can't see the definition of them, and so you don't know what they could potentially do, and because it's C, they could do anything, they could write around on memory. It is so hard to get a compiler to do a good job of optimizing and vectorizing your loops in C.

Sean Parent

Yeah. And I was talking with Bryce last night at dinner and saying, you know, when I look at the SIMD work going on in C, it's it's what I want is something closer to halide, which is let me express the math of the operation that I want independent of the data type. Because a lot of times when I'm doing an operation on, you know, for graphics, it's like I need to be able to write the operation, and that needs to work for uh for an 8-bit normalized type, which is not an 8-bit float, it's it's uh 8-bit that represents a value from 0 to 1. Which means when you multiply two of those, it becomes A times B plus 127, which is roughly your half, divided by 255. And you can't do a division by 256, because that gives you the wrong answer. And that would just be a shift, unfortunately. So you're you always have this divide by 255, which you can do uh there are very clever techniques to do, uh to do a strength reduction on that division and make it very efficient. But really, what I want to just say is I've got this type, which is a normalized 8-bit type, and I want to say A times B and get the correct result. And so I want to write an algorithm once, and then I want to be able to say stamp out code for that for SIM D that executes as 8-bit normalized, 16-bit fixed point, 16-bit half-float, 32-bit float, okay, uh all of those SIMD optimized, and then do the same thing GPU optimized for all of those kernels for all of those algorithms. And there's nothing in the SIMD library that lets me get even close to being able to represent something in a generic form in that fashion and provide my types and stamp out that data. The closest thing right now is halide. And you know, I think there's an opportunity here for us to say, look, when we say generic code, what we want to be able to say is generic code on a GPU, on a vectorization unit, where we say our value is represented this way, and we can stamp out efficient code for SIMD, for GPU, regardless of how we're representing our value.

Bryce

And and this is, I think, uh increasingly important today as compared to five or ten years ago, because we have seen an explosion in j just in number types alone that are used. We've seen increased use of things like fixed point, which this guy has worked on a bit. Pointing at Connor here. But also just in the in the floating point space, I mean, there's been this explosion of FP sixteen and and FP eight, floating point nine. Yeah, and you know, you if you're guessing, who cares about the precision? Am I right, folks? I mean, I mean, there's there's something like four or five different just floating point formats for FP8.

Conor

I know David Olson listens to this podcast, and he will be, I'm sure, happy to be acknowledged because he's done a substantial amount of work on, you know, work on those sort of non-traditional floating point types that are important for machine learning where like we're just guessing, so who cares, you know? We don't need that much precision.

Bryce

Yeah. And I mean, I I think I also have an an interest in being able to write that sort of code in a in a generic way where I can I can easily change the data layout because maybe maybe on one platform I want the I want the data to be laid out in array of struct, but in the another platform I want it to be laid out instructive array. And maybe I want different padding or different spacing or different tiling on different platforms, and being able to write the code generically in one way and then be able to make those decisions later, I think, is increasingly important in the the world that we live in where we're seeing um uh an explosion of heterogeneous hardware.

Sean Parent

Yeah, and it's you know the closest thing we have right now is halide and Adobe's investment in halide. And you know, halide is is great, but it's also always a bridge to another system. And and so it's like, okay, well, you know, within C we have to do it one way, and then within Halide, we get to do it in a more natural way. And it's just painful. And so so I would like to be able to smooth that out and say, let's have one programming language that can do this efficiently, that can let me write, you know, my kernel operations, make the decisions afterwards about scheduling and tiling and layout of data. Um uh uh based on my target, largely those decisions will get made automatically for me outside of my system, and all of that scheduling and get very efficient code. And um uh, you know, so personally, it's like I I think there's a gap in the industry, I think there's an opportunity here, I think the timing's right. Uh I happen to think Val is is arguably the best solution, and and like frankly, I have criticisms of other languages. You know, my only criticism of Val is that it's it's not mature yet. Right? In in many ways, Val is my dream language, and and and I say that from somebody who's largely outside, right? It's not the language that I created, it's the language that Dimmy and Dave Abrahams created. But I see the value in what they've created here. Yeah, so you know, I think I think there's an opportunity there.

Conor

I mean, as a programming language enthusiast, I mean I've been in Seventh Heaven for the last two years. I mean, ever since Carbon got announced and CP2, CPP2 got announced, and even before that, I think Yacht was a thing. We actually we meant to have Richard Smith on the podcast, but then CPP Cast had him on first, and so we thought CPP Cast just interviewed him. We were trying to beat any podcast to interviewing all the successor languages. And we did have Dave Abrahams on at one point. He did talk a little bit about Val. But I mean it's been it's been a year since CPP North, and I have to say, there has been not a ton of movement, publicly at least on Carbon. There might have been a lot of internal developments, but we will link. It won't be out probably by the time this podcast gets out. It might be, but the keynote that Sean Parent gave was fantastic. The best part, in my opinion, was the QA at the end, a lot of hot takes on other successor languages. We won't repeat them here, but go watch the talk on C on C's YouTube channel. The point is, is we've got we've got Val, we've got Carbon, we've got CPP2, we've got other languages, and I have to say, and we've got Circle, so Circle in like the pure C space is what has me most excited. But sort of in the adjacent C, what's the next thing? The fact like hearing you tonight say not just you know Graydon's take and Eric's take, but that one of the get-go reasons was we don't have a language that prioritizes heterogeneous compute, and how do we target different types of acceleration? And that Val's biggest weakness is that it just doesn't have a collection of people that are building out the community. So my point here that I want to ask is if there are people listening to this podcast right now that want to get involved, is Dave the person to reach out to? Like maybe there are Rust folks that are interested in working on a different language or You heard that right. Connor's saying that Rust people should leave Rust. I didn't say that. I because that's the thing, I think Rust is an interesting language as well. But also, you know, I didn't I didn't speak up when I was hearing Sean talk about it, but the lifetime issues, like as a consumer of Rust libraries, Rust is amazing. As soon as you become a library developer and you have to deal with those lifetime issues, and you have to spell the types of these complicated things that you're returning from objects of the iterator model. I've done that. I have my own little iter X library, and I tried to compose two simple functions, zip and map, and I ended up learning a box and dyne and going to Stack Overflow, and I was like, wow, I really truly appreciate the value of function deduced return type in C now because that was painful, and it sounds like Val does not suffer from that at all. In fact, it dodges that whole issue of lifetime. So, you know, I actually haven't taken a deep dive into Valve, but my point is that I am personally excited about it, and I feel like people listening to this conversation are probably as well. So the question is for those folks that maybe want to get involved, is there a place they can go or a person they can? Contact. Not that, like you said, you're not in the community development initiative, but it's I feel like people are going to listen to this conversation and get excited the same way that I am listening to this. So feel free to just point at Dave's Twitter handle if that if that's what it is. But uh what should what should people do if they're excited and want to get involved?

Sean Parent

Yeah, I would say Dave is not on Twitter anymore for you know political reasons around Twitter. Reach out to myself on Twitter and and I can hook you up. Uh go to uh uh the Val Lang uh GitHub repo, which is pretty easy to Google and find. Yeah, yeah, we'll link to it in in the show notes, so that'll be good. And you know, it at this point it it's pretty easy. We have like a twice-a-week meeting um uh uh over Teams where we meet. We have a uh uh it's not just Dimmy and Dave, we have a couple of other external developers who who are actively contributing. Uh uh one of them is working on the concurrency model and and improving that. Uh we have an active Slack channel for for Val.

Conor

And so wait, are you telling me you have a Teams meeting that is open to people that want to get involved that any external person can join? Yeah, absolutely. I can guarantee you. I mean, actually, I can't, because I I mean I don't know how interested our our our our listeners are, but the fact that there will be a link in the show notes, folks, of this conversation where even if you don't want to start doing work, but if you just want to listen to the conversation that is happening, if you are an external person outside of Adobe, check the show notes. It'll be it'll be at the top. It'll be the number one link. I guarantee you there's gonna be a few extra people that are just sitting in on the conversation wanting to listen, and a few of those people are gonna want to get involved.

Sean Parent

And and that's great. I mean, the the only way that I see this happening is as a grassroots effort. It's gonna happen because people believe in the model and people buy into it, and and uh and individuals are willing to contribute and build it out. Right? There is not, like I said, Adobe's not in the tooling business. We're not gonna move into the tooling business. So Adobe will put some emphasis behind it, but we can't match what Google is going to put into carbon or what Microsoft is going to put into their efforts or what Apple is going to put put into their efforts. But I think that that's actually a good thing, right? If you look, you know, C didn't happen, only marginally happened because Bjarna was being backed by AT ⁇ T. But it wasn't the ATT name behind it that made it happen. ATT at least kept Bjarna in the game and kept it funded enough that a community built around it and made C happen. And I compare that to kind of Java, which I think was, you know, heavily funded. Heavily funded and and pushed down. Thank you, son. Yeah, thank you, son. Um, you know, and and and Oracle to follow. And it's I don't want that.

Conor

Yeah, right? Yeah. If it if it needs funding from a corporation to succeed, probably it it shouldn't succeed, which I'm not saying that about Java. I'm just saying that in general.

Sean Parent

Yeah. So, and I agree with that. It's like like if if this is gonna happen, it's gonna happen because it's it's the right answer at the right time. And I happen to believe it is, and you know, Dave Abrahams has been kind of dragging me along, right? Right, part of this has been like he came in, he to my team, he had a foot in Val. And and part of our agreement was, you know, come on, work on the team, and you can continue working on Val. And slowly that's become like maybe more of the team should be involved in Val. And maybe Adobe should put up some funding to help with Val. And and that's where we are right now. And it's you know, it's because I think it's the right answer at the right time. I I just do. And compared to all the other languages, I think we have the the best answer.

Bryce

So so you know, I think in a way, some programming languages that start out being driven by one company and have a lot of resources behind them struggle to move past that legacy. One of the biggest challenges that the carbon team thinks that they'll face is making it not just be a Google thing, that they want to build a community around it. They don't want its identity to be that it's a Google thing. Rust also had this in the earlier days where it was a Mozilla thing. Swift has this problem too. Some of the more successful languages didn't start out with a huge research effort behind them, and having multiple companies and multiple organizations and multiple people from all over the world, from all different backgrounds, involved in in the project instead of a single big benef uh sponsor, that I think makes a project more resilient.

Conor

I I definitely know that the the reputation of Swift is that it is like a Mac only thing because I've personally tried to do Mac or not uh to do Swift on Linux, and they have a terrible story for it. And there are people within the Swift, you know, ecosystem at Apple that are working on that, but it's just not a priority for them. They're they're focused on Swift UI, they're focused on you know iOS stuff, and that makes sense for their it's still a top 20 language. I think it's ranked like 13th or 14th in the you know programming language rankings, depending on the site that you look at. But uh there's definitely something to be said about languages like you know, C, C, you know, PHP is still a top 10 language, you know. What company is that endorsed by? Like no co no company, you know, and like in spite of people hating the language, it's still a top 10 language, and you know, you can argue that that's because of Facebook. Okay, Bryce has something to say.

Bryce

Well, I was gonna say, you know, earlier when we were talking about, you know, how what what was the size of the team that you would you would imagine for for Val, you know, Sean Sean, you said something like, you know, three to five core people, and and as somebody who spent many years of my life involved in the C committee, which is which is a room of 300 different authors, all with their own goals and objectives and perspectives. You know, I think the best thing for the for C was if we just picked eight people. It could be eight people at random. We picked eight people at random. But Barry's one of those eight people. Yeah, but seven people at random from the committee and just say, like, you're the people now. Sometimes sometimes a bigger team is not a better team. Some sometimes sometimes having a smaller, more focused team is is the right approach.

Conor

Be sure to check the show notes either in your podcast app or at adspthepodcast.com for links to everything we mentioned in today's episode, as well as a link to the GitHub discussion where you can leave questions, comments, or thoughts. Thanks for listening. We hope you enjoyed and have a great day.

Bryce

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

Conor

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