
Hunt: A high-level D Programming Language Web framework - chenzhekl
https://github.com/huntlabs/hunt-framework
======
continuations
Why does D perform so poorly for web programming?

[https://www.techempower.com/benchmarks/](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.

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

~~~
amelius
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.

~~~
TylerE
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.

~~~
gnulinux
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.

~~~
pjmlp
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.

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

~~~
jimbob45
What would having symmetrical code accomplish?

~~~
amelius
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.

~~~
realharo
_> 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.)

