Hacker News new | comments | show | ask | jobs | submit login
Building a Website with C++ (sourcerer.io)
95 points by daftpanda 10 months ago | hide | past | web | favorite | 109 comments

Really? Escaping, people! This code isn't practical or useful; it's dangerous and sloppy.

    cout << "<body>\n";
    cout << getenv("QUERY_STRING");     
    cout << "</body>\n";

FWIW I wrote an article about HTML escaping and shell here: http://www.oilshell.org/blog/2017/09/19.html

Followup: http://www.oilshell.org/blog/2017/09/29.html

Also if you want to use a native language for web sites (which I don't), Go is a better choice, as the standard library has html/template which protects you from naive injections:


Yeah... this example code is bad. Not to mention that CGI is slow, problematic, and chock full of potential security issues. At the very least, spawning a process per request is a DOS attack waiting to happen, even if the code were immaculate.

Classic CGI is not the best performing interface, yes. But there's a big difference in launching a complete interpreter for every request, and running a small purpose-built native program. And remember that people did manage the former 20 years ago, sites like Slashdot were running CGI Perl scripts back then.

I'm not sure about the "chock full of potential security issues". You have to be careful with trusting environment variables as the Bash guys learned, but I don't know what else there is that is specific to CGI.

Forking a process per request is expensive, interpreter or not.

Slashdot used apache mod_perl back then. It never forked a process per request.

Slashdot started in 1997, the first release of mod_perl was on 12.03.1998. They certainly used cgi at first, just check the url here: https://web.archive.org/web/19980113191337/http://slashdot.o... - it says cgi right there.

Edit: Seems I was wrong about the date, it was actually 28-Jul-1997[1], nevertheless slashdot was only launched two months later, and as the link above witnesses didn't seem to have used it at first.

[1]: https://web.archive.org/web/19971210053529/http://perl.apach...

CGI was commonly used by everybody and anybody in those years. I recall Slashdot having some CGI pages, not everything but forms processing.

Then I have good news for you !


Also: DOS attacks against capacity sound positively benign compared to what they translate to on cloud : DOS on your credit card.

What is lambda?

> In this article, I’ll explain how you can use C++ to develop a website and some concrete reasons why you might consider doing so.

I dont find any reasons at all. That article ist just a clickbait nonsens.

"Building a Website with C++" "Is This Even Possible?"

We can just "flag" articles like this one.

CTemplate is a not-unreasonable option for C++ as well.

I run https://byuu.org using C++. Not just for page generation, but also for the server itself. It's all a single package, so no CGI is involved. Although I do use nginx as an HTTP->HTTPS proxy because TLS is scary. It's handled being linked on the front page of a few major sites with no issues.

In my case, I just prefer coding in that language over PHP et al. It's on a $2.50/mo VPS and I can spawn a new instance in five minutes if need be. Every memory access (for strings, vectors, etc) go through containers with bounds checking. The server/webapp itself runs as its own unprivileged user. If the server crashes, it'll stay offline and give me a core dump, which should let me find and fix the bug in my library.

The code's open, too: https://gitlab.com/higan/higan/blob/master/nall/http/server....

It's certainly not 100% perfect security, but what really is? Between Heartbleed, Meltdown, Spectre, weekly Wordpress exploits, etc ... I don't think the risk is particularly higher.

(aside: the forum runs on PHP on another VPS instance; separation of security concerns.)

Oh hey, you are still using Vultr? How have they been? I'm pretty sure I'm the one who suggested it some years ago on the forum and have wondered ever since if the at least then-unproven VPS company ended up being reliable. It looks like their prices have stayed competitive at least!

> Oh hey, you are still using Vultr? How have they been?

Pretty great. Infinitely better than anyone else I've ever used (especially InMotion Hosting that corrupted my SQL database, and misconfigured Apache to return my PHP source code to every visitor.) Not perfect, but very reliable uptimes.

If I had to nitpick:

The New Jersey instance lost the ability to reach it over IPv6. Their support staff wanted root access to my box to take a look. Nice that they were willing to do that, but I just moved to Chicago instead. IPv6 with the exact same configuration works fine there.

Their two-factor authentication does not allow SMS as a backup option. I don't like printing out codes.

Like everyone else, their bandwidth scaling is really poor. You have to scale up your entire server, even if you really don't need the CPU, memory or disk space. The price increases quadratitically while the bandwidth increases linearly.

You have to e-mail them your driver's license or something to enable SMTP. I think their fine print says they'll fine you $250 for every spam mail you send or something scary like that.

>You have to e-mail them your driver's license or something to enable SMTP. I think their fine print says they'll fine you $250 for every spam mail you send or something scary like that.

...Wow. The other stuff is par for the course really, but that sounds, a bit insane.

On the other hand, I assume (hope?) they just mean port 25 stuff, not encrypted SMTP...

I’m using vultr now and I vastly prefer it over Linode (I’ve yet to fully try DO).

It’s super simple UI to start an instance with a basic script (like update distro and developer tools etc). Lastly, you can pass in your pub keys and just ssh directly without doing it yourself the moment you log in for the first time.

All in all highly recommend it!

I will have to try Vultr again. My last experience was good, but regrettably I still use DO and AWS for everything.

Remarking on that, Digital Ocean is nothing special, but they have added some nice features in the past year or two. I like that their control panel supports multiple teams with permissions, I like that it has a nice tag-based firewall, the DNS service works fine, and it has an S3 clone called Spaces which is pretty handy. I believe they also announced recently that private networking would be isolated per-team instead of being the entire data center, another networking improvement that most low-end VPSes do not provide.

All in all, if you just need a low end VPS, I would say there's no fault in going with something like Vultr, but Digital Ocean adds a few extra features that might be more useful if you're developing a medium-complexity system. Of course though, at that point, you probably want to at least consider Google Cloud Platform, a reasonably cost-effective host with very rich features. (And AWS, but my feelings for AWS have shrunk in recent times after having better experiences with GCP consistently at my day job.)

Friendly note: they modify the stock install to enable root SSH login via password. I'd strongly recommend disabling that. Go to RSA key login as user only.

In an absolute emergency, their GUI portal will let you log in as root via password.

I too like to dabble in masochism

I also write my own cryptography implementations: https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur...

It's fun. We learn and better ourselves by making mistakes. My idols are the folks breaking through the security of the Switch et al. They had to learn somewhere: by doing things everyone else told them not to.

Don't worry, I would never use this stuff in production at a company.

As someone who's been helping lead the charge on Switch hacking, you're one of my idols, haha. Come join us! You would fit in well.

I'm in the early stages of a FaaS platform that uses CGI for the functions. As such, I have been collecting articles about general CGI development, and have them listed in my docs. If anyone is interested in writing large scale CGI apps (CGI is popping up a lot around here lately), these are some good resources: https://bigcgi.com/docs

Isn't cgi slow ? Don't you need something like fast-cgi (which lambda does I think) ?

CGI is slow because of the spin up time for individual processes for each request. FastCGI is fast because they run as one long running process that handles multiple requests.

While plain CGI is a slower, the advantage is that you don't have long running and potentially idle processes for low traffic periods, and process isolation is a little security boost.

I chose to have a slightly slower startup time, which hopefully remain constant in a load balanced cluster, to gain the advantages above.

Also the spinup time is considerably larger problem for various interpreters and virtual machines than for native code binary.

I would even expect that you can write non-trivial CGI application whose startup time is smaller than the additional overhead from parsing of the FastCGI protocol.

Pion[0] is a fairly robust and well-written HTTP server implementation in C++. You can spin up a server very quickly and reverse proxy through Apache or Nginx. Microsoft has a cross-platform offering of some sort in the works using C++11, now I don’t remember the name but I think Herb Sutter has a write-up in it from a couple years ago. It’s definitely possible to write modern web applications in C++, I feel like the cgi route is pretty old school.

[0] https://github.com/splunk/pion

> Microsoft has a cross-platform offering of some sort in the works using C++11

Casablanca, but I'm not sure how active is the project nowadays.

It's called the C++ REST SDK (https://github.com/Microsoft/cpprestsdk) now and is fairly active. I've used it client-side and I've really enjoyed it.

I wrote a c++/Qt web framework as a hobby.


Reminds me of the BCHS-Stack: BSD, C, httpd, SQLite.


I am still unsure if its satire or not.

Using CGI is silly and slow, for all but the simplest, stateless servers. If one wishes to avoid the overhead of learning a new framework, at least FastCGI should be considered. A relevant (but dated) discussion about web frameworks in C++ can be found in [1].

I am personally a big fan of CROW [2] and have used it many times in the past.

[1] https://softwareengineering.stackexchange.com/questions/5362... [2] https://github.com/ipkn/crow/blob/master/README.md

CGI isn't slow -- starting interpreters is slow. Starting Python or Ruby can easily be 1000x more expensive than starting a process in C, which takes MICROSECONDS, not hundreds of milliseconds.

See this 7 year old message by Richard Hipp (of sqlite):



This server takes over a quarter million requests per day, 10GB of traffic/day, and it does so using less than 3% of of the CPU on a virtual machine that is a 1/20th slice of a real server.

People just throw around qualifier attacks these days without thinking about the reality of modern processing power and what is really overoptimization. Just because CGI is slow-er- does not make it slow. So many hours are wasted on overoptimization, myself guilty of it - simply because of OCD type tendencies. I hope when I am finally on my deathbed I am not picky about the color of the sheets...

+1, FastCGI is the way to go for web services in C/C++: not only because cause of avoiding to spawn a process for each request, but because of having web services state in memory. Also, for avoiding heap fragmentation in long lived processes I recommend avoiding the STL library, and avoid using C++ strings, too.

I was expecting something like Wt (https://www.webtoolkit.eu/wt)

I would suggest/recommend this as well.

I had good experience with WT too.

If you want to use something like that for web, then use http://websocketd.com. There's no need to generate html on the server, unless you really don't want to touch JS at all.

Interested parties desiring production quality security and significanlty better performance than CGI, check out the C++11 library Restbed https://github.com/corvusoft/restbed Restbed replaces Apache, or put another way puts the web server inside your application, so your C++ app is its own server. It is easy to create REST APIs with executable as small as 100K, and that is all you need - no Apache or Nginx other web server needed. I have created a fairly sophisticated facial recognition REST API that host itself, only occupies 500K and can run circles around pretty much anything - while running on a $99 Intel Compute Stick. I've created web sites and servers and web APIs in a most of the fashionable web best practices, and I gotta say Restbed blows everything away.

Looks great but it's AGPL unless you buy a license.

Sometimes, software is worth paying for...

> In this article, I’ll explain how you can use C++ to develop a website and some concrete reasons why you might consider doing so.

I only saw one reason: performance. Did I miss some? Do people have other good use cases that justify paying the dev cost of using C++ for a web server? I'd guess with caching and a decent backend, it would be fairly hard to demonstrate a true need for performance that requires C++, but I'm sure there are a few demanding applications out there that need it.

Since a web page's throughput is usually network bottlenecked and not CPU bound, I'm curious (just for fun) what the max possible performance benefit of going C++ is, especially behind a CGI interface?

There's probably a small latency benefit at all times, and I'd guess there's a throughput benefit that is only visible if you're doing more than a few thousand requests per second..?

You missed IoT.

Preferably one would use some kind of network protocol with a native management console, but nowadays it is fashionable to have a mini webserver exposing a Web UI instead.

> You missed IoT.

I did? I just read the article again, and I don't see any mention of IOT or small or embedded devices aside from Docker, can you point me to what you saw? The article is assuming Apache is running...

I was replying to your question, which I should have quoted.

> Do people have other good use cases that justify paying the dev cost of using C++ for a web server?

Most router admin panels are probably written in C++

> Most router admin panels are probably written in C++

What makes you say that? The modern routers I've used all run a full embedded Linux like BusyBox, and they have no need for compiled high performance panels. It'd be more expensive and less portable to write the admin panel in C++, and I can't really think of any strong benefits that would make it worth using C++. I would have assumed they run a scripting language. But I'm checking some of the OS projects now instead of assuming.

Poking around, I see that Tomato is a busybox distribution, all the Linux tools including httpd are C (not C++), and the admin panal pages are .asp (written in VBScript).

DD-wrt appears to have PHP admin panels.

Looks like Asuswrt-Merlin uses .asp.

M0n0wall is all php.

Let me know if you find one with admin panels in C++, I'm interested.

Many are written in shell, terrifyingly, usually running as root.

A large existing C++ code base is one good reason. It’s possible to write wrappers for most of the more web-friendly languages but they are a pain to debug and maintain for any complex API. So if you need a relatively lightweight web front-end for a complex C++ backend something like this may be a good choice. I still wouldn’t go the cgi route, or use makefiles for that matter.

Wouldn't this have very similar performance characteristics to something like serverless functions on Amazon/Google cloud ? (assuming using same language)

I doubt the performance of a c++ web site would be better than c#/java or some other compiled languages for most non-trivial web sites. Once things like jits come into play, and you see large projects (1million+ loc) the performance advantage of c++ often disappears or it becomes less performant for things like web sites. Most companies do not have the time nor ability to do all those optimizations that theoretically exist that would make c++ more performant.

This isn't even counting the dev time difference

> c++ web site would be

No "would" about it C++ web sites are real and have been around for a long time. I'm thinking of sites running on Windows using "ISAPI".

Is their performance demonstrably better than other sites? Parent wasn't saying that c++ sites don't exist, just speculating that it doesn't necessarily make the site clearly faster to browse. I'd speculate the same, but would appreciate if there's hard data around to educate me, I'm genuinely curious what the benefits of going c++ are.

The performance would be notable. However, hardware is cheap these days.

> The performance would be notable.

Can you quantify & explain what you mean by notable? I've written a lot of C++ and also a lot of scripted web services like node.js and flask (python). For most normal websites, I doubt that you could make significant and noticeable performance improvements to a decent scripted backend by switching to c++, from the user's point of view. A latency savings of a millisecond or two across the board I could buy, but making it obviously faster to a user, I'm skeptical, unless the site has non-traditional high performance requirements.

What exactly is the "performance" you're talking about? How you define it?

> What exactly is the "performance" you're talking about? How do you define it?

You can see that that was precisely my question, right? Did you mean to reply to the parent comment? The article says the reason to use C++ over rails or node or another scripting language is "performance", the parent comment to mine said that the performance difference would be "notable". I'm asking exactly what you're asking -- what is performance, what is notable?

On top of that, I did define performance loosely in my comment -- as something that is noticeably faster to the user. If a user running Chrome can feel the difference on a site, and the only difference is the language it was written in, then I could buy that C++ gives better "performance". I suspect it's rather difficult to write a custom C++ web server and make it load or run any faster, from the point of view of the person on the other end, than a generic rails/flask/nodejs web site, for most sites.

> as something that is noticeably faster to the user

you know, there might be MORE THAN ONE user

so if server is done in, say, python, then user #11 will get slowdown. With C++, slowdown might start with user #50 (or 100, or ...)

Thanks. Yes. I said this very thing in my top comment. It takes a lot of users (many more than 10!) in any modern web server framework to get noticeable slowdowns, unless you've done something horribly wrong. So the question on the table -- still -- is what web applications might actually require a C++ web server, in practice?

C++ advocates often talk about the performance gains. The problem with that is that what C++ buys you is not better performance or even predictable performance, but repeatable performance, which is not that useful for anything not hard-realtime.

For typical large OO codebase some kind of tracing GC is almost always better than various reference counting and tracking schemes. For the unpredictability the problem has to do with the fact that even simplest C++ statement might cause the compiler to generate several kilobytes of inlined code.

C++ only has repeatable performance if used in certain ways.

> various reference counting and tracking schemes.

Reference counting doesn't always have repeatable performance.

Maybe for a program image started from scratch on exactly the same non-real-time input. But then almost anything has repeatable performance for that, including ordinary mark-and-sweep garbage collection.

My point was that only reason to use C++ is when you want repeatable performance which implies that you will not do things that are against this goal (and in fact C++ makes various tricks to achieve this goal trivial, eg. per-timestep heaps)

My other point was that for anything other you do not want to use C++.

Edit: and also "when used in certain ways" is exactly the problem with C++ I tried to point out. The language and it's interactions with real implementations is simply too complex for any kind of useful analysis.

Some other libraries I have seen for http protocol based applications:

https://github.com/Qihoo360/evpp - network library for developing high performance network services in TCP/UDP/HTTP protocols

https://github.com/rep-movsd/see-phit - C++ HTML template engine that uses compile time HTML parsing

https://github.com/boostorg/beast - HTTP and WebSocket built on Boost.Asio in C++11

https://github.com/emweb/wt - Wt, C++ Web Toolkit

Personally, I've used: https://github.com/civetweb/civetweb

(for implementing an RFC 3161 (crypto timestamp) service.

It's a fork of https://github.com/cesanta/mongoose

(The Civetweb fork exists due to Mongoose license switch from MIT to GPLv2)

Bevor I'd use C++ I'd take a hard look at Go, figure out whether I really need C++ performance, or whether Go is just good enough.

Go is rather performant and in contrast to C++ memory safe.

If you say that C++ is not memory safe you really don't know the modern C++. Of course you can use only `void *` everywhere... but you can also write your software in a totally different way. My C++ code has no pointers, just objects, which are automatically destroyed when I want to. The nice feature is that I know when the destructor is called, so the object will clear itself in a very nice way.

It's futile battle though to achieve both performance and safety in C++: as an example, safety requires avoiding moves, using reference counting, while achieving performance means avoiding copies and passing occasional references around, among other things. That's why advertising C++ solution as fast does not work well with "but C++ can be safe too!".

Moves can be safe, and copies can be dangerous.

C++ is a language that can be used like a sawed-off shotgun propped against a developer's foot, and with a hair trigger. Granted, it does not _have_ to be used this way, but it can be.

A good developer can be "safe by default" and can use profile-directed optimization to speed up areas that are performance critical. A great developer can build proofs that such performance improvements maintain safety guarantees. For the average developer, following modern C++ development practices creates code on par with other languages in terms of both safety and performance.

For most languages, a lot can be done in terms of optimization, profiling, and security. Even in higher-level languages, an FFI is available to rewrite critical portions of code in a lower level language for performance improvements. Careful attention to detail can provide critical performance improvements in any language without compromising on safety. Getting there requires model checking or formal methods, but that is also becoming more of a part of modern development practices.

The problem is that many developers don't care, they just want to do something that works and move on.

This is not specific to C++, but it is worse in C and C++ given the nature of these languages.

It also doesn't help that management even cares less about QA than those devs.

Not sure I necessarily agree with all your examples, but yes, this trade-off between safety and performance does exist in C++. It is particularily acute whenever you're forced to work with third party libraries that don't agree on a single approach to memory management.

Rust is essentially a bet on the impossibility of working around that trade-off in C++. And they are right, it is impossible to close that gap completely. C++ simply doesn't have the language features to enforce all necessary ownership rules without a performance penalty.

But I see trouble on the horizon for Rust, because that gap is quickly shrinking to its formally irreducible minimum as more C++ libraries are adopting a "modern" style. What's left of that gap may be too small to fit an entire new programming language built around fixing this single issue.

Rust is more than just safety though. We had a huge community discussion last year: https://brson.github.io/fireflowers/

I know it's more than that. But what you can't do, in my opinion, is love Rust for its other modern features and merely tolerate the new approach to memory management.

Memory management in Rust is so dominant in terms of syntax and in terms of restrictions imposed on common idioms that it must be either embraced or rejected wholeheartedly.

This is just my personal opinion obviously, not any sort of truth or prediction.

Two main components of Rust's approach to memory management are i) the imposing/exploiting of scope lifetimes on objects and references, and ii) the restriction that a mutable reference may not co-exist with any other references (to the same object).

I suggest that with C++ there is kind of the option of embracing the former, without so much of the latter, to achieve a performance-safety combination that is closer to Rust's than current "modern C++" practices. That's sort of the premise of the SaferCPlusPlus library [1]. If you're a C++ programmer, the barrier to adoption is low. Though without a "borrow checker" or something equivalent, you wouldn't be able to match Rust's performance-safety combination in all cases.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

edit: edited the link

Yeah, I totally hear you. I shared that opinion too, but, surprisingly enough, it seems to some degree that that's in the minority. Or at least, there's a pretty significant number of people who do "love Ruts for its other modern features and merely tolerate the new approach to memory management."

I feel that way myself now, but figured that I was just too close to have a mainstream opinion about it :)

That's good to know. Perhaps I just need more practice then.

You're just wasting your energy man. People still think we live in the C++98 era.

>Go is rather performant

Go is slower than C++.

What's with all the weird spam at the bottom of these comments? Someone seriously loves rust.

Cutelyst is a nice C++ web server with a much better api imho: https://cutelyst.org/

I wrote my blog site in C. Runs as CGI and works just as fast as other tech stacks, say PHP.

C has very low startup time compare to say Java. And process fork-exec isn't as heavy weight under Linux as in Windows.

Java can be C like when compiled into native code, OpenJDK isn't the only JVM around.

You can do this with libboost with this https://github.com/ipkn/crow

> I know it sounds strange, and perhaps even an exercise in novel futility, but it isn’t.

Oh come on, C++ is a systems programming language and certainly can handle this, so “futility” seems over the top. Hell, you can write cgi handlers in assembly.

Around 94 I wrote Cygnus’ web interface (and then cron job too) to our big system in sh. Sure, I wouldn’t make the same choice today, but it’s hardly absurd.

Am I right in thinking the main reason not to do this is memory safety (as demonstrated by Cloudbleed)?

That's part of what I'd argue is the main argument against: not reinventing the wheel. The only argument for is experimenting. These are all toy examples. I'd argue that through CGI it won't even be more performant than opcode cached interpreted languages.

yes you are! Just imagine websites leaking other people's credentials to hackers because someone was using an undefined language haha!!

This brings me back... I was doing this exact sort of stuff at the turn of the century, although admittedly in C - not C++ - and using/linking to the Delphi CGI library.

CGI in 2018 seems a bit passé...

Actually, this new hip function-as-a-service thing feels a lot like CGI/inetd…

well, at least in terms of not keeping the server process up all the time, only when it's used.

To combine "only running when necessary" and "not restarting for every request when there's a lot of requests", I made a thing: https://github.com/myfreeweb/soad — little wrapper listens on a socket, spawns your server with the socket passed in, terminates the server when there were no new connections in a while, rinse, repeat.

You can check inetd which does exactly that and comes preinstalled and pre activated with Linux installations. Or at lest it was common once upon a time. Don't know if it still is.


UTF-8 handling is a big reason I prefer a language like Python 3 or Go over C++ for the web.

Building parts of a web site backend in C++, maybe. Anything else with the current state of technology seems futile for a production environment.

tl;dr: CGI.

You can build a website with any language… I mean, sometimes it’s nice to go back to the basics, but aren’t there better packages and frameworks written in C++ to handle the job?

Just use rust man :| why do you want to bring all your security vulnerabilities and undefined behaviors to web?

Why do people think the C++ of today is the same as the C++ of 1998? Today we have concepts such as RAII to clean up our objects when they go out of scope. We have references which are essentially safe pointers to an extent (see dangling references). References have always existed, but people insist on using raw pointers still. Finally, for those use cases where heap allocated memory is absolutely necessary, we have smart pointers which clean up the memory they own when the smart pointer object goes out of scope (an application of RAII). Other unsafe practices carried over from C such as void * type erasure are being replaced with type-safe objects (see std::any for C++17, boost::any for pre-C++17).

There's still plenty of ways to shoot yourself in the foot if you are "not careful" with the modern C++ code you write. See for example http://foonathan.net/blog/2017/03/22/string_view-temporary.h...

Modern C++ has a lot of great stuff to help, but the sense of safety you get when you use Rust is something else entirely.

Because Rust lets you hire noobs that don't know what they're doing and contains their damage. C++ is fine if you know what you're doing. It's ridiculous to claim that memory safety is helped by the use of references.

I can’t speak for everyone but I think of the C++ of today as being dangerously close to the C++ of 1998 because there is so much 1998 C++ code still being linked into most C++ projects. C++17 is incredibly powerful but it’s also hard to wield correctly and most people don’t have those skills yet (and almost none did while writing that 1998-originated library you eventually find yourself need to use). It’s not just the language that matters, it’s how that language gets used and by whom.

Might want to integrate an existing C++ code base into a server without developing an API or IPC in between the two. The security issues would be similar in either case and this would be much quicker to develop.

> Might want to integrate an existing C++ code base into a server without developing an API or IPC in between the two.

Or perhaps you might want to use a belt sander to refinish your table without removing the tablecloth from the table first. Not all the things one “might want to do” are good ideas, even if there’s a wikihow on best ways to do them.

C++ is a great language but it’s a very hard language to wield correctly. The odds there is an exploitable buffer overflow or injection attack buried deep in some part of the code are simply too high compared to memory managed languages with standard libraries designed from the ground up for web-facing applications.

this would be much quicker to develop.

There is almost literally no chance that this is the case. The amount of pointless boilerplate code that you'd have to write would be many, many, many times in excess of a thin API layer.

How do you suggest writing a thin API layer to expose an interactive real-time stream consumed over WebSocket?

Rust would be equally unsuitable to this task. Web development in C++ or Rust? Why?

There may be some advantages to writing a middle tier application server in either of these languages, but using a system language to manage a web front-end is effectively like using a hatchet to shave. Sure, the hatchet is faster at cutting wood than a safety razor, and if one is careful, it could be used to remove stubble, but chances are that one is not clearly thinking about the problem at hand to suggest such a tool.

As replied in another thread, IoT.

There aren't many options when you just have a few hundred KB.

Having a better and more expressive type system.

Its always interesting to see C++ but as someone else mentioned I expected to see Wt. If I want nearest to C++ speeds I rather go with D (using vibe.d) or Rust. C++ isn't my area of expertise though but those two other languages are years more approachable for me personally. Not saying I could never do C++ though. I know OkCupid is C++ using Wt iirc. I wish they'd give D a try or Rust to see how much more productive they become.

Why would you assume that D or Rust would be make developers more productive? If the developer already knows C++, then switching to D or Rust would make the developer significantly less productive over six months to a year, after which, the developer would likely be just as productive as he/she was when writing C++.

Languages are not panaceas. Rust and D are both hard languages, as is C++. Selecting one of these only makes sense if the application warrants it. Each have advantages and disadvantages. I don't really think any of them are suited to web development, but claiming that D or Rust would be a more productive web development language than C++ seems equally silly to seriously considering C++ as a web development language.

> Why would you assume that D or Rust would be make developers more productive? If the developer already knows C++, then switching to D

Because D is very obviously C++ but better. Rust isn't, though. But D, down to the very name, has lots of things that appeal to C++ users. It has advanced metaprogramming, is multiparadigm, it compiles down to machine code, and has very similar syntax to C++.

D has had other influences, but it is written by C++ compiler writers who think they can do better than C++. I say this as someone raised on C++ and who is now trying D. It is a very natural progression to make, if you're inclined to try something new.

Furthermore, Vibe.d is kind of a burgeoning "killer app" for D. D's package manager, for example, was originally made for Vibe.d. This isn't the only way in which Vibe.d has influenced D development. Vibe.d is one of the most popular D libraries. It's the only D library I know that has its own published book,


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact