Silicon: C++14 web framework | Hacker News Reader

Silicon: C++14 web framework

siliconframework.org

29 pointsapi14 comments

I've seen many web frameworks where the design is centered around URL+Method dispatching (routing). Many frameworks also play overly clever type system tricks in the dispatching code, just so the intro looks really short and sweet.

Having developed two or three nontrivial web applications myself, I don't think routing is a substantial part of web application design. A framework which focuses on routing will probably be suitable mostly for small one-off applications. This approach has in fact lead to significant boilerplate in my routing endpoints. The boilerplate would probably not have amassed so naturally if I had first implemented the actual functionality as data or streaming interfaces.

If the functionality is finished, a custom integration with HTTP should not be more painful then integrating with a framework. Furthermore, the implementation can be accessed with an interface other than HTTP (testing, internal scripts...)

The hello world example takes 2.5s to compile on a 2.6GHz i7 + SSD. Adding 9 new routes bumps the compile time to 4.5s. 30 routes = 10s compile time. Seems like this would get out of hand quickly for any moderately complex project.

Other than having to deal with complex templates, I personally wouldn't choose this for web development because the advantages of the strongly typed routing are dwarfed by the dangers of writing C++, especially when alternatives like Rust exist today if you really need the low level performance advantages.

Indeed, compile time is a currently a problem for API with a large number of routes. It'll probably get better with the C++17 Module TS.

What do you mean by the dangers of writing C++?

I mean the memory safety pitfalls of C and C++, mostly.

You can write Silicon APIs without the use of any pointer, which save you from most of the segv you can get with these languages.

That's how the operator overloading abuse looks like.

Author here. Questions are welcome.

1. Why C++?

2. Why the complex/unfamiliar DSL?

3. The Boost dependency (through iod) is not documented on the website. Might want to mention that.

Here are my answers on the reddit discussion:

1. Why C++?

There is advantages (and disavantages) of using C++. There is situations where loosely typed languages may be better but there is certainly lots of case where C++ has many advantages. The problem is that today, it is pretty hard to write web APIs in C++, this is why is not widely used, despite its performances.

Hopefully, the standard finalized C++14 and I jumped on this opportunity to take advantage of those new features (lambda, auto, variadic templates,...) to write a zero-cost and robust web framework. Zero-cost because most of the framework stack goes away at compile time, and robust because its static paradigm enables the compile to detect most of the errors.

2. Why the complex/unfamiliar DSL?

I found that in some case it really simplify the code and as long as the new semantics is coherent, the user can get used to it quickly. I could have chosen a non DSL approach, but it would have been more verbose, harder to digest, and less similar to a real URL:

DSL: GET / _hello / _world / _id[int()]

Non DSL: GET.path(_hello).path(_world).url_param(_id, int())

3. The Boost dependency (through iod) is not documented on the website. Might want to mention that.

Thanks for noticing, I'll mention it.

> The problem is that today, it is pretty hard to write web APIs in C++

What I think is needed is mainly a library for parsing and encoding of HTTP requests and responses (I don't know what there is for C/C++). But in most cases the CGI interface is good enough.

I think the model where some framework contains the main loop which drives the application is deeply flawed because the implementation will strongly depend on the framework.

The hardest part of creating an API is the design. This won't just go away with yet another framework.

> What I think is needed is mainly a library for parsing and encoding of HTTP requests and responses (I don't know what there is for C/C++)

https://github.com/nodejs/http-parser

On the parser side, that's about as widely used/polished as you could hope to see.

Hey Matt, appreciate that you open sourced this. I always learn something by reading such code that other people have written. This one is an interesting problem to tackle in C++ for the reasons you mentioned.

For the same reasons I feel D seems a very nice fit here. You may enjoy digging into that. Coming from C++ context switch would be a minimum. You will enjoy nicer way to metaprogram and enforce compile time properties, you can lean on a garbage collector should you need one, and whole lotta shorter compile times. DMD is the fastest among GDC and LDC but the generated code is not that fast. So in theory the best path is to develop using DMD and once the code settles out you can switch to better codegens. It doesn't quite work as well as it should because DMD and [G|L]DC are sometimes a few versions apart, but its still quite reasonable for medium sized repositories.

But again thanks for open sourcing your code, I look forward to digging into it.

Thanks Srean, lower compile time is definitely something Silicon would benefit a lot. I am wondering how much the c++17 module TS will help. I'll check the D language to see if we can implement a framework similar to silicon. I do not know anything about this language, do you think we can get a D web server running as fast as its C counterpart?

Sorry, hadn't seen this till now. Modules ought to help, kinda disappointed its a TS only.

Yes D can be just as performant and I am sure you will feel at home pretty quickly because its essentially C++ done right. C++ committee has been falling over themselves to get all the D features :) The site to go to for D is dlang.org. It runs on D. One library you surely would want to look at is vibe.d

Reply on news.ycombinator.com