C++ Beast Library
Pages: 12
I wonder how many people have heard about it. The C++ Beast library is a low-level HTTP and Websocket library based on Asio. Anyone who hasn't heard of it before can read about it on its GitHub page: https://github.com/boostorg/beast . I heard one of the examples it comes with even implements an actual web framework. It'll be included in Boost in Boost version 1.66.0. Those who got the beta version can already use it.
I asked about the standards committee's plans on standardizing it on their Google Group. If you want, you can read that conversation here: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/1vtlS1F1pm0 .
I hope people will give their support on this. It'd be great if this library got standardized along with the Networking TS (in C++20, preferably). Other libraries from Boost that were being considered for C++17 will hopefully be added to the standard in C++20 as well.
I asked about the standards committee's plans on standardizing it on their Google Group. If you want, you can read that conversation here: https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/1vtlS1F1pm0 .
I hope people will give their support on this. It'd be great if this library got standardized along with the Networking TS (in C++20, preferably). Other libraries from Boost that were being considered for C++17 will hopefully be added to the standard in C++20 as well.
In my opinion an HTTP or a websockets library does not belong in the standard library. The standard library should be agnostic of specific technologies such as network protocols. For example, a DEFLATE implementation could be appropriate, but not a ZIP implementation.
Plus, websockets are a fad. Do we really want to add something to the standard library that might not even be in use anymore in five or ten years?
Plus, websockets are a fad. Do we really want to add something to the standard library that might not even be in use anymore in five or ten years?
But we need a networking library that provides HTTP/S support. I've seen people complain about it. If the C++ standard library gets such a networking library added to it, we'd be able to write web server/client apps and be able to do web dev more easily. The ability to do these things is greatly overdue in the standard library.
| But we need a networking library that provides HTTP/S support. |
| we'd be able to write web server/client apps |
The standard library doesn't need to accommodate every possible use case for the language, it just needs to provide facilities to interact with the system (e.g. <chrono>, <filesystem>, <iostream>) and general utilities (e.g. <random>, <algorithm>, <memory>).
Then why don't people think of C++ as a first-choice language for web development? Why are "scripting" languages like Python preferred over C++? C++ needs to become a language that is no longer just a niche-language for when you need a high-performance solution. That's what I'm trying to say.
Last edited on
| Then why don't people think of C++ as a first-choice language for web development? |
Because there are other languages better suited to web development.
| Why are "scripting" languages like Python preferred over C++? |
Because they are better suited for the job.
| C++ needs to become a language that is no longer just a niche-language for when you need a high-performance solution. |
What makes you think C++ is a niche-language? IMO, Web Development is a niche market better suited to other languages.
| Then why don't people think of C++ as a first-choice language for web development? Why are "scripting" languages like Python preferred over C++? |
Who cares if your server can generate the page a few milliseconds faster if the main bottleneck is the network and you never handle more than 100 simultaneous clients?
Who cares if C++ developers can squeeze a little more juice out of the hardware when they're so much more expensive to employ than JS developers?
| C++ needs to become a language that is no longer just a niche-language for when you need a high-performance solution. |
Gluing a steering wheel to the cockpit of a fighter jet is not going to convince Joe Average that they can fly it. If anything that just makes the fighter jet more complicated, because now it has even more parts.
The point wasn't the Websockets thing. My point is to add to the C++ standard library whatever it needs to become a first-choice language for web development. Beast provides Websockets support, but I wasn't focusing on that to begin with. I was focusing on the HTTP support and anything else we might need.
And also, I do know some HTML, CSS and JavaScript. I took a CS course and some tutorials online that teach that stuff (and that CS course I mentioned also teaches C and Python). And I'm pretty sure a lot of programmers who know C++ or Java also know how to use those web technologies. So at least one JavaScript developer out there might know C or C++, especially the developers who took the same online course that I took. The problem isn't if they know C/C++ or not, though, it's whether or not they think C++ should be used for web development, and as long as the standard library doesn't provide facilities that make it easier, most people will think they shouldn't use it for web development. And it's that very thing that I have a problem with.
And also, I do know some HTML, CSS and JavaScript. I took a CS course and some tutorials online that teach that stuff (and that CS course I mentioned also teaches C and Python). And I'm pretty sure a lot of programmers who know C++ or Java also know how to use those web technologies. So at least one JavaScript developer out there might know C or C++, especially the developers who took the same online course that I took. The problem isn't if they know C/C++ or not, though, it's whether or not they think C++ should be used for web development, and as long as the standard library doesn't provide facilities that make it easier, most people will think they shouldn't use it for web development. And it's that very thing that I have a problem with.
Last edited on
| My point is to add to the C++ standard library whatever it needs to become a first-choice language for web development. |
Why do you think that C++ should be the tenth choice for web development much less the first choice?
| I was focusing on the HTTP support and anything else we might need. |
Why?
| And I'm pretty sure a lot of programmers who know C++ or Java also know how to use those web technologies. |
Okay, and your point is?
| So at least one JavaScript developer out there might know C or C++, especially the developers who took the same online course that I took. |
What does JavaScript have to do with C or C++, it is as it's name suggests a script language isn't it?
| The problem isn't if they know C/C++ or not, though, it's whether or not they think C++ should be used for web development, |
Why should C or C++ even be concerned with web development?
| and as long as the standard library doesn't provide facilities that make it easier, most people will think they shouldn't use it for web development. |
And what is wrong with that? I think it is a very good thing that C and C++ aren't considered good candidates for web development. Look at how much problems you have been having with your C++ book, do you really think that C++ should be a first choice for something as "simple" as web development?
| it's whether or not they think C++ should be used for web development, and as long as the standard library doesn't provide facilities that make it easier, most people will think they shouldn't use it for web development. |
The standard library also doesn't provide any facilities for GUI development, or for game development, or for high performance computing. Yet people do use C++ for all these things. The lack of OpenGL interfaces in the standard library never stopped anyone from making a game in C++.
The people who want to do web development in C++ already do it, with the standard library not even supporting networking. So what's the use of adding HTTP or whatever?
If someone doesn't want to do web development in C++ just adding a few facilities to the standard library isn't going to cut it. Myself, I have ample experience in C++ and I wouldn't write a web server in C++. Why would I, when I can accomplish the exact same thing in C# in a fraction of the time?
C++ directly gives programmers facilities that allow for high performance computing. The standard library doesn't need to do anything for that because it's how the language is made. As for GUI development, it seems like the standards committee is considering it. One of the technical specifications implements a 2D Graphics library. There's also a technical specification for a 3D Graphics library. And of course there's also the Networking TS. You do see these things are already happening, right? The standards committee wants to give us these things, and Stroustrup himself wants a networking library to be added to the standard. Lots of people think we need it.
There are people who thing C++ is a horrible language that needs to be burned with fire. And there are also some who think that it's complicated and hard to learn. The former one I can't really do anything about, but at least the latter one needs to go.
@jlb: Yes, I've been having difficulty with the book, but modern C++ itself isn't really that hard to learn, is it? What have I been having difficulty with? Do you really think it's the language itself? It's not. The language itself is easy.
Part of the reason people think C++ is a hard language to learn and use - even though it actually isn't - is that the programmers using it make it seem hard with the way they write their code. And they also say things that make people who are new to C++ think it's hard. But modern C++ is like a whole new language and it's actually not that hard to learn if you really think about it.
There are people who thing C++ is a horrible language that needs to be burned with fire. And there are also some who think that it's complicated and hard to learn. The former one I can't really do anything about, but at least the latter one needs to go.
@jlb: Yes, I've been having difficulty with the book, but modern C++ itself isn't really that hard to learn, is it? What have I been having difficulty with? Do you really think it's the language itself? It's not. The language itself is easy.
Part of the reason people think C++ is a hard language to learn and use - even though it actually isn't - is that the programmers using it make it seem hard with the way they write their code. And they also say things that make people who are new to C++ think it's hard. But modern C++ is like a whole new language and it's actually not that hard to learn if you really think about it.
| C++ directly gives programmers facilities that allow for high performance computing. |
| As for GUI development, it seems like the standards committee is considering it. One of the technical specifications implements a 2D Graphics library. There's also a technical specification for a 3D Graphics library. And of course there's also the Networking TS. You do see these things are already happening, right? The standards committee wants to give us these things, and Stroustrup himself wants a networking library to be added to the standard. Lots of people think we need it. |
As for those proposals you mention, I'm neither in favor nor against them. Unlike HTTP or websockets, they're not tied to any specific technology that might fall into obscurity any day.
| And there are also some who think that it's complicated and hard to learn. The former one I can't really do anything about, but at least the latter one needs to go. |
| The language itself is easy. |
What I was talking about was the fact that C++ is fast. You can write high speed, high performance applications in C++ directly because we have access to the hardware's memory via pointers. And C++11 and 14 also gave us smart pointers so that we don't have to worry about managing memory manually. Now understanding how to use smart pointers is another matter altogether. But yeah, again, there's no need for the standard library to do anything for high performance application support because the C++ core language supported that from the beginning.
And we do at least need to fill in the gaps in the standard library. Make C++20 or 23 a ground-breaking update like C++11 was so that hopefully the people that left C++ for other languages can at least consider coming back. It might make the language more complicated to learn, but we have people like Stroustrup who push for simplicity so it's probably fine (i.e. there will still be people who manage to find simplicity even with the added complication, and will find a way to teach how to use it).
And why do you think HTTP is going anywhere? Nowadays, web applications are in control. And the main protocol of the web is HTTP. So it might be for the better if the standard library supported the protocol directly.
And we do at least need to fill in the gaps in the standard library. Make C++20 or 23 a ground-breaking update like C++11 was so that hopefully the people that left C++ for other languages can at least consider coming back. It might make the language more complicated to learn, but we have people like Stroustrup who push for simplicity so it's probably fine (i.e. there will still be people who manage to find simplicity even with the added complication, and will find a way to teach how to use it).
And why do you think HTTP is going anywhere? Nowadays, web applications are in control. And the main protocol of the web is HTTP. So it might be for the better if the standard library supported the protocol directly.
Last edited on
| What I was talking about was the fact that C++ is fast. You can write high speed, high performance applications in C++ directly because we have access to the hardware's memory via pointers. |
| And we do at least need to fill in the gaps in the standard library. |
| Make C++20 or 23 a ground-breaking update like C++11 was so that hopefully the people that left C++ for other languages can at least consider coming back. |
| Nowadays, web applications are in control. And the main protocol of the web is HTTP. |
Actually the move in the past few years has been to move everything to HTTPS. Are we going to have crypto in the standard library, now? Is the committee even able to keep pace with advances in this sector to maintain a secure standard library?
| And why do you think HTTP is going anywhere? |
Personally, I think the web is such a clusterfuck that it should be thrown out and started over from scratch, but then I'm not a web developer and never want to be, so what do I care?
Last edited on
| Yes, I've been having difficulty with the book, but modern C++ itself isn't really that hard to learn, is it? |
Well it seems that you're having quite a bit of problems with modern C++ so what do you think?
| Do you really think it's the language itself? It's not. The language itself is easy. |
If the language is so easy why are you having so many problems?
| You can write high speed, high performance applications in C++ directly because we have access to the hardware's memory via pointers. |
What? Just because C++ has pointers doesn't mean you have direct access to the hardware, in fact most modern operating systems go to great lengths to prevent direct access to hardware. But really pointers are an argument for not using C++ for web development.
| And we do at least need to fill in the gaps in the standard library. |
And what are the gaps that you are talking about?
| Make C++20 or 23 a ground-breaking update like C++11 |
What? There were major problems implementing that major update called C++11, it took several years for the compiler makers to come to grips with all of those changes. Having smaller updates more frequently really seems to be the better option.
@jlb: The difficulty I have isn't with the language itself. You seem to have mistook my difficulty with (custom - as in those that I have to write myself) algorithms and other uses of the language with a difficulty with the language itself. These are two different things.
As for filling in the gaps. You should already know what I mean, right? Coroutines, Modules, DateTime (though I'm not sure if Boost.DateTime already made it into the standard - did it?), Asio, etc. There are quite a few thing that the standard library doesn't have that programmers these days want in a modern programming language.
The parts of Boost that were proposed for standardization for C++17 but haven't made it in yet should make it in ASAP. Hopefully in C++20. That's what I'm saying. And IMO, one important update would be to make the standard library more directly web-ready. But that's just my opinion so if you guys disagree, then we should probably just agree to disagree.
Edit: Let's not forget about the Ranges TS among the things that should be standardized.
As for filling in the gaps. You should already know what I mean, right? Coroutines, Modules, DateTime (though I'm not sure if Boost.DateTime already made it into the standard - did it?), Asio, etc. There are quite a few thing that the standard library doesn't have that programmers these days want in a modern programming language.
The parts of Boost that were proposed for standardization for C++17 but haven't made it in yet should make it in ASAP. Hopefully in C++20. That's what I'm saying. And IMO, one important update would be to make the standard library more directly web-ready. But that's just my opinion so if you guys disagree, then we should probably just agree to disagree.
Edit: Let's not forget about the Ranges TS among the things that should be standardized.
Last edited on
| You should already know what I mean, right? |
| Coroutines, Modules, DateTime, Asio, etc. |
The other things I do think would be a fit for the standard library, but if they're never included that's also fine.
HTTP and websockets, on the other hand I think do not belong.
I feel like we're on completely different wavelengths here. You're still not understanding me. The reason I mentioned Coroutines was to list one of the things I think need to be in the standard that aren't. I.E. the gaps in the standard library that I was talking about that Jlb wanted me to clarify.
You do realize, Helios, that I'm talking to both you and Jlb here? When I don't mention one of you with @<name>, assume I'm talking to both.
Coroutines, Modules, Concepts, DateTime, Asio, Beast, and anything else in Boost that isn't in the standard library yet.
And I think you just contradicted yourself. You said before that networking doesn't belong, and yet just now you didn't argue with Asio needing to be in. You do realize that the Networking TS is based on Asio? And that Beast being standardized depends on the Networking TS being standardized?
You do realize, Helios, that I'm talking to both you and Jlb here? When I don't mention one of you with @<name>, assume I'm talking to both.
Coroutines, Modules, Concepts, DateTime, Asio, Beast, and anything else in Boost that isn't in the standard library yet.
And I think you just contradicted yourself. You said before that networking doesn't belong, and yet just now you didn't argue with Asio needing to be in. You do realize that the Networking TS is based on Asio? And that Beast being standardized depends on the Networking TS being standardized?
Last edited on
| The reason I mentioned Coroutines was to list one of the things I think need to be in the standard that aren't. |
| You do realize, Helios, that I'm talking to both you and Jlb here? When I don't mention one of you with @<name>, assume I'm talking to both. |
| You said before that networking doesn't belong |
Ah, I misunderstood you then. I'm sorry for that (on the networking). So the only thing we disagree on is whether or not the networking library should directly support web technologies directly. Because I actually think that the standard library should try to stay up to date with web technologies.
I said "need" there because I think it's one of the blanks that should be filled in the standard library.
@jlb: I forgot to say this earlier. You said
You know, I don't understand why you want C++ to be thought of as hard. Complexity is the enemy of simplicity. Code should be kept as simple as possible. That's something Stroustrup preached in PPP2. You read that book, too, didn't you?
(@jlb and @helios) I disagree with just using the fact that people have difficulty with doing things in C++ as an argument to say that it shouldn't be a candidate for a language used for web development. In fact, people do already use it for that and it's actually really easy if you use the right framework or library (and if you actually understand how to use that framework or library). The standard library just needs to provide support for it directly and also give us the things we need in a modern language that Python and other web languages provide already. Some of those things, sans the web support, are already in TS papers being considered for standardization in C++20 or later. Once those things make it in, people who left C++ might come back anyway. Because at that time it'll be easier to do the things that people want to be able to do in a modern programming language. And then when the standard library gives support for web technologies, people will care about it more than they would if those other things weren't already supported directly. And that's what I think the standards committee should do. It'd be better if we got web technology support along with the other stuff, though.
And it's not really even the standards committee's fault if people think C++ is hard. It's our fault as the users. Read this: https://arne-mertz.de/why-simplify-cpp/ . I think both you and Helios should read this. It's a plea to "keep C++ simple". But it's not a plea to the standards committee, but to the users of the language. Because it's the users' code that makes other people think C++ is harder than it actually is. Or at least it's a part of it.
I said "need" there because I think it's one of the blanks that should be filled in the standard library.
@jlb: I forgot to say this earlier. You said
| And what is wrong with that? I think it is a very good thing that C and C++ aren't considered good candidates for web development. Look at how much problems you have been having with your C++ book, do you really think that C++ should be a first choice for something as "simple" as web development? |
You know, I don't understand why you want C++ to be thought of as hard. Complexity is the enemy of simplicity. Code should be kept as simple as possible. That's something Stroustrup preached in PPP2. You read that book, too, didn't you?
(@jlb and @helios) I disagree with just using the fact that people have difficulty with doing things in C++ as an argument to say that it shouldn't be a candidate for a language used for web development. In fact, people do already use it for that and it's actually really easy if you use the right framework or library (and if you actually understand how to use that framework or library). The standard library just needs to provide support for it directly and also give us the things we need in a modern language that Python and other web languages provide already. Some of those things, sans the web support, are already in TS papers being considered for standardization in C++20 or later. Once those things make it in, people who left C++ might come back anyway. Because at that time it'll be easier to do the things that people want to be able to do in a modern programming language. And then when the standard library gives support for web technologies, people will care about it more than they would if those other things weren't already supported directly. And that's what I think the standards committee should do. It'd be better if we got web technology support along with the other stuff, though.
And it's not really even the standards committee's fault if people think C++ is hard. It's our fault as the users. Read this: https://arne-mertz.de/why-simplify-cpp/ . I think both you and Helios should read this. It's a plea to "keep C++ simple". But it's not a plea to the standards committee, but to the users of the language. Because it's the users' code that makes other people think C++ is harder than it actually is. Or at least it's a part of it.
Pages: 12