CppCast - Beast

Episode Date: January 17, 2017

Rob and Jason are joined by Vinnie Falco to talk about the Beast HTTP and Web Sockets library. Vinnie Falco started programming on an Apple II+ in 1982. He did significant work on Canvas, an early 1990s desktop publishing program that starting on the Macintosh. A while later he wrote BearShare - a Gnutella compatible file sharing program. After that Vinnie joined up with Ripple, a company that is developing a global financial settlement network built on top of a decentralized cryptocurrency and its associated ledger. Ripple has graciously given him the opportunity to develop and publish Beast, the HTTP and WebSocket library written in C++ and used in Ripple. News Winners of the 2016 Software Developer Podcast Awards The Salami Method g++7 is C++17 complete .NET Rocks: C++ for a New Generation with Kate Gregory Catch 1.6 release Order Your Members Vinnie Falco @falcovinnie Vinnie Falco's GitHub Links Beast Library CppCon 2016: Vinnie Falco "Introducing Beast: HTTP and WebSockets C++ library" Ripple Sponsor Backtrace

This episode of CppCast is sponsored by Backtrace, the turnkey debugging platform that helps you spend less time debugging and more time building. Get to the root cause quickly with detailed information at your fingertips. Start your free trial at backtrace.io slash cppcast. Episode 86 of CppCast with guest Vinny Falco, recorded January 17th, 2017. In this episode, we discussed the salami method and ordering your members. Then we talked to Vinnie Falco, developer at Ripple and author of Beast. Vinny talks to us about Beast and his long-term goals for the HTTP and WebSockets library. Welcome to episode 86 of CppCast, the only podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are you doing today? I'm okay. I'm getting over a little illness, but I think I'll make it through the podcast. Okay, that's good to hear. Well, at the top of every episode, I like to read a piece of feedback. We got a big one, and this just came in like an hour before we got on to record. I was not expecting this at all, but we apparently won the 2016 Software Developer Podcast Awards. That we did. That we did.

So thank you, everyone who voted for us. I just shared the post on Facebook, and we got two comments there. I'll read this one from Matt saying, Congratulations, well done. Your podcast, in contrast to some other software engineering podcasts, is focused and no nonsense. And with interesting guests, keep it up. Yeah. Great. So we'd love to hear your thoughts about the show as well.

You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us reviews on iTunes. Joining us today is Vinny Falco. Vinny started programming on an Apple II in 1982. He did significant work on Canvas, an early 1990s desktop publishing program that started on the Mac. A while later, he wrote BearShare, a Nutella-compatible file sharing program. After that, Vinny joined up with Ripple, a company that is developing a global financial settlement network built on top of a decentralized cryptocurrency and its associated ledger. Ripple has graciously given him the opportunity to develop and publish Beast, the HTTP and WebSocket library written in C++ and used within Ripple.

Vinny, welcome to the show. Hey guys, thanks for having me on. Really nice to talk to you today. You know, whenever our guests have something about 80s computers in their bios, I just have to talk about it for a minute. So Apple 2 Plus in 1982, were you, you know, using BASIC like I was? Or were you doing like the cool kids and already programming and assembly? Well, I didn't know anything about computers, but the Apple 2 Plus was pretty neat. It came with an instruction manual that tries to teach you BASIC, which, you know, I didn't realize at the time, but that was pretty revolutionary, coming with a tutorial. So I learned some BASIC,

and after a couple of days, I wrote my first program, and then I lost it. I forgot to boot DOS. Apparently, you need DOS if you want to save. Okay. I never really used the Apple computers like that, so I don't have a lot of history experience with them. If you don't have DOS and you try to save, then it pauses for 30 seconds and it saves to the cassette. Now, if you don't have

a cassette recorder connected, then it actually does nothing. So I spent a few hours calling Apple technical support. And finally, they figured it out. And I said, you know, is my program gone? And, well, they said yes. So that was my first experience.

And, you know, really not a lot's changed since then. That's awesome, though. And back in a time when you could have called Apple or some other computer company and actually spoken to someone and gotten technical support without paying $150 an hour or something, I'm sure these days. It's only gone downhill from there. Okay, well, Vinny, we got a couple news articles to discuss. And then we'll start talking to you about Beast and the work you're doing at Ripple, okay? Hey, that sounds great. Okay. So this first one is an article called the Salami Method, which is a method for writing cross-platform C++ code, which, Jason, I know is something we always care about, right?

Yes. Yeah, so this is targeted basically for application developers who are targeting iOS, Android, and Windows platforms, and it goes over some techniques to putting some clear definitions and layers between all the code, focusing on a strong core C++ base layer. Building up from there like slices of a salami. Exactly. Yeah, and being Italian, you know, I love salami.

I love prosciutto. I love mortadella. So the salami method, this is a great article. It has a lot of things that I like in technical articles. It's expository. You know, it's all written down. It's easy to skim through and you can copy and paste it. There's expository. It's all written down. It's easy to skim through, and you can copy and paste it. There's nice examples. And I think this shows what John

Lakos, who's the author of the book, Large-Scale C++ Software Design, he calls it levelization, which is dividing your code into successive levels where each level only calls into functions in the previous level. And that's a great way of organizing code because it helps you reason about software and it helps to isolate things, makes things easier to test. It's a very good technique. Now, that said, I don't really do a lot of development on devices. I've been primarily an application developer for quite a long time.

I build desktop applications. I've dabbled a little bit with the devices. I know that the app store markets are huge, so I'm probably missing out on a lot of profit opportunities. But the desktop is really where I'm comfortable. Those app store markets are so huge that it's also easy for your application to get lost. I understand not very many actually make a big profit on there anyhow.

So it's very true. Who knows? It's kind of like winning the lottery. Yeah. Yeah, well, I do have some experience in the mobile application world. And I will say it's nice to see an article on this because you don't really see this covered a lot, writing C++ for multiple application platforms. There's tons of examples online if you want to do something with C Sharp or JavaScript to target multiple platforms.

But C++, we know it's done. I used to do it at my previous job, and I know Dropbox and other companies are doing it, but it's just not as well documented. You don't see many examples of good methods to do this. So I appreciate this article. All right. Okay, so this next one is that we already have a C++ 17 compliant compiler, and that's GCC 7. So, you know, I think this is the second time that we've announced that G++ is C++ 17 compliant. Have we announced it? I know it's the second time that we've announced that G plus plus is C plus plus 17 compliant. Have we announced? I know it's the second time I've seen the announcement and that's because

there was actually a feature added and the last standards body meeting and then they had to get back up to compliance. Quickly got back up to compliance. Okay. Well, this is a, this is very exciting announcement. I think,

you know, we're living in an age where things have never been better for C++ developers. We've got three really great compilers that have emerged to be the premier tools. We have Clang, G++, and Microsoft Visual C. Now, the last one is debatable, but that's the one I like to use. So I think this friendly competition between the compiler vendors at really trying to turn around the new features as quickly as possible is great for developers. Now we're able to get our hands on the new stuff a lot sooner. We're able to experiment with it. So when the actual standard does drop, then it's already hitting the ground running. So at my company, the software

that we develop, which is open source, we build using all three compilers, and we try to stay on top of it. It helps our code be more robust, and it gives users who want to run the software more options about what kind of build system they want to use, and it's helped us. I would also just like to say if you do plan to play with these cutting-edge C++17 features that you can definitely easily get with GCC and Clang right now. Don't be surprised if you get random compiler crashes and features that don't work together like you would expect them to and that kind of thing. It's definitely stuff

that's still being polished. Well, even with the production official versions of these compilers, they have these little bugs, which interestingly, I didn't know about until I started working at Ripple four years ago. And I really started stressing the language and writing cutting edge code. So my position now is if you're developing code on a production compiler and you get an internal compiler error, that's how you know you're doing it right. You've arrived. Yeah, it's an interesting experience the first time that you're like, I know I just actually hit a compiler bug. That's weird. But yeah. Okay, the next one is actually a episode of another podcast, the show called.NET Rocks. And they just did an episode with Kate Gregory titled C++ for a New Generation. I used to listen to.NET Rocks

pretty regularly. They, as the name implies, maybe focus on.NET and Microsoft stuff, although they cover lots of different programming languages, including episodes on C++. And, you know,

if you listen to our podcast regularly, you're not going to get anything necessarily new out of listening to that show. But it's interesting to see how people outside of our community view and think about C++. Because these guys haven't touched C++ for about 10 years, probably. And it's interesting to get an outside perspective of the new features coming to C++ in the world that we're living in today. There was a comment on the.writenrocks website

from a listener of their podcast that says, it has been more than a decade since I last worked with C++, but this has definitely piqued my interest. Having spent some time tracking down my share of memory leaks, the stack semantics is particularly compelling. So it sounds like she did a good job of representing modern C++, which we know that she would have. Obviously. Yes.

This is a very interesting podcast for me because now this is going to come as a bit of a shock, but I've never actually listened to a podcast before. And I certainly recognize the irony of appearing on a podcast. It's really difficult for me to focus on just talk. When I study programming materials, I usually prefer exposition. It's a lot easier for me to digest and to be able to skim back and forth. So I admit to being a

podcast noob it's okay yeah i think podcasts have a different purpose than you know reading a blog post or article um you know kind of gets your interest peaked in a new topic and then maybe you go and find and hunt for more information later from what i understand most of our listeners listen to us while commuting or jogging or something else like that where they want to absorb more material but don't really have the ability to have visually stuff in front of them necessarily. Like an audio book. Yeah, I wouldn't recommend trying to jog and reading that slimy method article at the same time.

Run into a lamppost like that yeah okay uh next article we have is a catch 1.6 is out um and i was a little curious about this because uh i know he's working on catch 2.0 uh it says in here that he added some c++ 11 support though so i'm not quite sure what's going on there jason you have thoughts on this uh well he says standard added some c++ 11 support though so i'm not quite sure what's going on there jason you have thoughts on this uh well he says standardize the c++ 11 feature toggles okay so maybe it was already c++ 11 stuff and this is more of a bug fix to make it more usable just to make it usable for c++ 11 i guess so or something i mean i don't know i've i've used uh catch for a long time pretty much blindly i threw it it into my project, and it's worked great. And I've never had to care about any of these details. But it looks like this is largely a bug fix minor kind of release compared to the 2.0 that he talked to us about for sure. So this is a nice little library, just speaking

generally about Catch. I think having more options for testing frameworks is always a good thing. Different people have different use cases and goals. For me personally, I like to see my code coverage get as close to 100% as possible. I like to see that badge, all those badges on the GitHub page turn green, get up there. That's when you just adjust down your targets, then they turn green.

Oh, I'm going to need to try that. I have to try that. So yeah, so I think I love header-only libraries. They're a lot easier to add to a project, and they don't require any burden on your build script. Now, there's really two types of testing frameworks. You've got what I call macro-heavy and then macro-light. So cache is in the macro-heavy category. The test fixtures bear a little less resemblance to standard C++

than regular code that you might find on account of the macros. You have test case, macro, and have, you know, test case macro and require and section. So someone who's not really familiar with that library there, they might see that and get a little bit confused. It's not a bad thing, but there's a trade off, you know, you get a lot of features in terms of the reporting and control over, you know, which tests you want to run from the command line. But on the flip side, you have code that might look a little bit strange for someone who's just a C++, expecting regular C++. For me personally, I try to use the simpler test frameworks that are lighter on the macros. I wrote a very simple one for Beast.

It's no frills. Now, there's people out there who follow an even more minimalist approach to testing. They only use assert and static assert. If you're listening, you know who you are. So one of the problems with every framework that I've seen is that it doesn't help you write what I call a negative test. In other words, you want to write a code that only passes the test if the code fails to compile.

So in other words, you want to write a test that makes sure that invalid usage is flagged by the compiler. And, you know, you need cooperation from the build system for that. And, you know, different projects have, you know, varying needs for those sort of tests. But that's one thing that I'd like to see in the future more of. I've never done, I've never tried to do that. And ChaiScript actually would be a pretty good use case

for stuff that you would expect build failures and if people are using the library incorrectly. And yeah, that's an interesting point. I do things where if the code is not, the script code itself is not parsed correctly, then I have negative tests for that. But you're talking about like a meta layer above that even, like making sure people are using the library correctly at compile time.

It's an interesting idea. Exactly. Like, for example, you want to make sure that if anyone tries to make a copy of your object, which is non-copyable, you're going to get a compiler error. Right. Huh. Sounds like a good idea. Well, I guess you could do a static assert on is copy constructable type trait.

Well, but then, right, exactly. Then your program won't compile. Right. Good point. Okay, so this next last article is order your members, which is just kind of a nice refresher on alignment in classes and structs in C++ and goes over some of the new features that were added, I guess, back with C++ 11 with align of and align as. Is that right, Jason? Well, those features were added in C++ 11, but I did not get the

chance to get into this article, so I can't answer specifically. Okay. This is a beautiful article, guys. Let me tell you, this has everything I like to see. You know, the ideas are built up with a logical progression. He's got great code snippets. It's always better to show through code than to just tell. And I think, you know, a discussion of how the compiler packs a structure is, that's a very useful subject. You know, C++, one of the benefits is the ability to write very high-performance code, you know, the ability to kind of get as close to assembly language as possible.

And I think that, you know, people need to be reminded of this. A lot of times, you know, we're looking at, like, you know, these high-level designs and abstractions, but then we forget that, you know, we want to get the most out of our software. So this article has actually inspired me to cut down on the size of the Beast library web socket stream class.

And I've already managed to save 20 bytes just by reordering members. Wow. Nice. Very, very nice article. I recommend it for everyone. So something I don't see mentioned in this article, and it's possible I missed it, is that Clang actually has some warning levels

that will warn you if your data members are ordered inefficiently. And that can be helpful for people. Very nice. Clang has great diagnostics. Sometimes when I get a huge multi-page compiler error in GCC, I'll flip over to Clang in order to get a more intelligible compiler error. Right. Okay, so Vinny, we briefly mentioned it in your bio. Can you

start off by telling us what exactly is the Beast library? Okay, great. Thanks for asking. So Beast is a C++ header-only library that implements WebSocket and HTTP protocols as defined by the Internet Engineering Task Force, RFCs. The reason that it came up is because in our product, our open source product, we were using this library called WebSocket++, which is a very popular WebSocket library. We had some trouble with some of its clumsy interfaces, so I took the time to write a brand new WebSocket library that follows Boost ASIO best practices. Okay. Now, I'm sorry, I call a client-server model.

You know, the client issues a request, and then the server receives that request, and then it does processing, and then it sends back a response. So an HTTP session consists of a request-response pair happening over and over again until the connection is closed. Now, there's a problem here. What if the server wants to send unsolicited information to the client? For example, let's say you're implementing a chat server or you want to publish some type of subscription data periodically to the client. So HTTP is really not suitable for that. There's been a number of hacks to try to get it to work, like polling once per second or kludging the protocol,

piggybacking data in the headers, but those are not really good solutions. So WebSocket is the answer to that problem. So with WebSocket, you've got connections are symmetric. There's no client and server. Each side just sends a message, which is a block of bytes that's length prefixed. And any side can send a message at any time. And that's pretty much what WebSocket is.

Now, in order to speak WebSocket, the first thing you need to do is you need to issue an HTTP upgrade request, which is an HTTP message. So every WebSocket library in existence, you know, has a little bit of code to do an HTTP request and response in order to activate the protocol. So it's very common for web servers like Apache to, you know, that have the WebSocket module, you know, they dispatch it from the HTTP side. So that's why Beast also has HTTP in it as well, because people want to customize that handshake to start the WebSocket session. And so my library gives them primitives that they can use to get control over that. And then in the process, it was built up so that you can just do HTTP if you want on its own without the WebSocket. Is WebSocket commonly used in, I don't know, web-based applications right now, or is this a relatively new thing? Oh, WebSocket is extremely popular. Have you ever played, like, Slither.io or, like, Agario?

Oh, I think Slither.io I've seen, but no, not Agario. So those games are WebSocket-based. They have a WebSocket server, and then, you know, every browser has WebSocket in it, and WebSocket based. They have a WebSocket server and then every browser has WebSocket in it and WebSocket is very popular from JavaScript. So WebSocket is hugely popular. All right. This shows how long it's been since I've done any serious web development of any kind, I guess. Okay. So here's the question. Who's kind of the target audience for Beast? Is it library developers, application application developers a bit

of both so so beast has the two modules the web socket and the http now the web socket module is it's pretty full featured um it's i would say that the target audience would be application developers or library developers really anyone who wants to talk web socket they're going to have a pretty good experience with beast uh the WebSockets. Now on the HTTP side, the Beast support is what I like to call low level. It's aimed at people who want to write a library. You can use it to do simple things like just grab a plain text file from a server or, you know, post some form data. Like, let's say you have an app and maybe you want to like check a website to, you know, pull form data. Let's say you have an app, and maybe you want to check a website to pull some data. You could use it for that.

It's not heavy duty. It doesn't try to be a server or a full-featured client. But instead, it gives you building blocks that authors can use to create clients and servers that other people might use. So it's my hope that other developers and enterprising folks will build some really great libraries on top of the HTTP module in Beast. And so one of the reasons I chose Boost ASIO as the networking layer is that the author of Boost ASIO has submitted a proposal.

It's called the Networking Technical Specification, and it's on the path to becoming part of the C++ standard library. And it's about time that TCP IP was part of the C++ standard. And then once that's there, people are going to want to do HTTP and WebSocket. It's going to be the first things that people are going to want to do. So I'm designing this library with standardization in mind. Wow. That's a big goal. Yeah. So the path is first to get into Boost. And then once it's in Boost, wait for the networking technical specification to become part of standard and then do a port, which will be fairly trivial because it's not much different from ASIO.

So have you already submitted it to Boost? So that's going to happen in q1 of 2017 i'm putting some polish on the documentation and then we've got we already have a review review manager set up so that's going to happen in the beginning of this year i'm very excited about that by the way it's it's tough to get a library approved yes i understand it's an interesting project and can be difficult one yeah we've had robert on from the Boost incubator before. Are you in talks with him yet to get this product on Boost at all? So Robert Ramey, he's a great guy. I met him at the CPPCon, and I submitted Beast to the incubator

where people can go there and they can visit and they can leave behind comments. And there's been a little bit of discussion on the Boost developers mailing list. So it's all very positive, very exciting to be part of this community, which is great. Cool. Well, and I know you said you're a podcast newbie, but our last two episodes were actually about the process of getting stuff accepted to the C++ standard also. So I also met Marshall Clow, who was, I believe he was the last guest on your show. He's another great guy. He's a very prolific author, and he manages the boost algorithms library.

Wonderful, wonderful to be working with these folks. Cool. So can you tell us a little bit more about the motivation for beast? I know you mentioned you're using WebSocket plus plus, and you're having some issues with that library right so so uh the idea behind beast is to provide a library that can be like a solid building block something that people can can adopt as a standard just because it's based on asio and and so my design methodology for building a library was to copy as much of asio as possible. So all the interfaces in Beast resemble that of ASIO. You've got the asynchronous operations, you've got completion handlers, and all of the complexities associated with it. The documentation is very similar.

It was my intention that anyone who already knows how to use Boost ASIO is going to be able to pick up Beast and instantly have a good result. They're already going to be familiar with the idioms. And that's been very successful. I've gotten a lot of feedback. People think that that was the right choice and they were very comfortable with it and they were able to hit the ground running. Now, what's interesting is that

even though there's a lot of people that are looking at the repository, that have cloned the repository, I'm not getting a lot of feedback. So I'm going to be kind to myself and assume it's because they're not having too many problems. You know, when there's problems, people talk. But then when everything is going well, it's crickets. So I noticed looking at the GitHub repository that you have not actually tagged any releases yet, I believe.

So do you consider this library to be production ready or not? So that's a good question. So we're using Beast in our production servers, you know, in RippleD, the software, the open source software. I know of a couple of other companies that have adopted Beast WebSocket internally for their own proprietary products, and one of them is already shipped. The other one is still in development i can't say who they are um so so i'm pretty happy with the the stability of the software it's definitely stable you can build a web socket server or a web socket client with it and you're going to have you're going to have great results so i think it's production ready i haven't put any tags on it, simply because some of the HTTP interfaces

are still a little bit in flux, so I can't promise that they're not going to change. And also, once Beast is accepted into Boost, then the whole version numbering system changes. So I don't want to commit to saying, hey, this is a

final version until it gets through that Boost review. But for all intents and purposes, you could use the library now. That makes sense. Thank you. How does Beast compare to other networking libraries? I know I used to use Libcurl, which I know is a C-based library, but is there anything else that it can be compared to? Well, so Libcurl is interesting because that's a very robust HTTP client library that's written in C, and it's got a huge number of features. I mean, that software is very complete.

You know, it handles compression of the message body. It will decode your multi-part mime. It'll traverse a firewall. It'll handle like a 100 continue. You know, it does a lot. It has basic authentication. It's got a lot of things. Beast does not try to do those things. And it's very unlikely that Beast will ever do those things. Just because my intent is to provide like that building block that other people can step in and say, well, they can, you know, provide their own take on how to do those things. Maybe we'll see someone build a library, a C++ library on top of Beast that handles message bodies or a form posting library and that sort of thing. So Beast doesn't try to dictate how those things are going to be. It just gives people the tools to create their own ideas

on how they want to handle those things. So Beast is not a replacement for Libcurl. Libcurl is a big library. The WebSocket module, there's a lot of C++ libraries that do WebSockets. Some of them are C, but you could use them in C++. There's only one, to my knowledge, that's built on ASIO. So I think if you look at the other libraries that that's built on ASIO. So I think if you look at the other libraries that are not built on ASIO, I think they're nice for now. But once the networking

technical specification becomes part of the language, I think that those libraries are going to really fall out of favor because why would you want to have a library that uses another library instead of the standard library? I mean, there's a strong bias to prefer the standard library. So, you know, I think we need to focus on, you know, using the standard library as much as possible. You just get a better result. I've been looking forward also to ASIO becoming standardized, but I had not really thought about the fact that we have, there are significantly large networking libraries, if you will, that already are cross platform and lots of people use like the ones built into WX widgets and QT and whatever else also. I hadn't given any thought

to that. So that makes a very great point for why you would want to base your new library on Boost ASIO. Well, and also, you know, since my intention was to become part of Boost, well, it makes sense to use the networking library that's already in Boost rather than requiring another one. Right. Right. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsors.

Backtrace is a debugging platform that improves software quality, reliability, and support by bringing deep introspection and automation throughout the software error lifecycle. Spend less time debugging and reduce your mean time to resolution by using the first and only platform to combine symbolic debugging, error aggregation, and state analysis. At the time of error, Backtrace jumps into action, capturing detailed dumps of application and environmental state. Backtrace then performs automated analysis on process memory and executable code to classify errors and highlight important signals such as heap corruption, malware, and much more. This data is aggregated and archived in a centralized object store, providing your team a single system to investigate errors across your environments. Join industry leaders like Fastly, Message Systems, and AppNexus

that use Backtrace to modernize their debugging infrastructure. It's free to try, minutes to set up, fully featured with no commitment necessary. Check them out at backtrace.io.cppcast. Okay, do you want to tell us a little bit about Ripple and the C++ team you have there? Sure, I'd love to. So our open source software which is called ripple d you know it's written in c plus plus um when i came on board there was just you know one other developer and and i've helped grow the team and our philosophy is we're very c plus plus focused

we we use the latest official version of the c plus plus. You know, we adopted C++11 features as soon as they become available on all the compilers. C++14 is out now, so we're using that. You know, we've been converting our code. So we're very meticulous about trying to use new language features. Now, why is that? So we're able to refactor code to become smaller. We can make code more expressive and less likely to contain bugs,

you know, using standard library features that they've added. It's all been great. You know, we're in a golden age for C++ now. It's a wonderful time with the way that the language is progressing. So we try to bring engineers on board who love C++ language. That's like the number one criteria is that they got to really love C++. They got to stay on top of all the new developments and things like libraries such as Boost. So that's our philosophy about that.

We try to make the code very clear and well documented just because the software is open source and it implements a distributed financial system so people need to trust that this software does what it claims to do that it doesn't contain vulnerabilities and exploits and because that's where the value of the system comes from so so we use all the features of the language to make sure that the code expresses intent clearly that it's easy to verify that it's correct, and that it's easy to test. So you say that you like to use the, you want to stay at the latest versions of C++,

the latest official version. And arguably, Visual C++ is probably the compiler that holds you back, right? So does that mean like when Visual Studio 2015 came out, you guys immediately switched to it? And then when Visual Studio 2017 goes gold, you're going to immediately switch to it also? Or how do you guys balance that?

Well, so yeah, it's exactly what you said. As soon as there's a new official version of Visual Studio or GCC or Clang, we try to switch to it. Now, sometimes there's something prevents us from moving forward. There could be a bug. But these guys are pretty good about fixing those things. So we switch. We demand that our users upgrade. Because when you have a decentralized system, you know, you have all

these different servers that are running the software, and they all connect to each other. So people have to upgrade, like when we put out a new version, which happens very frequently, like maybe every six to 10 weeks, 12 weeks, people need to upgrade or else they're not going to be able to communicate correctly with the other nodes in the system. So it's a distributed system, people have to have the latest version of the software. This is not like, you know, Oracle, where you know, you're running, you can run two versions behind and not have a problem. Everyone's affected by people running the older versions. So if they want to be able to transact on the financial network, they have to use the latest version. So we're in a bit of a unique

position that we're able to, you know, demand that people install the late new compilers. Yeah, I would say that is a fairly unique situation. Definitely. I believe it was your CEO or CTO who gave a keynote presentation at CppCon this year. Could you maybe give a brief overview of what exactly Ripple does with this cryptocurrency network? Sure, I'll condense his 90-minute talk into 30 seconds. Sounds great. So that was David Schwartz.

He's the principal architect of the Ripple system. Now, there was also one other author who doesn't take an active development role. So he was explaining, he gave a pretty broad overview of how decentralized systems work so so what ripple d is it's server software that you run and i don't know have you guys ever heard of netella like the file sharing system i've heard of it not used it or like for example kazaa or limewire

yeah they're all things i've heard of but okay so so the way this software works is you know you run the software, and then it goes out and it connects to other people that are also running the software. Now, how do they get the IP addresses? Well, the IP addresses circulate through the network, and then you have this mesh of people that are all running the software. And these nodes communicate with each other by sending messages that travel from computer to computer. So in the past, you know, you had Nutella, it was a file sharing network, and they use the network

to propagate searches. You know, you search for a piece of content, and you get back, you know, results, and then you can you download those files. But today, you know, we use the peer to peer technology to implement what we call a distributed consensus. That means that there's this ledger that keeps track of everybody's account balance. And people can inject transactions into the network. Like for example, I want to pay Rob $20. And then all the computers in the network see that transaction, which has a digital signature. Obviously, we need to prove that the person who's making the transaction owns the money in the account. And then the system called consensus is where all the machines in the network use a mathematical

process to agree on which transactions are going to be applied to the ledger. Now, the main problem that we're trying to solve here is what's called double spending. Like, how do you make sure that someone doesn't spend the same money from their account twice? So in order to do that, you have to have a, everyone has to agree on like the balances and everyone has to agree on which transactions go into the ledger to produce the next ledger. So that's a pretty simplified view of, you know, how it works.

I don't want to bore you with the whole 90 minutes. So that's what the software does. And there's a lot of cryptography that goes on in there, which I'm certainly by no means an expert in. And, you know, there's some various white papers that are floating around on the Internet that explain, you know, in mathematical terms how that process works. Okay, I'll make sure to include the link to his talk in the show notes, but I think that was a pretty good TLDR of it. Thank you. You mentioned before the show that Ripple's also involved in the

standards committee. Do you want to tell us a little bit about that? Yeah. So one of the people on the C++ team, his name is Howard Hinnant. He worked at Apple and he's been very active in the C++ committee. He's written a number of papers and he's worked on Chrono. He had a hand in the Move semantics. He's working on a new library called Date, which is a pretty nifty library that lets you do calculations with dates, you know, like figure out like which month has five Fridays. Like you can answer questions like that with his library, which is pretty neat. It's very nice. So he was the motivator behind Ripple's involvement in the C++ committee.

So the company has joined the U.S. national body. Normally every country gets one vote in the committee, but lately they've given each company a vote informally. But if there's objections, then they default back to the other scheme. So we participate in the library groups, the LWG and the LEWG. And we have our team members attend the meetings. We had two people go to Issaquah. Scott Schur and Howard Hinnant went to Washington in last November. This February, there is a meeting in Kona, Hawaii. We're going to send two people there.

We participate in the LWG telecons to help process LWG issues. We've submitted a few. And we're very interested in C++ since our software is written in it. So we like to have our finger on the pulse and maybe once in a while, you know, put our hand on the stick shift. Did you have, oh no, so Gary, go ahead. Did you volunteer for the Kona trip? Just out of curiosity here. So I did not. Let me be clear about these trips is they're not a vacation you know we keep hearing that but i'm not entirely convinced yet it's true it really is i mean there's a lot of material to process

and you know you have responsibilities to vote and to provide feedback and i think people notice if you're just a warm body. I would love to go. The only issue is I'm kind of anxious about not being at my computer since I still have work remaining to prepare for the boost review of Beast. Okay. Okay. Well, I'm sure that'll help when Beast does eventually make its way towards standardization to have two members of Ripple in the LWG committee.

Keep in mind that we are talking about, you know. We're talking about years from now. Right. C++ 23 or 26 is realistic. Right. Nice long view. Okay. Is there anything else you want to share about Beast or Ripple before we let you go? Well, not about Beast or Ripple, but I really appreciate the opportunity that you guys have given me

to come onto your wonderful show and talk about these subjects. I'm a huge C++ enthusiast, and I like talking to other people in the field about it. It's always nice to meet other people that are interested in the language and that are technical, and that's great.

And once again, thank you very much for having me on. Well, sure. Thanks for joining us. And before we let you go, where can people find you online? So my GitHub repository of Beast is the best place to go. My email address is public. I'm very responsive to GitHub issues. Sometimes people are shy. They only want to submit their issue by email. That's fine too, although I do prefer it when they're public because other people can benefit from the answers. But I'll certainly respond to private inquiries. That's the best place to find me. You can also find me hanging out on Freenode IRC and the Boost channel.

There's not a lot of traffic there, but I'm in the channel and sometimes I answer questions. I ask more questions than I answer, though. Okay. Well, thanks so much for your time today, Vinny. Thanks, guys. Thanks. Thanks so much for listening in as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in. Or if you have a suggestion for a topic i'd love to hear about that too you can email all your thoughts to feedback at cppcast.com i'd also appreciate if you like cppcast on facebook and follow cppcast on twitter you can also follow me at rob w irving and jason at left kiss on twitter and of course you can find all that info and the show notes on the podcast website at cppcast.com.

Theme music for this episode is provided by podcastthemes.com.