Hunt: A high-level D Programming Language Web framework | Hacker News Reader

Hunt: A high-level D Programming Language Web framework

github.com

47 pointschenzhekl20 comments

Why does D perform so poorly for web programming?

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.

Why would you expect rust or C? D has a garbage collector, a better comparison would be Java or Go

The best C framework in that benchmark performs roughly equal to the best Go framework. So I don't think that garbage collector matters that much.

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.

Many GC languages like D offer the tooling to decide where to allocate as well, it is not GC for everything.

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.

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).

GC doesn't matter here. Look at few other benchmarks:

https://attractivechaos.github.io/plb/

https://github.com/kostya/benchmarks

NoGC comparison

http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

It's just how the particular web framework is written?

For native code, D has roughly C++ levels of performance with much simpler/nicer code.

>It's just how the particular web framework is written?

What about the framework leads to this, and how could it be changed to get better performance?

> 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).

https://forum.dlang.org/post/mailman.2866.1587920400.31109.d...

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

Take a look at their source code. They just push hardcoded responses to the socket. That bench is pretty useless.

Does it compile to WASM so you can have the same code on client and server?

What would having symmetrical code accomplish?

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.

I think they are referring to running the same applications on client and server, not just the same language.

>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.)

Significant reduction in cognitive load for maintaining an application.

Reply on news.ycombinator.com