3 ms·
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 languag
by matt42 11y ago
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.
- jstimpfle 11y ago> 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.
- erichocean 11y ago> 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 https://github.com/nodejs/http-parser On the parser side, that's about as widely used/polished as you could hope to see.
- srean 11y agoHey 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.
- matt42 11y agoThanks 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?
- srean 11y agoSorry, 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