Hacker News Reader

Comment by Negitivefrags | Hacker News Reader

You could make one hell of a good C++ web framework with this.

  http::controller mypage
  {
    //Browsing to http://server/mypage/test?some_str=blah&param=5 calls this
    http::response test( const std::string& some_str, const unsigned param )
    {
      return web::response{ 200, "You did awesome stuff" };
    }

    //This method can only be called with HTTP POST
    [[POST]] http::response save_some_data( const std::string& blah ) 
    {
      return 200;
    }
  };

  int main()
  {
    http::server server( "localhost", 80 );
    server.add_route( "mypage", std::make_unique< mypage >() );
    server.run();
  }

It's all the magic of a modern web framework but in a fast language.

Due to web assembly you can easily have your server and client side scripting be done in the same language, with the same libraries which is also huge bonus.

I honestly can't think of a better stack.

View on HN

https://rocket.rs/ is basically this, but in rust instead.

https://vibed.org/ is basically this, but in D instead

ASP.Net MVC is basically this, but much more mature and feature packed :) And C# is no slower than D.

> And C# is no slower than D.

I very much doubt that. Do you have anything to back up that statement?

Benchmarks are tricky and hard to find for dlang as its not that popular, but I have common sense to back that statement. Dlang garbage collector is really really slow for now [0], and C# has a very fast GC and overall is almost as fast as zero-overhead languages like Rust or C++ [1]. So, its reasonable that for anything that involves GC (we all can agree that web server does) D is not that fast as manual memory management languages yet.

[0] https://olshansky.me//gc/runtime/dlang/2017/06/14/inside-d-g...

[1] http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...

I have benchmarked D code against C,Rust and C++, most of the time D code is faster than Rust and C++ so I doubt it's on pair with C#.

Also in Vibed, Diet templates (~= Mustache templates) are compiled using this into binary classes.

The new WebConfig library looks promising too: https://github.com/WebFreak001/WebConfig

You can do exactly this with the Haskell "servant" framework. Works great. It's in fact even more powerful than this. Your routes are first class, so you can pass them around and generate type-safe links.

It also doesn't require any "meta" level programming, just plain Haskell. And Haskell is blazing fast, not far behind C++ (especially when using high level C++ APIs like std::string)

https://haskell-servant.github.io/

Proponents of C++ for some reason think that C++ is the only fast language while all others are slow interpreted scripting languages.

Only those that never used other languages besides C.

Or those, who - besides C++ - only used Python, Ruby and/or JavaScript. ;).

Yeah right. :)

My point was more about being closed minded to alternatives.

It's more that C++ is the only widely adopted fast language. Rust and D are the only real challengers there but D doesn't seem to have caught on and Rust's growth, while impressive, isn't up to widely-adopted language status yet.

Granted most things don't /need/ the raw throughput potential of C++, but if parts of your code really does need it then it tends to be easier to just make the whole thing in C++ than deal with bindings to other languages.

Sorry but can someone explain why C++ by itself can't be good enough for a web framework? OKCupid wrote one back in the day.

ALSO: Your example is much slower than the same server written in Node.js, haha. Because the language doesn't support evented programming. The language may be fast, but the paradigm of blocking while waiting for I/O is slow!

Ahem.

Back in 2001 I was working on what was at the time the fastest webserver in the world: Zeus. It was written in C++ and built around select(), which gave it effectively evented programming. One process per core. Primarily for serving static content, although there was a fastcgi interface and, god help you, IBM Websphere integration.

There were a few quirks to the codebase. No STL; instead our own containers and length-based string classes. There was also a "stringrange" type class, which referred to a range of a longer string. So it parsed in the entire HTTP header as an octet array, then created objects to refer to individual headers. Since the input header was immutable this worked beautifully. Considerable effort was put into avoiding unnecessary copies.

It also had at least a dozen target platforms; Linux, SunOS, IRIX, and architectures from ARM to Itanium. I'm not sure on how many of those we ever sold a license.

I remember that server! It's really cool stuff, and select() can definitely be used in C++. But there is no real evented ecosystem for mysql, pgsql, websockets, and all the other types of I/O unless it is all done through sockets. I think all languages can do an event loop, it's just a question of the ecosystem. Javascript is designed around async and Node.js was heavily promoting it from the beginning. So the default pattern is async. That's what I meant.

Yes, sure you can do the web server and even middleware as async, but there are many services (redis, memcached etc.) and having async modules for them all is the key.

CGI scripts used to be fairly popular back in the day, it was not uncommon to have C or C++ code facing the web directly.

The main problem is that web apps have a huge surface of attack, a huge part of any web application is handling untrusted user input. For this reason you're taking significant risks by using a memory-unsafe language. Also web services are rarely CPU-bound, so the added performance matters less.

> The main problem is that web apps have a huge surface of attack, a huge part of any web application is handling untrusted user input.

That's not actually true; not all web frameworks work by having pages that parse query params on every navigation. Callback based frameworks like Seaside let you write apps where form input is the only attack vector and messing with URL's will only make you lose your session. That pretty much removes the largest attack vector in most web apps.

Well you're just delegating the issue to the framework then, it doesn't really change what I said. If the framework is written in C++ it'll have to be written very carefully and thoroughly validated.

If the framework is written in a safer language then it's not much different than if you write a web application in, say, Django where you call native C and C++ modules. That's very common.

Sure, but that's why we use frameworks to begin with, to create such abstractions. My point was the main attack vector many web apps suffer from are merely due to frameworks that leave too much to the developer. Abstracting page to page linking, as Seaside does or as this very website's Arc framework does with callbacks kills that vector by changing the very nature of what links do.

> ALSO: Your example is much slower than the same server written in Node.js, haha. Because the language doesn't support evented programming.

Uhh, how do you think Node.js is implemented?

It's not about how the bytecods is compiled. It's about the paradigms the language encourages.

Look, even PHP has frameworks to do evented programming: Kraken, amphp, ReactPHP. But it lacks an ecosystem of modules that actually do things in an async way and work with the same framework.

It's the ecosystem of modules and the ethos that matters.

C++ has always supported callbacks and has libraries for promises [1] and event loops [2]. Co-routines (i.e., await) are coming soon.

[1]: https://msdn.microsoft.com/en-us/library/dd492427.aspx [2]: https://github.com/libuv/libuv

> ALSO: Your example is much slower than the same server written in Node.js, haha. Because the language doesn't support evented programming. The language may be fast, but the paradigm of blocking while waiting for I/O is slow!

there are plenty of event libraries for C++, many predating Node.js (which is written in C++ btw) by decades.

There is no reason why the op example can't be implemented on top of such a library.

Unless your was sarcasm, in which case Poe's law strikes again.

That may be true, but his example is not evented programming. Unless the function he is calling is badly named, I am pretty sure the style he was thinking about was about blocking the thread until I/O completed.

I can't know what the OP had in mind, but I don't see anything that would prevent the example to be fully asynchronous. http::repsonse could be the moral equivalent of a future or it could be running on top of a coroutine.

Microsoft also used to have one based on ATL, as IIS module.

You don't need event programming to be fast. A blocking paradigm is perfectly fine in any language or context that supports fibers.

And none of that snippet you are replying to even blocks, so... what?

https://www.youtube.com/watch?v=bzkRVzciAZg

More seriously Node.js has some pretty major performance problems, like the fact that it's single threaded. You'll make excellent use of one core, but that's about it. It looks great on I/O bound request/second benchmarks, but as soon as your code needs to do meaningful work it doesn't scale anymore. The solution to that is to spawn multiple node instances to make use of the actual machine resources, but now you're on your own and why did you bother with node.js then in the first place?

Reply on news.ycombinator.com