Hacker News Reader

Comment by byuu | Hacker News Reader

I've been building an HTTP/1.1 server in C++11. Along with a C++ wrapper around SQLite, I've been having a lot of fun putting some lightweight forum software together. I definitely enjoy the code structure and compile-time safety over PHP.

Using a threaded model with tiny stacks, and std::lock_guard for atomic operations.

The biggest downside is you have to run the same OS your server uses on your dev box (which is what I do); or you have to upload the source and compile the binaries on your server directly. (or have fun with cross-compilation, I guess.)

To answer the inevitable "why?" -- for fun and learning. Kind of cool to have a fully LAMPless website+forum in 50KB of code. Not planning to displace nginx and vBulletin at a Fortune 500 company or anything.

Still wishing I could do HTTPS without requiring a complex third-party library.

View on HN

Go would solve the problems you mentioned (cross compilation and HTTPS support), and would also offer first-level support to many web concepts and protocols that you need to implement from scratch in C++ as the ecosystem is not there. Of course if it's just for fun, then anything goes :)

I am so glad that my company chose to write the majority of our web oriented frameworks in Go. It's simple to the point of boring for most of this stuff.

I find this so much more pleasant to use than the alternatives. There's a portable distribution of it which you can put in your project and statically link.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

Just put HAProxy in front of your server. You'll want that anyway most likely.

The biggest downside is you have to run the same OS your server uses on your dev box

You should check out Docker.

Docker only helps with portability between Linux distributions, not operating systems.

You can't run it on Windows, Mac or the various BSDs without a VM, at which point you're running "the same OS your server uses".

That's not true; Docker runs great on OSX natively. You can't run the containers there, but the client itself is fine and largely abstracts away the whole "where am I building" issue.

Minor nitpick - Docker runs great on OS X, but it doesn't run natively, it runs on a minimal Linux VM - Boot2Docker.

I agree that the reality of the situation is that it's abstracted away enough that the distinction isn't really all that meaningful.

No, the docker program itself does indeed run natively on osx. You do not need to use boot2docker or any other VM.

You can't run any containers on osx, but docker itself runs fine as a client binary to docker running on a linux server. I use this configuration daily using a native osx docker binary on my workstation speaking TLS to a docker service running on a CoreOS server.

Yes and no.

I use OS X for my main machine, and can happily deploy something to a server running 'not OS X' and be confident that all libraries and dependencies are exactly the same in production as what I was using in development.

Sure Docker is running through a stripped down VM on the Mac, and so technically it's "the same OS my server uses", except it's abstracted away so that for all intents and purposes I'm using OS X for development (and email, browsing, and other things) and deploying hassle free to Linux.

Reply on news.ycombinator.com