Matthias: This is Rust in Production, a podcast about companies who use Rust to shape
Matthias: the future of infrastructure.
Matthias: My name is Matthias Endler from corode, and today we talk to Daniel Stenberg
Matthias: about integrating Rust into Curl.
Matthias: Daniel, thanks for being here. Can you quickly introduce yourself?
Matthias: I don't think you need a lot of introduction, but maybe say a few words about yourself and Curl.
Daniel: Sure. Hi, I'm Daniel. I am a Swedish developer.
Daniel: I started with open source in the 90s.
Daniel: I'm mostly known for being the founder and lead developer of Curl and the Curl project, LibCurl.
Daniel: And that is what I do mostly, internet transfers and protocols and Curl.
Daniel: That's my daily thing.
Matthias: And you've been doing this for quite a while and i
Matthias: saw many of your talks in person you are
Matthias: kind of a i would say popular or
Matthias: well-known developer and i guess one of the reasons why people admire your work
Matthias: is that you've been on this for many many years decades even by now you started
Matthias: with curl in i guess 1996 if you might count in the pre-precurses of curl is that correct.
Daniel: In November 1996 i looked for i wanted to download currents rates off the web
Daniel: so i looked for a tool that could do that i didn't want anything big and fancy
Daniel: just a small tool to download HTTP and i found one called httpget so that i didn't
Daniel: write but i found it and you know No, that was even before Google.
Daniel: I imagine I used AltaVista. I don't actually remember.
Daniel: But I found that tool. It didn't really work the way I wanted to.
Daniel: So I communicated with the author, a Brazilian guy called Rafael Sagula.
Daniel: And so we bounced some patches back and forth. And I became the maintainer of httpget in late 1996.
Daniel: That's how it all started, really. Okay.
Matthias: Fast forward to today, how many devices does Curl run on? Do you have a rough idea?
Daniel: Oh, I've decided to more count installations because I don't really know.
Daniel: I count somewhere around 20 billion installations of Curl.
Daniel: And it gets that many also because it typically runs in multiple installations
Daniel: in each mobile phone, for example.
Daniel: So any typical mobile phone runs like three or five copies of curl because lots
Daniel: of apps ship it independently so that there's a lot of curl everywhere yeah.
Matthias: And the moment one of the big vendors like instagram for example adds curl to
Matthias: one of their apps you have another whatever like 600 million or 1 billion.
Daniel: Users exactly and and the other way around too right if one
Daniel: of them stops using it it's going to be yeah sure
Daniel: i can lose a billion users or a billion installations overnight like
Daniel: that and it happens it goes up and down and also
Daniel: since it's open source and usually these these companies
Daniel: and product people they they just you know they pick curl and ship it in the
Daniel: products and i don't know about it i just realize it one day once you know when
Daniel: i just stumble upon it for some reason someone emails me and ask me something
Daniel: or i just happen to find it So it's very hard to actually have any accurate numbers.
Daniel: That's why I say I'm guessing we're really trying to Google,
Daniel: find the curl license and see in what kind of products, how many products are
Daniel: using this and blah, blah, blah. So it's a rough estimate.
Matthias: I guess you can just roughly estimate the numbers from, say,
Matthias: licensing terms in handbooks or something.
Matthias: I don't know if, for example, my car vendor, which is VW, maybe has your name in their handbooks. Do you know?
Daniel: They do. I'm not sure it's in every VW car, because I have screenshots
Daniel: from several VW cars with my name in it.
Daniel: So I know it's there. It's actually in most cars.
Daniel: But I don't know exactly in how many. I mean, several hundred million, surely.
Matthias: Sounds scary.
Daniel: You know, you end up in a situation like when several hundred million installations,
Daniel: it doesn't really change the scale very much when you're at 20 billion.
Daniel: So sure, another hundred million users or so.
Matthias: Doesn't that keep you up at night from time to time? Doesn't it scare you?
Daniel: Usually not, actually. It's kind of weird in that way. But I think it's because
Daniel: it's been such a gradual growth and scale and sort of development that,
Daniel: I mean, it has taken a long time to get here.
Daniel: And we have come to this point because we were at the previous point, right?
Daniel: So it's sort of building on top of previous, maybe not experiences,
Daniel: but proof that we can do this. And it's fairly reliable, right?
Daniel: And over time, we had more and more tests, more and more systems to verify this stuff.
Daniel: So I'm actually, these days, I'm pretty certain that, I mean,
Daniel: the internet won't burn tomorrow just when I do a new release,
Daniel: maybe, hopefully, you know, crossing my fingers.
Daniel: So I usually don't get too sort of scared about most devices in the world running curl by now.
Daniel: Now, it feels pretty good, actually, because it's also, you know,
Daniel: obviously, since we have come to this point, it seems to run pretty well in all of these places.
Daniel: So obviously, a lot of things have been done right.
Daniel: And we just keep on adding, you know, tightening the bolts, doing things better,
Daniel: testing more, verifying more.
Daniel: So I think we're actually, I mean, I think we're going in the right direction
Daniel: rather than having any sort of.
Daniel: Special dangers that something will i'm not saying that it can't happen i'm
Daniel: sure it will happen at some point more i mean bad things happen every now and then but,
Daniel: with a little luck we should be able to avoid at least the worst kind of outcomes.
Matthias: One thing that probably a lot of people value about curl is its stability and
Matthias: we will get to that in a second you touched on that briefly but i wonder in
Matthias: one of your talks at FOSDEM2024 you mentioned that curl runs on two planets
Matthias: now earth and mars does it also run on the moon.
Daniel: A most likely
Daniel: i would say but but again especially the space people they don't tell me what
Daniel: they do right so and and like in the mars case nasa has only said that they
Daniel: use curl in relation to that project They won't tell me exactly what they use
Daniel: it for, because that seems to be some kind of secret.
Daniel: It's used to further their mission or whatever they said.
Daniel: So I don't know. And I think it has been used on Moon, but I haven't got any proof about that.
Daniel: So I don't say it because I don't know it for sure, but possibly or likely, I don't know.
Matthias: That's so funny, though. what
Matthias: is the most safety critical environment that curl runs in that you know.
Daniel: Of i guess it's safety critical i guess that depends on your point of view but
Daniel: i mean it's used in pretty much all kinds of vehicles for example and it's used
Daniel: in a lot of medical devices i guess those are maybe the most safety critical
Daniel: ones i don't know what about.
Matthias: Power grids nuclear.
Daniel: Reactors? I don't know any of that.
Daniel: But I mean, it's also used very commonly in like financial institutes,
Daniel: like banks, insurance companies. And so it's also...
Daniel: Kind of critical in that kind of aspect that it's an infrastructure tool for
Daniel: a lot of our kind of modern society.
Matthias: Does the C in curl stand for C by the way?
Daniel: No, it stands for client or possibly for the verb "see", to see a URL.
Daniel: Because when I picked a name, I wanted it to be short and easy to type on a
Daniel: keyboard like Unix style.
Daniel: So it would be easy in short but i also wanted a url in the name because it
Daniel: would work with urls and then it couldn't be just the url but that would be
Daniel: stupid but client for urls would be fine or just see,
Daniel: urls so we kind of it worked either way so i think that would be enough and
Daniel: it was pronounceable in english so curl an english word so you know naming is
Daniel: really hard how do you name something i think it went pretty good it worked
Daniel: out pretty well because if.
Matthias: You search for it you will find.
Matthias: It so it's awesome seo the.
Matthias: Core of curl is written in c of course and with all of your experience looking
Matthias: back over two decades of working on this what are some of the things that you like about c.
Daniel: There are there are many things to like about c i think i mean first of course
Daniel: we have to recognize that I started this in the 90s and there were not many
Daniel: alternatives in the 90s for picking a language to do something like this with.
Daniel: I mean, there aren't that many options today even. So, of course, I went with C.
Daniel: Back in the 90s, C++ wasn't even an option because of the inability to do stable APIs and stuff.
Daniel: But anyway, so I think one of the primary good stuff, of good reasons to go
Daniel: with C is that it is available everywhere, literally everywhere.
Daniel: I mean, we talk about 20 billion installations everywhere.
Daniel: One of the reasons why it can run on all of these weird platforms everywhere,
Daniel: it is because it's in basic C89-flavored code sets.
Daniel: Basically, you just need a C compiler, which exists for any platform anywhere.
Daniel: So you can run it on any crazy operating system, and you could run it on any
Daniel: crazy operating system already from the, well, early 2000s at least.
Matthias: Does that mean that there would still not be any alternatives today if you started
Matthias: a project knowing that it would
Matthias: be used on so many platforms there is very little other choice is there.
Daniel: No there really aren't but but of course you could then question is it is it
Daniel: sensible to aim for that many platforms if you start a new one today you could
Daniel: of course discuss that and sure you can debate that back and forth But I think
Daniel: there are a few options today,
Daniel: and we're talking about Rust here today, right?
Daniel: So, sure, Rust is, I would say, it's becoming, it's only becoming an option.
Daniel: But for me, sticking to C has been a key, and I think it's been a key to its
Daniel: development and success over the years.
Matthias: And what other alternatives would there be? I can imagine C++.
Daniel: Yeah, people have brought up C++ over the years, right?
Daniel: But I mean, I have a strong feeling against C++ because I think it's a messy language.
Daniel: And I think because typically people mess up code written in C++.
Daniel: So it's both ways. So I'm actually, I've never been very happy with C++.
Daniel: I worked for several years at Mozilla working with C++ all day.
Daniel: But it just solidified my opinion that C++ is not my favorite language.
Daniel: So I don't want C++ in curl. And I don't think it had helped curl.
Daniel: I think it just would have made it more complicated.
Daniel: So I don't think C++ would have been a better solution in any way.
Matthias: Was it ever raised as a topic of interest to integrate C++ into curl?
Daniel: Not really. More in the way that everyone sort of, you know,
Daniel: it's easy to just bring your opinion and say, hey, you should do this.
Daniel: Someone from the sidelines just throwing, you should blah, blah,
Daniel: blah, blah. Use your copious free time to do what I ask you to do.
Daniel: But I've never considered it seriously, no.
Matthias: The same might be true for Rust. People might say, you should use Rust or you
Matthias: should rewrite it in Rust.
Daniel: It is. There are certainly similarities. Yes.
Matthias: Doesn't that put you off then if people constantly evangelize rust in that way?
Daniel: Not really. I think it's more of a pattern in how humans work.
Daniel: So the people it's so easy to just bring out, you should do this because I have seen the light.
Daniel: I will tell you how you should do things to make things better.
Daniel: It's just that people are like that and it will always go on like that.
Daniel: I just usually, you know, don't
Daniel: really care so sure you can say things
Daniel: and and bring ideas but you know ideas are
Daniel: really really easy it's easy to say something it's easy to
Daniel: come with a good idea the hard part is not the idea the hard part is actually
Daniel: making it reality right implement it do it make it happen so and so sure rewrite
Daniel: it in whatever and sure if you come along and make it happen then we can talk
Daniel: then we can probably maybe make it happen and make it a reality.
Daniel: But just throwing it out there probably won't help that much.
Matthias: And now, you said that you have sort of mixed feelings about C++,
Matthias: and a lot of people compare Rust with C++.
Matthias: How do you see the differences between those languages?
Matthias: Where would you say Rust made the right decisions, where C++ made some wrong decisions, maybe?
Daniel: I think, first of all, I'm really not a Rust developer.
Daniel: So I'm just a rookie Rust person. and I couldn't even, you know,
Daniel: I couldn't write anything in Rust.
Daniel: So my take is more sort of understanding how the system works and my experiences with C++.
Daniel: I think, for example, one of the downsides with C++ is that it is so much C.
Daniel: So that it sort of, it brings all the C and it tries to do things C++,
Daniel: which allows everyone to shoot themselves in the foot and at the same time,
Daniel: try to do everything object-oriented in the way you never figure out who's doing
Daniel: what because everything is
Daniel: inheriting everything else and you just never understand who's doing what.
Daniel: So I think by not having this based on C, I think Rust has a much better position.
Daniel: And of course, I think Rust has a much better starting point because just of
Daniel: the ownership and trying to do it memory safe and stuff like that.
Daniel: And then half of the C++ people would say, well, you can do it with C++ as well.
Daniel: But no, you can't. So, yeah, I think Rust has a much more going for it as a safe language.
Daniel: But then, I mean, I can't really tell how it works in reality in like a big code base.
Daniel: Maybe they will end up with similar problems or similar challenges. I can't really tell.
Matthias: The one thing that a lot of people from C backgrounds mention when they talk about C++,
Matthias: including Linux Torvalds, for example, is that exception handling kind of goes
Matthias: in the way of how you would want to model a lot of low-level tools like kernels
Matthias: or maybe also HTTP clients that get used in multiple billions of devices.
Daniel: That's certainly true. True. I think in general, when you do things like low-level
Daniel: code kernels or libraries in general, you don't want exceptions.
Daniel: You just want everything to be managed basically by success or not, right? Return codes.
Daniel: And yes, and then we're touching on one of these, at least.
Daniel: I'm not sure exactly what the situation is right now in Rust,
Daniel: but running out of memory.
Daniel: What happens when you run out of memory? I think for a library,
Daniel: like used by millions of applications, it should just return a failure,
Daniel: right? The operation failed.
Daniel: And then the application can decide, what do you do when the transfer failed?
Daniel: You can try it again. You can exit.
Daniel: You can, yeah, well, it's not up to me to decide. I write a library that makes
Daniel: the transfer. The transfer can fail due to certain conditions.
Daniel: Running out of memory is one of those failure conditions.
Daniel: It should just return an error. Yeah.
Daniel: So that's it. One of those things that I ran into with Rust originally, years ago at least.
Matthias: Yeah, I remember there was a EuroRust talk from 2022, and there was a point
Matthias: about OOMs in Rust, like out-of-memory exceptions or like out-of-memory situations in Rust.
Matthias: And the problem is that,
Matthias: Rust panics can be handled with a panic
Matthias: handler but if you have an OOM in Rust that calls abort and that cannot be handled
Matthias: right now so there is an RFC to fix that but the problem is not panics necessarily
Matthias: the problem is that OOMs don't panic so they cannot be handled ah.
Daniel: Right okay I understand.
Matthias: But there is another thing in Rust, which is to try and preserve memory.
Matthias: For example, you can try to allocate memory for a vector.
Matthias: And if this operation fails, you get an error, which is just a variant of the result.
Matthias: These might be things that maybe would help you make this a little bit more
Matthias: defensive. Or if you write a library, maybe you can handle these cases.
Matthias: But I don't know if such patterns are very widely used.
Daniel: Right. And for me, you know,
Daniel: I'm taking more of a stance that I think these are more identifying issues that
Daniel: are going to likely be sort of problematic to some users.
Daniel: But it doesn't really stop me. It doesn't really prevent me from adding anything
Daniel: because I can just say that, well, this is a fundamental flaw in this setup,
Daniel: but I can still support Rust written libraries, right?
Daniel: It's just, well, this is just one effect of the total thing when you build with this.
Daniel: And therefore, I like, my approach is more rather to, sure, I can support more
Daniel: stuff and certainly libraries or subsystems written in Rust.
Daniel: But at the moment, I also provide others, right?
Daniel: And I rather let my users decide or sort
Daniel: of let the world pick the combination they want if
Daniel: the world decides that we only want
Daniel: the rust written libraries then sure then we
Daniel: will see that happen and then there will be more work and more emphasis and
Daniel: more attention to the to those libraries and then they will get more improvements
Daniel: and more you know and over time they will be better and maybe that they will
Daniel: become the default options going forward or whatever.
Daniel: So I rather sort of let the, let users and the world of who are using curl.
Daniel: Pick what they want and need and go with that.
Matthias: I can imagine that one
Matthias: of your main roles in curl or just
Matthias: in general as a lead developer is risk management so being aware of all the
Matthias: unknown unknowns and every new technology like a new programming language and
Matthias: maybe trying to gauge whether this is a big risk for the project or not further
Matthias: down the line is that correct Well.
Daniel: A little bit yes and a little bit no, right?
Daniel: So, of course, I want to understand sort of the ramifications and understand what it is.
Daniel: And is it worth spending time on at all, right?
Daniel: If someone throws up something really weird, I don't want to spend time on it
Daniel: and efforts and bring it in to support.
Daniel: If it's just something crazy that
Daniel: will just make users unhappy and just turns out to be a waste of time.
Daniel: So sure, I need to sort of have some faith in it before I put in effort and do something with it.
Daniel: And in this case, I believe in Rust as a tool, method, language to do things.
Daniel: So I believe in it as a... But then I don't need to actually think that rustls will
Daniel: replace OpenSSL over the time.
Daniel: It's not up to me to decide. I can support them both.
Daniel: So sure, if you want to build curl with rustls instead of OpenSSL,
Daniel: go ahead and do that and tell me what doesn't work and we can fix that and go forward.
Daniel: And I can also leave that risk assessment to the users who are building devices, right?
Daniel: If you want to build your device and you You want to do a robot dog.
Daniel: Do you want, which kind of TLS library do you want? You decide that.
Daniel: Curl supports 12 different ones. You can pick the one that works for your device.
Daniel: I don't have to do that. I don't have to make the decision.
Daniel: I do to some regard. So if I figure out that one of those 12 libraries is really
Daniel: crappy, you know, development stops, it seems to be a really bad choice for
Daniel: users, then I can drop that and say, hey, users, don't use that.
Daniel: Here are the other 11 you should go with. So I can raise the standards and make
Daniel: sure that at least I don't recommend anything that is really truly bad.
Daniel: I try to do that so that I don't lure users into something they shouldn't use.
Daniel: But other than that, I also want users to have the choice and therefore let
Daniel: the market decide what is right and what is wrong going forward.
Daniel: It helps me because then I don't have to make that decision.
Daniel: I don't have to look in the crystal ball and say, what is the future like,
Daniel: which is the right solution, which library is going to win, which is going to
Daniel: be the better one in five years.
Daniel: I don't know. I'd support several of them and let them fight out between themselves.
Matthias: I think that's very smart. And I want to get into all of these details in a
Matthias: second, but before we go and talk about these things, can you just quickly give
Matthias: us a timeline of Rust adoption in Curl?
Matthias: When was the first time you heard about rust in general when was it proposed
Matthias: for curl when was the first little piece of library code that was pushed to
Matthias: the curl code base and so on.
Daniel: So what was the process i i was employed by mozilla from 2014 to late 2018 and
Daniel: at mozilla i of course learned about rust and i think the first public release
Daniel: was in that time period i wasn't involved
Daniel: in it in any way. I've just sort of heard of it.
Daniel: And at the end of my time at Mozilla, we also started to merge the first components
Daniel: into Firefox that were written in Rust.
Daniel: So I certainly was aware of Rust and sort of the concept and the idea.
Daniel: As I already said, I don't author Rust myself, so I'm certainly not sort of
Daniel: good at Rust, but I understand the concept, I knew about it.
Daniel: And I always sort of appreciated the idea that you could do it like,
Daniel: we did in Firefox, and sort of replace components piecemeal,
Daniel: one by one, with one written in Rust instead of the C++ one.
Daniel: So that's certainly one of the fundamental strengths of Rust,
Daniel: so that you can go one by one and improve things over time.
Daniel: So I knew about Rust for a long time ago, but then fast forward into the Curl
Daniel: project, I was actually, when I started to implement,
Daniel: I think, yeah, I think I started to implement HTTP3 in 2019, I think we started that.
Daniel: And pretty quickly, I was one of the, I think the absolutely first backends
Daniel: for HTTP3 that we support in curl is the quichelibrary written by Cloudflare,
Daniel: and that is implemented in Rust.
Daniel: So I think the first HTTP3 support we had, the first experiment,
Daniel: you know, it didn't really work, but you could, you know, do some first basic
Daniel: HTTP3 stuff. That was using the Rust library.
Daniel: So using a Rust library was never any weird thing.
Daniel: It was just sort of just, sure, that was just the nature of it.
Daniel: We can use Rust libraries as well.
Daniel: And then a few years later, I did a work with the ISRG, the Let's Encrypt People.
Daniel: And then I introduced support for Hyper, the Rust HTTP library.
Daniel: So you can actually switch out a chunk of LibCars native HTTP code and use Hyper
Daniel: instead as a build time option.
Daniel: And so, and I think in the center, I think I started at 2021,
Daniel: was it early 2022, something like that a few years ago.
Daniel: And in the same time, we also got support,
Daniel: the first support for rustls merged into curl as in the TLS option and all
Daniel: of these, so that they fit the pattern that I already mentioned in cURL that
Daniel: we have a lot of backends.
Daniel: So you can optionally pick and choose when you build cURL which kind of different,
Daniel: third-party solutions you want when you want different protocols so
Daniel: you sort of pick different libraries to go with so you can go with keys for
Daniel: HTTP3,hyper for HTTP1 and 2 and rustls for tls and then you get quite a bit of
Daniel: rust in the execution binary that becomes current but.
Matthias: All of these These libraries are still, I wouldn't say experimental,
Matthias: but they are opt-in, right?
Daniel: Yes. I think we still consider them all experimental because they are all almost there, but not quite.
Daniel: Quite annoying, actually, because they're all maybe 90, I don't know how many percent.
Daniel: I don't have any exact numbers, but they're all like 95 to 98% done.
Daniel: They're almost there. We have a few test cases that fail with them enabled,
Daniel: and we have a few quirks remaining.
Daniel: So there's just a little friction. We just need a little bit more polish in
Daniel: all of those three areas, really, to make them non-experimental.
Matthias: I just checked, and for Hyper, there were still a few disabled tests.
Matthias: For Rust TLS, there were also some disabled tests, and there was one other thing
Matthias: about IP support in certificates, which might or might not be supported by now. I don't know.
Daniel: I think that's fixed.
Matthias: Okay.
Daniel: But we have another issue right now with rustls. So they fixed their issues,
Daniel: and we still have to catch up with their fixes and adopt them and adjust things.
Daniel: So I think, yeah, we just need a little bit more time,
Daniel: a little bit more effort to make sure that everything is glued in correctly,
Daniel: at least in the hyper cases I think in several of the cases it's just the integration
Daniel: between so it's not really curl's fault it's not really hyper's fault it's really
Daniel: the integration between them that needs to be,
Daniel: polished a little bit more.
Matthias: And about this integration in general, you mentioned one of the advantages of
Matthias: Rust would be easy interop with other languages through their FFI interface,
Matthias: their foreign function interface.
Matthias: Were there any things that you encountered when integrating a backend like Hyper
Matthias: into Curl that fundamentally were different between C and Rust and would prove
Matthias: to be some challenge for a project?
Matthias: Or was it more or less easygoing?
Daniel: Yes and no, but it's actually quite straightforward.
Daniel: So there's really nothing fundamental that stands in the way of doing it.
Daniel: I think, I mean, one of the things that I'm struggling with,
Daniel: actually, in all of these three projects that are all Rust libraries,
Daniel: they provide excellent Rust documentation.
Daniel: But if you're a C programmer, you want to know how it works as a C function, right?
Daniel: What does it actually return? What does it actually do?
Daniel: And none of them actually provide C documentation.
Daniel: And sure, they convert the Rust code into a C API.
Daniel: But from a C user standpoint, it's complicated to read documentation for Rust
Daniel: and trying to understand how that actually maps to C.
Daniel: I mean, that's not actually a language thing, right?
Daniel: It's more of an issue with me as a C user trying to interface a Rust library.
Daniel: But there are things like that.
Daniel: Otherwise, I think we had some early issues with Rust.
Daniel: There were some global symbols, for example, that made it impossible to load
Daniel: two Rust libraries statically. But I think those were just, you know,
Daniel: some child diseases in the beginning.
Daniel: So I think, otherwise, I think it's pretty straightforward.
Matthias: I mentioned that if you wanted to render c
Matthias: documentation from rust there might
Matthias: be a need for a certain library or
Matthias: a certain tool that does this i am not aware of
Matthias: such a tool but it would be nice if if we had one or if if i was aware of one
Matthias: right well what do c people use for this is there a documentation tool that
Matthias: renders that that i can view online then like the html output of it or is it
Matthias: mostly integrated into the IDEyeah.
Daniel: I don't think there's no there's no standard way to
Daniel: there are ways i mean there are tools that are converting you know header files
Daniel: to documentation and stuff like that in my case i have all my documentations
Daniel: written separately standalone because i think that's the better way to do it
Daniel: but that's more of a religious taste thing rather than facts.
Matthias: As someone who used that documentation in the
Matthias: past i really appreciate that part it was really extremely well done and it
Matthias: saved me so much so much time the reason was back then that i needed to interface
Matthias: through the php extension of curl and there was an issue with it and i could very
Matthias: clearly see how the C function worked.
Matthias: Even though I'm not a C developer or I'm not really very experienced in C,
Matthias: I could still understand what was going on roughly.
Daniel: Right.
Matthias: So kudos to that. You once mentioned, and correct me if I'm wrong here,
Matthias: that users in general don't test experimental stuff.
Matthias: They don't enable optional features and they build their own core client just to experiment with it.
Matthias: Is that still the case? Is that true?
Daniel: I think that is still true to a rather large extent, yes.
Matthias: And does it also mean that the Rust...
Matthias: Code base or the rust integration doesn't get that much exposure and maybe it's
Matthias: not you know it's not handling all of the error or edge cases.
Daniel: Yes and.
Matthias: And that could be a problem for.
Daniel: Rust integration exactly so yes so there's a little bit of a chicken and egg
Daniel: thing there right so so you want people to test it out so that we can find the
Daniel: problems and fix them so that we can make them sort of not experimental so that
Daniel: people will enable them but but yes so it's certainly,
Daniel: hashed that challenge.
Daniel: I actually think, in general, I think the Rust backends have that challenge
Daniel: in general, that it is in the land between C programmers and Rust programmers.
Daniel: So it's a little bit of a hesitation from Rust programmers, and there are hesitations
Daniel: from C programmers rather than the opposite, I think. So it is a challenge.
Daniel: I also think that's why We came to 95% support in all of these three backends,
Daniel: but now we have struggled to get that final little push over the goal line because
Daniel: now it's a bit difficult,
Daniel: challenging to get that first 90%. That was easy.
Daniel: The last 10%, that's where 90% of the work is, right?
Daniel: So, yeah, it's becoming harder and harder and slower and slower,
Daniel: And it takes a particular kind of mindset and person to actually manage to take this further.
Matthias: Do you see a future where one of these Rust backends could be enabled by default?
Daniel: Sure. I think so. I think it's mostly, I think all of them just,
Daniel: they just lack someone to, you know, step up, roll up your sleeves and make it happen.
Daniel: You know, don't give up so easy and just spend whatever time it's required.
Daniel: I can't say how much time it's required. It depends on person.
Daniel: But I mean, it's not that many tests. It's not rocket science.
Daniel: It's just code, like I used to say.
Daniel: It's subtly fixable. I can imagine that if you would just spend devoted time
Daniel: and energy on it, it wouldn't take that long.
Matthias: Which one of the backends would you say is the most mature one from the three?
Matthias: We have Hyper, rustls, and Quiche.
Matthias: They all serve different purposes, but one of them might be more stable than the other.
Daniel: I'm not sure I have the oversight to say which one. I think Quiche is the least one.
Daniel: Elite sort of mature mature
Daniel: one exactly but and also because they sort of
Daniel: also consider themselves beta much more than i
Daniel: think hyper and rustls do i i imagine i
Daniel: could imagine that hyper is the one that has reached the most maturity but i
Daniel: wouldn't really i couldn't say that for sure i think rustls is also pretty
Daniel: mature they complicated our lives a little bit by changing their api recently
Daniel: so that's one of the bumps that we have to overcome you know upgrade to the new api so.
Matthias: Speaking of which isn't that an annoying part in rusted a lot of those libraries
Matthias: are not stable yet they have breaking apis isn't that a cause of churn for curl.
Daniel: Yes certainly that that sort of makes it more complicated right because then
Daniel: so like in this case it's hard to keep up with the latest changes because oh
Daniel: suddenly they changed the api so we cannot just you know upgrade to the latest,
Daniel: we have to understand the new concept because they removed the old concept and
Daniel: introduced a new one with new names and a new concept.
Daniel: So sure, it's certainly a,
Daniel: limiting factor because i mean you know we all we all like every open source
Daniel: project there's a limited amount of people and a finite amount of resources
Daniel: so what do you spend your time on every day and every hour so yeah you have
Daniel: to decide what to spend sort of where to go and maybe,
Daniel: improving the rustls back end or the hyper back end or the quiche back end is not always,
Daniel: top the top prior.
Matthias: How many people work on the rust part of curl is it a single person two is it more people.
Daniel: I think we're closer to zero right now
Daniel: so it's i mean we're not
Daniel: a project that we we don't
Daniel: have that distinction really we don't have people working in areas
Daniel: we have people working in the project or not and we're
Daniel: we're not a fixed amount of people either because we're an open source
Daniel: and we i'm the only person who works on it full time
Daniel: so there's me and then there's people who
Daniel: only did one commit and everything in there between so and who's working on
Daniel: the rust stuff i i don't think we have many people working on it regularly right
Daniel: now so i think we're closer to zero than to one right now maybe.
Matthias: That's an opportunity for some of the.
Daniel: Oh it's certainly an opportunity.
Matthias: And tell us a little bit about the curl test suite do you run all of the backends
Matthias: through the same tests and so even if the rust part wasn't enabled by default
Matthias: you would still get some exposure to real-world edge cases?
Daniel: Exactly, that's how we do it. So we pretty much have a test suite that has a
Daniel: bunch of different tests.
Daniel: So we can run tests with the curl command line tool, which is actually the most convenient way.
Daniel: And we build special dedicated tests for running lib curl tests with library
Daniel: in ways for cases that the curl command line doesn't do.
Daniel: And then we have also dedicated unit tests that just runs various kinds of functions directly. correctly.
Daniel: And then in the test suite, we build curl and lib curl basically with all supported
Daniel: TLS backends in different, and even in a few different combinations.
Daniel: And then we run the same tests with all the different TLS backends.
Daniel: So ideally then whatever you build with all the tests should run the same.
Daniel: So if you run, build with rustls and run the test suite, and then and it should just end up saying, OK.
Daniel: And then we know that all what we're testing is working OK, which should cover,
Daniel: quite a lot of TLS cases.
Matthias: How long does a usual full-blown CI run, a continuous integration run, take?
Daniel: That's a little bit annoying because some of them are slow because of CI's infrastructure reasons.
Daniel: I think it takes somewhere between, in the best case, maybe 30 minutes to a few hours,
Daniel: maybe sometimes more than a few hours when we sort of have many CI running at the same time.
Matthias: And do you have your own continuous integration infrastructure or do you run it somewhere else?
Daniel: We run it on a lot of free CI services. I think we use six different ones right now.
Daniel: So we're on basically anything you can find that offers free CI services.
Daniel: We're not all on free tiers either. We have a few bumped up power tiers as well.
Daniel: And I think we run like 140 CI jobs on every pull request.
Daniel: So there's quite a lot of builds going on.
Daniel: In total, I think we're at around 190,000 tests per pull request or something.
Matthias: With Rust compile times taking so long, wouldn't it make sense to have dedicated
Matthias: infrastructure for it or at least have one of the bigger cloud providers step
Matthias: up and provide bigger cloud infrastructure for CI?
Daniel: Sure.
Matthias: Wishful thinking.
Daniel: Exactly, sure. They would be very welcome to do that.
Daniel: I actually think right now our biggest bottleneck is actually just,
Daniel: I think, some of the Windows CI infrastructures,
Daniel: because they don't offer enough power to us and we don't pay enough,
Daniel: I guess. We could probably pay more to get more.
Daniel: So I think that's why they are queued up sometimes. That's why it takes longer
Daniel: time. not because they're busy, just because they're waiting for some parallelism
Daniel: to go down so that we can run them.
Matthias: Even if you don't write ROS code yourself, do you still have to build it on
Matthias: your local machine from time to time?
Daniel: Oh yeah. I did the entire hyper adaption in curl, right?
Daniel: So of course I built Hyper hundreds of times locally.
Daniel: So yes, update Hyper, build it, run it, test it and figure out what's wrong,
Daniel: build it again to test it. So sure. And,
Daniel: Yeah, so I'm kind of used to at least updating building hyper things or Rust things in general.
Daniel: And I built all of those Rust things locally and I test them locally.
Daniel: And in particular, when we run into problems, it's convenient to be able to
Daniel: run it and debug it locally to figure out exactly what's going on and how to fix it.
Matthias: I mentioned the long build times, but I wonder if that is true in your case.
Matthias: Did you even have problems with long build times?
Daniel: No, they're really fast. So there's no issues.
Daniel: In general, with curl, there are never long build times, actually.
Daniel: It's, in comparison, a tiny project. And all of the other sort of related libraries,
Daniel: they're all kind of small.
Daniel: I mean, in the grand scheme of things. So build times is not the problem.
Daniel: I think running tests, they take usually longer than building things.
Matthias: Now the rust ecosystem is still pretty young by,
Matthias: Looking at it at a scale from, for example, many, many decades,
Matthias: like C is around for many decades now.
Matthias: And in comparison to Rust, it's still pretty young.
Matthias: What do you believe will be in Rust's future? Looking forward,
Matthias: maybe not just two or three years, but a couple decades from now,
Matthias: do you still see it to stick around?
Matthias: I mean, for curl, it's not a huge problem because you can just disable the backends
Matthias: if you want and maybe deprecate them.
Matthias: But just what is your personal opinion on rust is it will it stay is it something
Matthias: that will be as popular as c and c plus plus in the future or do you see other
Matthias: competitors also take that space.
Daniel: Well it's really i mean talking about that long future it's really impossible
Daniel: to say right and i've never been good at telling the future so i rarely try
Daniel: to i just follow along but i i mean I mean,
Daniel: I think Rust has everything that it needs in able to become that sort of future
Daniel: C alternative that could sort of replace C in virtually every aspect over time.
Daniel: But if it does, I'm not sure.
Daniel: I don't think I've seen any other viable alternatives, rather, to replace Rust.
Daniel: At least for... I mean, in my world, I work with libraries and low-level code,
Daniel: and then many of the other new popular languages, they're not really there to
Daniel: replace C in that kind of environment.
Daniel: So I think Rust is basically the only current available alternative to C in a lot of these cases.
Daniel: And so sure, I think it certainly has a chance to do that.
Daniel: Whether it does that or not, I can't really tell.
Matthias: And if it failed, what would be your most likely reason?
Daniel: If it failed, no, I think the only reason it can fail is if something else can
Daniel: do it better, smoother, easier, fancier with something else.
Daniel: I mean, but it has to be something with a huge backing.
Daniel: So I don't see anything of that short term. But, you know, if you're talking
Daniel: long term, something can happen. I don't know.
Matthias: Do you see that some existing C tools get rewritten in Rust now?
Matthias: That seems to be a trend in other languages, but I'm not sure if it's also true for C.
Daniel: Well, I think it is. I think it is a trend. I mean, people are rewriting a lot
Daniel: of the popular Linux tools, like the bin utils and stuff in Rust alternatives.
Daniel: So I think it's over time, it will happen more and more.
Daniel: And so Yes, I think so.
Daniel: Even if my personal opinion is also sometimes that it's a little bit of waste of time.
Daniel: At least, I don't really like this popular sort of thing that every language
Daniel: should rewrite everything in their own language again, because it seems like
Daniel: that's a pattern we're doing over and over.
Daniel: Every language should always introduce a lot of things.
Daniel: And now we should rewrite it again in our new language.
Daniel: But I also understand why. So sure.
Daniel: And everyone is free to do whatever they want. So why not? If that's what you
Daniel: want to do, go ahead and do it.
Matthias: Well, one reason might be to use multiple cores and use modern hardware and SIMD and all of these.
Daniel: Exactly. And make it more safe and easier to use more threads and then thereby
Daniel: make it more efficient, faster, better.
Daniel: So sure, there are certainly, there can be many good reasons to do it, yes.
Matthias: Doesn't curl also have a way to run multiple requests more or less in parallel?
Matthias: I'm not sure if you run them concurrently or in parallel, but there is a way
Matthias: to spawn multiple requests, right?
Matthias: And how does that work? And also, did you take a very defensive approach when
Matthias: you integrated, or were you going all in because you kind of knew what you were doing?
Daniel: They don't do threads. They are all just state machines. So it's all in the same thread.
Daniel: So we do any amount of transfers in the same thread concurrently.
Daniel: So it's just a lot of state machines. Yes.
Matthias: It's very similar to async programming in Rust then, right?
Daniel: Yeah, it is virtually the same thing, just done manually. Yeah.
Matthias: And under the hood, it uses an event system like epoll, or how does it work?
Daniel: It's actually more complicated than that, because curl itself doesn't do the event system.
Daniel: It allows the application to provide the event system. So an application can
Daniel: go with any event system it wants.
Daniel: You can go with any epollor LibEvent or LibEV or LibUV or whatever you want
Daniel: and then use curl to do that.
Daniel: And then because that's typically the way how you do really high performance Lib curl transfer.
Daniel: If you want to go like several thousand concurrent transfers in a single thread,
Daniel: that's really how the way to do it.
Matthias: That's a very smart way to do it. does the curl command line tool also do it or is there no multi.
Daniel: Now the current command line tool has the dash capital z option z and then it
Daniel: does them concurrently too so you can do parallel transfers like that and then
Daniel: it can do any any amount of parallel transfers but again they're in the same thread and.
Matthias: How does the command line tool run these things it needs some sort of it It
Matthias: brings their own event handling system.
Daniel: Yeah, but then it doesn't do it with an event-based one. It just does it with
Daniel: a select-based one or poll.
Daniel: So it's a little bit less performant, but it's fine.
Daniel: As long as you're sort of below a few hundred transfers, then it doesn't really
Daniel: matter which one you go with.
Matthias: You can also use curl from Rust. And that is a very nice thing to do because
Matthias: you get all of the advantages from cURL, all of the knowledge,
Matthias: all of the hard work that was put into it.
Matthias: And you can just use Rust from your application perspective and call into cURL.
Matthias: Did you ever interact with some of the maintainers of the libcurl crate?
Daniel: I think I've been communicating with them, but not a lot. I think they've sort
Daniel: of managed most of that themselves. ourselves.
Daniel: But I think that's also thanks to us having a pretty solid product and a pretty
Daniel: good documentation situation.
Daniel: So most people can actually figure that out themselves. They don't need to ask me. They don't have to.
Daniel: As long as they can just go with what we have and they understand how it works,
Daniel: they don't need to tell me about it.
Daniel: But sure, and even cargo and stuff is using libcurl. So there's a lot of curl in Rust.
Matthias: Oh, yeah, I didn't know that.
Daniel: Yeah, so every cargo command line is using curl underneath.
Matthias: I think I should introduce a curl counter on my terminal somehow because I think
Matthias: I used it thousands of times a day. It's incredible.
Matthias: And it also runs on all of the platforms that I use. It runs on Linux,
Matthias: but it also runs on FreeBSD. It runs on Android.
Matthias: It runs on wherever. And did you run into any specific issues regarding
Matthias: building for these platforms also probably people try to build rust on some
Matthias: of the more exotic architectures as well did you ever encounter any any issues with that.
Daniel: Sure i mean every basically every new platform has the opportunity to introduce
Daniel: some new challenges right so going you have to be pretty conservative in how
Daniel: to do things to enable to just open up the opportunity to build on a huge amount of platforms.
Daniel: So it has to be close to POSIX, but also open for POSIX violations.
Daniel: And that's basically how we did it from the beginning.
Daniel: And then we've always been very careful to do if-defs for features that are
Daniel: available in the platform.
Daniel: But sure, Sure. Whenever, if you
Daniel: want to go with curl and run it on a new operating system, new platform,
Daniel: sure, there's going to be some tweaks that might be necessary to do,
Daniel: not only defining just, you know, the rich set of different features that the
Daniel: platform might or might not have, but there are also different,
Daniel: you know, one of my recent things is that I've ported curl to a lot of real-time operating systems,
Daniel: and they tend to be more crazy than other operating systems because they typically,
Daniel: for example, change some of the POSIX functions for sockets or something like
Daniel: that, because our function that makes a connect,
Daniel: it should take another argument that's used for this, which is sort of crazy.
Daniel: So then, yeah, then you have to do a special crazy thing for just that particular
Daniel: operating system and things like that.
Daniel: So it certainly takes a lot of, sometimes just a little, sometimes a lot of
Daniel: work to make it run on a new platform, a new operating system.
Daniel: But in my case, when I have this list, I have 101 operating systems that Curl
Daniel: has run on now, and most of them I never ran Curl on, and most of them I never even heard of.
Daniel: Someone else made it run there and were happy, and they just told me about it.
Daniel: So apparently it is also easy enough for others to make it run on a fair amount of different systems.
Matthias: Does it mean that other people also maintain the Rust compilation for some of these platforms?
Daniel: I don't know. Usually they don't tell me exactly what kind of setup they do.
Daniel: So I would imagine that Rust is... For the more weird platforms,
Daniel: they don't go with Rust solutions at all.
Daniel: They go with some traditional C libraries.
Daniel: So I guess they don't use the Rust ones.
Matthias: Okay. So for most platforms, you kind of know that the C code base works and
Matthias: you compile a minimal version of it.
Matthias: And maybe for some platforms, you might also provide Rust support,
Matthias: but it might be something that they have to opt in and maybe add that.
Daniel: And like always, we just ship curl as a source code, right?
Daniel: And the ones who are going to build it, they decide how to build it and with
Daniel: what sort of components and what backend.
Daniel: Ends so they are it's up to them so whatever
Daniel: wherever you build curl you can select how sort
Daniel: of which back ends to use which components so you can go with the rust components
Daniel: or the c components that's up to you so i guess and especially since the rust
Daniel: ones are all experimental and beta versions still most people would go with
Daniel: the c versions because some some of them are not experimental are.
Matthias: The backends compiled in statically or dynamically or can you choose.
Daniel: You can choose since it's all c code so you typically go it depends on your
Daniel: platform usually or your religion or something but but if you go with a modern
Daniel: system like linux you typically go with everything shared yeah.
Matthias: I looked up some of the edge cases that you ran into when you integrated the
Matthias: Hyper backend into Curl.
Matthias: And there were a few things that you raised on the Hyper issue tracker,
Matthias: which just helped improve this grade in general. I really liked that part.
Daniel: Yes, I think I ran into a whole bunch of issues.
Daniel: And I also actually think it worked the other way around, that I actually also
Daniel: fixed Curl stuff because I realized that Hyper had done solutions in a clever
Daniel: way that I could just as well do that.
Daniel: Because when incorporating Hyper into Curl, I ended up in this fun solution
Daniel: that, again, I mentioned the test suite. I run tests and they should work the same way, right?
Daniel: Even if I build with Hyper or build with a native HTTP, they should run,
Daniel: they should produce the exact same byte sequence over the wire pretty much.
Daniel: And of course they didn't at first. So I had to sort of struggle.
Daniel: Who's to blame here? Is it Curl? Is it Hyper? Is it both? Is it neither? or how do I actually,
Daniel: move forward so it was a bunch of fixes into hyper bunch of fixes in curl and
Daniel: bunch of minor adjustments in the test suite as well and.
Matthias: You also phrased it very nicely because one of the issues that you created in
Matthias: the hyper github repository was titled what's the maximum header size limit
Matthias: and knowing that it comes from you you know exactly that what you're aiming for is kind
Matthias: of an explanation as to why it is like this or why maybe it is also undefined
Matthias: behavior for all we know but i really like that you were very open for suggestions
Matthias: and also didn't really impose anything.
Daniel: Yeah and it's kind of and that boils down to that i i run into this sort of,
Daniel: awkward situation for me that you know i try to make sure that curl and lib
Daniel: curl has a situation where I know exactly how it works, I can document the limits,
Daniel: and when it runs into this, this is returned because blah, blah, blah.
Daniel: But when I then use Hyper, for example, that has its own mind and its own limits
Daniel: and its own decisions on what is right and what is wrong, then suddenly things are different.
Daniel: So when I build with a native HTTP, I have one limit, and when I build with
Daniel: Hyper, there's another limit. And in that case, I had this situation where I actually...
Daniel: Long story short, if you send an endless amount of headers to a client, right?
Daniel: You have a malicious server and you just send headers.
Daniel: Header one, header two, header three, header four, you know, and it never ends.
Daniel: That's a lot of headers. At some point, you have to just stop and say,
Daniel: I refuse to accept any more headers. It's stupid.
Daniel: Something is wrong. You're trying to take advantage of me and return an error code.
Daniel: At what point should you do that? And then I made a limit in libcurl because
Daniel: I have to stop because of just memory restraints and, well,
Daniel: and Hyper makes a different choice and they stop at a different point.
Daniel: So that's why I wanted to understand if there had been any clever thoughts or
Daniel: reasoning behind their limit.
Daniel: And I know there's been a discussion in that issue afterwards,
Daniel: because others have run into their limit, which seems to be much lower than my limit.
Matthias: A reasonable way to solve it might be to introduce a configuration or a setting for it.
Daniel: Maybe, but I've come over time to be more restrictive about options because
Daniel: people won't know what to set it to anyway. Anyway, and then you have an option
Daniel: that no one knows exactly what to set it to until you run into that.
Daniel: And then you can bump it a little bit until the next time you run into it.
Daniel: It's really difficult for anyone to have a setting for it.
Daniel: So yes, I agree. Settings are good, but it's also, and also it makes things
Daniel: complicated to add settings for a lot of things because you drown in settings
Daniel: and then you never find the setting you actually want because there's going to be a hundred.
Daniel: I already had that problem in curl that we have so many options that you won't
Daniel: find the option you want because there are so many other options you don't care about.
Daniel: In my case, I ended up looking at the browsers. What kind of limits do the browsers set?
Daniel: Because I imagine that very few users can survive.
Daniel: I mean, very few users actually have servers sending more headers than,
Daniel: popular browsers accept so if the popular browsers don't accept that many headers
Daniel: i could put the limit somewhere in there in that sort of ballpark as well that's what i went with.
Matthias: Yeah. Because you also catch two birds with one stone on one side you aim to be pragmatic
Matthias: here and maybe have sane defaults which would work for most people and on the
Matthias: other side what people expect sometimes is what the browser does.
Daniel: Exactly and they want to make they want to use our tools to do the same thing
Daniel: they did with the browser.
Daniel: So having more strict rules than the browsers, that's usually a failure because
Daniel: then people are going to complain.
Daniel: I could do this with Chrome, but curl says blah, blah.
Daniel: That's never good. So I want to make sure that we can do it.
Daniel: If you could do it with Chrome, you should be able to do it with curl as well.
Daniel: If it sends you 200K of headers and Chrome accepts that, then curl should accept it as well.
Matthias: And is the reverse also true? Did you find any issues with curl when integrating
Matthias: hyper support port and rust in general.
Daniel: I found a few things or
Daniel: i think i've been keeping to find a few things
Daniel: i think if in particular i think i've made the
Daniel: curl HTTP parser a bit stricter because i realized when i ran a few test cases
Daniel: or i don't remember how many but test cases and then i realized that the hyper
Daniel: parser is much more strict when it parses some of the HTTP details i think status
Daniel: code i I don't remember exactly.
Daniel: There were some things that at least I ran test cases and curl said,
Daniel: oh, this is fine and hyper returned error.
Daniel: And then I realized that, wait a minute, why is curl saying this is fine?
Daniel: Because it's really not HTTP compliant.
Daniel: It's actually weird status.
Daniel: So I decided then that, meh, I should make the curl parser more strict as well.
Daniel: And then made it so that curl would return error in the same way that hyper already did.
Daniel: So in that way, I think it was a benefit for me to make sure that,
Daniel: oh, I sort of just opened my eyes because curl had been doing that for 20 years already.
Daniel: And then just made me think that why is it accepting a two-digit status code
Daniel: when the spec says it should be three digits?
Daniel: And I made it fail if it's not three digits, like Hyper did.
Daniel: So things like that. I don't remember the details, but I remember there were
Daniel: a few other things as well that just made me realize when I could try with hyper
Daniel: and native, hyper native,
Daniel: and then sort of realize the differences, and then figure out that some of the
Daniel: things that Curl did natively really wasn't making much sense.
Daniel: It should just be a little bit more.
Daniel: Different than i had it before so it has been a sort of an improvement to the
Daniel: native parser as well yes.
Matthias: And it's also not a breaking change since it doesn't change this curl api it
Matthias: just changes the parsing outcome.
Daniel: Yeah the only the only risk is that there were actually
Daniel: two users you know one in three one in
Daniel: a million that actually gets a two-digit status code you know
Daniel: that's always a danger and that's always that's one
Daniel: of the sort of that's the reverse issue that
Daniel: i've had with with hyper that they are they've been too strict about things
Daniel: because you know the spec says something yeah yeah the spec says it should be
Daniel: like this yes it does but you know out in the real world there are two users
Daniel: who deployed something in 20 years ago,
Daniel: and that's not compliant, but they're still in use, right?
Daniel: That's sort of the collision, the real world versus the spec.
Daniel: And that's a complicated thing because then you need to make up your mind. Who's right here?
Daniel: Should we adopt according to the world or according to the spec?
Daniel: And then that's really difficult.
Daniel: In my case, I often have a way that we already work, right?
Daniel: So I want to make sure that we keep working like that so that we don't break.
Daniel: Like if it worked with that weird case already and people are using that weird
Daniel: case, I don't want to break it.
Matthias: Right.
Daniel: But if nobody is using that weird case, then we shouldn't accept it.
Daniel: So it's not that easy to figure out.
Matthias: Rust has this notion of soft breaking
Matthias: changes where sometimes it would be technically a breaking change.
Matthias: But since they run it on all the crates with a tool called Crater,
Matthias: they can ensure that it's not used...
Matthias: Very rarely used in the real world.
Daniel: Right, right. Yeah, it's difficult.
Matthias: It would be nice to have such a tool for Curl, but I mean, no one will tell you when they use it.
Daniel: Yeah, and really you can't know because in Curl we have this constant dilemma
Daniel: that people have really, really long upgrade cycles.
Daniel: So sometimes it's actually quite common that someone shows up in the mailing list and say, hey,
Daniel: I have a problem with this curl version that, you know, 14 years old and does
Daniel: this, you know, it's a wonder that it still works, right?
Daniel: And then say, well, I only have this issue.
Daniel: I don't want to upgrade because I only have this tiny issue.
Daniel: Or the reverse. Sometimes they say, well, I did the upgrade from,
Daniel: you know, the version 14 years ago to the current version. And then they discovered
Daniel: a tiny little change in something like that.
Daniel: Maybe I no longer accept two-digit status codes. They have to be three.
Daniel: And it doesn't work for our use case because blah, blah, blah.
Daniel: And they've been living under a rock for 14 years and worked with that weird case, told nobody.
Daniel: And it worked with that version that we shipped ages ago.
Daniel: And now suddenly it doesn't work because at some point during those 14 years,
Daniel: which did a minor change, nobody noticed. Nobody cared about it because it was spec-compliant.
Daniel: The API and API still work the same.
Daniel: But a user eventually figured out that it broke something somewhere.
Daniel: So it is a challenge. And then, of course, again, who's right and who's wrong?
Matthias: Perhaps one more question about hyper integration.
Matthias: Recently HTTP2 support for hyper was disabled and there is a pull request,
Matthias: but apparently it seems like there is a redesign that needs to happen for re-enabling it.
Matthias: Can you still remember some of the details of what is missing there?
Daniel: Sure. So Hyper supports HTTP 1 and HTTP 2. And I think they have experimental HTTP
Daniel: 3 support even, which I think is going to add even more challenges for me to support that.
Daniel: But I've sort of not gone into the HTTP 3 one with Hyper yet.
Daniel: We have four backends for HTTP 3 already in curl.
Daniel: So the HTTP 1 and HTTP 2 one turned out to be a problem that I had misunderstood
Daniel: how basically where the storage and how to manage HTTP 2 requests is.
Daniel: HTTP 2 can do many streams
Daniel: right over the same physical connection and and
Daniel: curl of course supports vp2s and you can also
Daniel: do streams over connections but so it was
Daniel: mostly a matter of me having misunderstood
Daniel: exactly how to use the hyper api to
Daniel: do streams over a single connection so when
Daniel: we when i tried to do more streams over the
Daniel: same connection well the life there was a lifetime
Daniel: setup issue i don't remember the
Daniel: exact details but it turned out to basically i
Daniel: used it wrong and stored the data in the wrong place in curl so i had to sort
Daniel: of back that out and and sort of we have to come back to that and i have to
Daniel: sort of dive into it and understand it again how the hyper api actually because
Daniel: i thought i used it correctly but apparently i had misunderstood it so i need to,
Daniel: go back and figure out exactly what they what the requirements are for the api
Daniel: to do streams streams properly for it to be too.
Matthias: Yeah and i guess this symbiosis helps both sides see rust curl hyper like the
Matthias: other crates everyone profits in the end.
Daniel: I think so too as long as we just cooperate and you know we're open and,
Daniel: for i mean and just make sure that we try to move forward and ask each other
Daniel: how how things supposed to work how do you think how do you do this in your
Daniel: project and sure i think it's that is just a matter of time.
Daniel: We will get there eventually.
Matthias: Overall, would you say your Rust experience was good so far?
Matthias: Would you make the same decisions again? Were you happy?
Daniel: Well, I think I'm content. I'm happy.
Daniel: And I think from my point of view, I think I'm happy with my way of solving,
Daniel: or not solving, rust into curl by making sure that we can build with rust components,
Daniel: rust backends, or replace parts of curl with rust-written alternatives.
Daniel: And I imagine that going forward into the future, we could do so with other
Daniel: components of curl, possibly replace other backends or introduce new ways to
Daniel: do backends that could be written in Rust.
Daniel: So over time, maybe we could have even more Rusts in a future curl binary.
Matthias: Do you have a favorite talk or blog post on the topic that people who want to
Matthias: learn more can learn more about?
Daniel: I think the best way is to just find my YouTube channel and search for Rust.
Daniel: I think I've talked about it a few times.
Matthias: We will definitely add it to the show notes. And yeah, I also think that this
Matthias: would be a great resource.
Matthias: Source i also like your blog posts so anyone who's listening do check out the
Matthias: blog posts sometimes they are even hilariously funny i remember the one i guess
Matthias: you have an entire blog post about you to like something like i could write
Matthias: curl in three days or something like this or on a long.
Daniel: Weekend yes yeah that's one of my favorite quotes.
Matthias: And you collect those posts i think this is great also great marketing.
Daniel: Thank you yeah i think it's
Daniel: fun and for some reason it's so easy for people
Daniel: to just be a little bit dismissive and say well it's just an HTTP client i could
Daniel: rewrite i could write that easily in a weekend and yeah i think i think people
Daniel: actually honestly think they can and maybe they can in you know in some very
Daniel: limited restricted way you can make an HTTP client in a weekend,
Daniel: depending on conditions and things.
Daniel: But I think Curly is a little bit more than that.
Daniel: I've been doing this for 27 years now.
Matthias: And I don't think that there's a reason to stop now.
Daniel: No, no. I mean, it's nowhere near an end or a closure.
Daniel: It's rather the opposite. It's more More activity, more development,
Daniel: and more speed in everything now than ever before.
Matthias: How can people support the work? If they wanted to chime in, what could they do?
Daniel: Well, there is everything. It's just wherever you want to participate,
Daniel: right? It could be working with Rust stuff.
Daniel: It could be polishing documentation. It's understanding the build or working
Daniel: with the CI or just figuring out sort of how to make sure that the test suite runs better.
Daniel: So that's really where I often,
Daniel: just try to encourage people to join in and do what they think is fun or where
Daniel: they think they find a problem where they want it to work better and go with
Daniel: that because having fun is important,
Daniel: when you want to get something done.
Daniel: So if you're interested, since this is a Rust podcast, so if you're interested
Daniel: in Rust and one of these Rust components and getting it to run better in curl,
Daniel: that's an excellent opportunity Because we're certainly not overstaffed when
Daniel: it comes to people working on the Rust backends in curl.
Daniel: So there's, as we mentioned, there are test cases to make sure that they work
Daniel: better. And they're sort of, we need to upgrade to the latest Rust, rustls API.
Daniel: And I'm sure that there are flaws to work on in Rust related things in all of these backends.
Matthias: If anyone is interested, check out the show notes. We will make sure to add
Matthias: a few links there to get you started.
Matthias: And if a pull request or two comes out of this, that would make me extremely happy.
Matthias: Now, it has become sort of a tradition around here to ask one final question,
Matthias: which is, what would be your message to the Rust community?
Matthias: If you could say anything that is on your mind, if you wanted to dedicate a
Matthias: message to everyone that uses Rust or is considering to use Rust, what would it be?
Daniel: I think I've just reframed from that. Join in, make things happen, have fun.
Matthias: This is the one thing which is my takeaway from your last FOSDEM talk.
Matthias: On every slide, you had the words, have fun.
Matthias: And as someone that also maintains some open source code, not as popular as
Matthias: yours, but I understand that sentiment.
Matthias: This is, I guess, the core part because if you have to do something for months
Matthias: and years if you don't have fun doing it you can't get there.
Daniel: No no i'm absolutely sure that as long
Daniel: if it's a spare time project or something you don't do full
Daniel: time if it's not fun it's not going to be done right then you're just going
Daniel: to not then you're going to do something else that is fun so yeah i think it's
Daniel: important and that's why i always try to encourage people when they want to
Daniel: participate join you know what What should I do when I join and do something
Daniel: open source or do something Rust? Do whatever you want to do.
Daniel: Do something that you think is fun, you think needs to be done or could be fun
Daniel: to have happen or you're missing or you think would be cool.
Daniel: That's where you should at least start out with.
Matthias: Daniel, I have to thank you for your time, for taking the time to do the interview,
Matthias: and for being such an approachable person someone that is so well known and
Matthias: popular you're still down to earth someone that you can talk to and approach
Matthias: and you it is very very fun to interact with you so i had a lot of fun and i
Matthias: have to thank you for that.
Daniel: Well thank you it was fun being here.
Matthias: Rust in Production is a podcast by corrode and hosted by me Matthias Endler
Matthias: for show notes transcripts and to learn more about how i can help your company
Matthias: make the most of Rust, visit corode.dev.
Matthias: Thanks for listening to Rust in Production.