> Anything other than C or Java really

Rust, C#, and Go also seem to fit the bill, according to these benchmarks. C# particularly has rocketed up since the last time I looked in depth at these. Pretty impressive work from the .NET Core folks, I'd say.

For Rust, I'm interested to see what the future holds once the community coalesces around an async IO interface. Additionally, when procedural macros stabilizes (for real), the possibilities for ergonomic frameworks in Rust become endless.

Rocket has been really interesting to work with, but it only works on nightly since it relies on experimental codegen/procedural macro features. Once procedural macros stabilizes, all the codegen can be ported to that. It doesn't support async IO yet, but that's because it's waiting for the community to coalesce before diving into it.

I think there's a future where Rust web frameworks are as expressive as Rails or Laravel but bring type safety and sound, zero cost abstractions to the table.

Lots of folks seem to be getting drawn to actix-web, which features quite a bit up the top of these benchmarks. I've not used it, but it works on stable, is fully async, and has been met with many good reviews!

Which according to their main developer is used in production at Microsoft.

> I think there's a future where Rust web frameworks are as expressive as Rails or Laravel but bring type safety and sound, zero cost abstractions to the table.

I'm really looking forward to this. The only thing I worry about is compile times. I hope they don't end up ruining an otherwise perfect solution!

Speaking of which, a few hours ago Futures were added to the standard library, so the next nightly will have them in. We're quite close to that standardization!

Just adding for clarity: this isn't async io, but the foundation trait for building promise/future combinators in Rust. Tokio, an async io library, is built around this trait.

Yes. It's the Future and executor stuff, but doesn't provide an executor. You'd do that via Tokio or whatever else.

Big news!

Plus one for c#, with compiler optimisations I was able to generate millions of sha256s a second, many more than my c++ version of the same code. Then I discovered CUDA, then I got bored and went onto something else.

I'm not sure how many companies use C, C++ for Web development. In my opinion C/C++ wont be good idea to use for most. It is about choosing the best ration b/w tool speed and developer speed(productivity).

There are very few companies which requires million per second request. For me Java, C#, Go, Node provide the best compromise b/w speed and productivity.

Vertx in Java is basically the fastest across all the benchmarks, putting it in the same speed/productivity bucket as node doesn’t make much sense...

I was talking about the compromise, if node is slower it provides better productivity.

Why would a experienced java dev be less productive than a node js one?

Tooling, typing, boilerplate and contrasting to the library that is npm.

Vertx is polyglot, you can use js and npm if you like, so in this respect vertx can be more productive as it allows you too use the tool that works best for your problem, be it npm, maven, gradle or language: java, javascript, kotlin, etc...

Most companies that sell embedded hardware managed remotely by Web interfaces.

Honest question: What sort of embedded hardware deals with millions of requests a second? I wouldn't have thought that kind of utility was the same domain as "embedded" (in the stricter sense of the term).

Granted you could expand the term to cover hardware load balancers and the sort, but those wouldn't really be running websites so much as routing and caching them. Aside from that, you have management interfaces for embedded devices but they're typically used infrequently and only by a small subset of users. Plus a surprising number of them are just written in PHP or Perl.

But maybe there is a whole industry out there I've overlooked? You've got me curious.

It is not millions of requests a second, rather what you can put into something with 512 KB or less while providing a minimal Web management interface.

For example,

https://www.hcc-embedded.com/embedded-systems-software-produ...

Ahh yes. I do have some familiarity with HCC - albeit limited to a hobby project rather than anything professional. It's interesting stuff but I'd argue that's a completely different target industry to the ones that would use any of the web frameworks in the discussed referenced benchmark. So not really on point to the question raised by the GP with regards to C vs the more rapid development frameworks like node.

Not that I'm trying to dismiss your point either because if I was given a choice between node and C, I might personally choose C just because of my own personal prejudices against Javascript. :D

I don't have actual experience with HCC, it was just one random example.

Embedded is one of my interests, so I do keep an eye on news about what is going on.

On my case I would rather try to bend my answer to be either C++ with embedded STL or Pascal, failing that C as well, in spite of my prejudices against it.

Hopefully they would at least allow C99. :)

I love Pascal (C++ less so but we all have our own personal preferences) however if you're targeting the web then you're definitely better off with C#, Java or Go* . You'd get similar language constructs while having a much richer ecosystem to develop in. Which was the point the GP was making with regards to development time verses request throughput. Only with the aforementioned you at least don't sacrifice that much in performance compared with node.

* I know Go gets a lot of hate because of its lack of generics and choice of error handling, but it's worth remembering that for web development you don't run into those particularly annoyances much.

Something that I learned after being part of a startup back when doing web servers in Tcl was cool (AOLServer and such), and Zope was hip, was that I never wanted to work again in software stacks that lacked a JIT or AOT compiler for production code.

I find it very frustrating that Scala, a language that is entirely capable of running just as fast as Java, is full of frameworks that are relatively slow compared to the java frameworks. It has to be some sort of fixation on reinventing everything from scratch in order to fit into some idealized idiomatic scala way (ignoring the fact that there are a million different versions of "idiomatic" in the scala community). Even the Play Framework, which used to be based on Netty and was pretty damn fast, ended up spending entire release cycles focused on migrating to an akka-based backend and they ended up with shittier performance and now they have to maintain two backends because nobody wants anything to do with their new akka backend.

Sometimes mutability and imperative code are okay, even in scala.

Do you have in mind these benchmarks?:

    play2-scala-slick-ne  60,588  14.3%
    play2-scala-slick     60,400  14.2%

("-ne" = netty, the other is Akka)

There's not that much difference? Or did the Netty version, get slower, because of refactorings done to support Akka?

Anyway I too feel frustrated that the Scala / Play Framework developers don't seem to focus so much on performance, but rather (it seems to me) on writing theoretically beautiful Scala code? I'd rather have something fast & simple like Vert.x, in Scala

Well, there's Vert.x + Scala, "only" 70 stars: https://github.com/vert-x3/vertx-lang-scala thugh. I wonder how Vert.x + Scala compares with Vert.x + Java, would have been really interesting to include in the benchmarks :- )

I suggested incl Vert.x & Scala in the benchmarks: https://groups.google.com/forum/?fromgroups=#!topic/framewor...