You could speculatively run stuff on the client and run it on the server, to achieve a speedup.
But there are many more usecases. For example, decoding and encoding of messages between client and server. Hashing stuff. The list is endless. I think that once you have experienced programming in the same language on client and server, you simply don't want to go back to the "split brain" kind of programming.
>decoding and encoding of messages between client and server
You can generate the message types and communication functions from a shared schema, e.g. gRPC/GraphQL/Swagger and many others, which will also lead to looser coupling and hopefully proper API version/change management.
I feel like unless you're using JavaScript/TypeScript on the server, most of the benefits of a shared language and framework will be negated by the lack of easy access to the web frontend ecosystem. (This may not be true for isolated shared modules that are oblivious to the UI, e.g. validation logic, where the surface area between it and the rest of the client code is maybe one or two functions.)
It's not all clear that a garbage collector isn't an advantage in actual workloads. Web apps tend to create a lot of short lived objects, and contrary to popular assumption malloc and free are not free.
The alternative of gc is not malloc and free. It's custom memory management, i.e. the code that decides when to execute malloc and when to execute free. Even a gc will ultimately call the equivalent of malloc or free. The difference is gc needs to do it generic enough that it works for all possible programs; whereas a programmer needs to do it in a way it works for this particular program.
That's a little disingenuous. h2o isn't really a framework as much as it is a server that can be extended as an application (Similar to CherryPy vs Flask/Django). There aren't really any good C web frameworks, and any web applications built in C are very likely to be bespoke code utilizing some HTTP library (libhttp, h2o, kore, etc).
Actix is a framework, built in Rust and non-GC'd, that performs significantly better than any of the Go frameworks. So GC does seem to have some effect.
That being said, I agree the GC is unlikely to be the problem for D's performance (in this case).
> how could it be changed to get better performance?
Mostly, pay attention and profile to get better performance.
---
For example, if you look at rust, you see that the top(actix) and the middle frameworks have some big distance. The former autor of actix care to get good result, others are just in the step of "have something working nicely"
Not sure why you are getting downvoted here. Your question is very valid.
As far as the Techempower results go, I'm pretty sure it is not a GC issue. It could be the postgres implementation issue. Someone has to work with upstream to tune and fix the issues.
Contributing to such benchmarks require time and effort. A small community can do only so much in their free time.
Even though such benchmarks are good marketing, the D community is not interested in participating such benchmarks (although I'm quoting one post from the D forum, the trend is same).
It's not D which us performing poorly here, it's vibed.
Rather look at the benchmark game if you want to compare numbers. Older versions, which did include the better languages
20 comments
[ 0.22 ms ] story [ 57.2 ms ] threadBut there are many more usecases. For example, decoding and encoding of messages between client and server. Hashing stuff. The list is endless. I think that once you have experienced programming in the same language on client and server, you simply don't want to go back to the "split brain" kind of programming.
You can generate the message types and communication functions from a shared schema, e.g. gRPC/GraphQL/Swagger and many others, which will also lead to looser coupling and hopefully proper API version/change management.
I feel like unless you're using JavaScript/TypeScript on the server, most of the benefits of a shared language and framework will be negated by the lack of easy access to the web frontend ecosystem. (This may not be true for isolated shared modules that are oblivious to the UI, e.g. validation logic, where the surface area between it and the rest of the client code is maybe one or two functions.)
https://www.techempower.com/benchmarks/
I was expecting Rust or C level of performance for D. Instead, D performs on the same level as Ruby and Python.
GC, untraced references, reference counting, stack and global memory segment allocations, OS system buffers.
The programmer also needs to do it in a way that works for a particular program instead of doing new everywhere.
The advantage being that having a GC around is much more productive for the workflows that don't need such hand tuning.
Actix is a framework, built in Rust and non-GC'd, that performs significantly better than any of the Go frameworks. So GC does seem to have some effect.
That being said, I agree the GC is unlikely to be the problem for D's performance (in this case).
https://attractivechaos.github.io/plb/
https://github.com/kostya/benchmarks
NoGC comparison
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
For native code, D has roughly C++ levels of performance with much simpler/nicer code.
What about the framework leads to this, and how could it be changed to get better performance?
Mostly, pay attention and profile to get better performance.
---
For example, if you look at rust, you see that the top(actix) and the middle frameworks have some big distance. The former autor of actix care to get good result, others are just in the step of "have something working nicely"
As far as the Techempower results go, I'm pretty sure it is not a GC issue. It could be the postgres implementation issue. Someone has to work with upstream to tune and fix the issues.
Contributing to such benchmarks require time and effort. A small community can do only so much in their free time.
Even though such benchmarks are good marketing, the D community is not interested in participating such benchmarks (although I'm quoting one post from the D forum, the trend is same).
https://forum.dlang.org/post/mailman.2866.1587920400.31109.d...