Maybe you can also include D + Vibe.d about app-servers HOT 12 CLOSED

Interesting point thanks.
Has D-lang any built-in HTTP server or must it rely on a 3rd party library like Vibe?
I'd rather prefer to stick with standard implementation when available ;)

from app-servers.

Unfortunately D has no build in webserver. It relies completely on vibe.d as one of the more feature complete HTTP server solutions. Its actually the only HTTP server that D has that is constantly updated and supported.

from app-servers.

Thanks, i am going to use Vibe then. I tested it, but unfortunately i cannot run it in parallel.
Do you know how to run Vibe server on all cores? I read Vibe supports parallelism via multi-threading.

from app-servers.

I am at the moment outside, so i can only post some quick stuff.

auto settings = new HTTPServerSettings("0.0.0.0:3000");
settings.options |= HTTPServerOption.reusePort;
listenHTTP(settings, &handleRequest);

That allows you to use the reuseport. Change reuse port option by .... There are two options. One is async and one is libevent.

Other option is:

https://github.com/nuald/simple-web-benchmark/tree/master/d

For a example of parallel letting D do the work.

Hope this helps

from app-servers.

Thanks,
i found the branch too ;)
Unfortunately it seems on OSX the reusePort option does not take effects: the code spawns multiple threads, but they are sticked to one CPU only.
I fear OSX doe not support the REUSE_PORT directive, like other Linux do.
As it is, Vibe is slower than Ruby, which i suspect does not make it credit...

from app-servers.

Included single core benchmarks of Vibe. Closing the issue, thanks.

from app-servers.

Just got home

	settings.options |= HTTPServerOption.distribute;

Use this instead of reusePort. That normally will do the trick.

from app-servers.

Tried out: same result. OSX is apparently unable to run Vibe in parallel. I suppose is something related to port re-using of multiple threads, since threads are indeed spawned correctly.
By using just libevent, D proves to be much slower than Crystal, which runs on one core by relying on LLVM and libevent too.

from app-servers.

Its strange but i am not surprised. My own tests with Go and D on a arm based PI show that Go is faster even when multi threading correctly and being more Io bound. D is a great language but at times I find the results disappointing.

Crystal for being such a young language ... They are what 4 years in developed vs D its 17 years. Crystal is showing way more impressive performance and being also very easy to read. Well, especially compared to Rust haha.

Going to invest more time into Crystal. Your results confirm some of my impression that D is not the language if one wants max performance with a easy language, for webdevelopment.

from app-servers.

Thanks for your feedback.
Yes, Crystal is very easy compared to Rust, but i think they cover different scopes: Rust excels in system programming (no GC, low memory).
Crystal will be more a challenge for GO, albeit it still lacks parallelism (but they have it on 1.0 roadmap) and compiling time is not as good as GO.
GO on the other side does almost everything the right way: complete and consistent standard library, parallelism via green threads, func as first level objects, simplicity (no generics), duck-typing. GO also has bad parts as well: verbose error handling, type switches (really?).
You just have to choose the right tools for your purposes ;)

from app-servers.

I have tried to like Go but the enforced coding style just does not fit with me. Give me new line brackets or no brackets but this same line brackets always made things harder to read. Same with no real class support and forcing the inclusion of composite design... And while the developers disagree I do find that generics can be useful in specific cases.

The right tool does not exist because they all have issues. It can be language related or editor support, design choices, forced choices, ...

from app-servers.

Pressed commit by accident. This is what happens when you write on a smartphone ;)

It is hard to find a good tool because it can involved 100 of factors, many outside your ability to handle.

I like D but there are so many factors that make it issue full for the future. The performance on the vibe.d alone is for me a issue. The focus of the development team. Crystal is also nice but they lack developer's. Go is too much enforced and linked so much with Google that you are getting Google's way or the highway. Notice the constant forces on the GC when there are a lot if open issues. Its because google has need for a better performance GC on there servers, so all the rest that people complain about gets ignored.

Its hard to find a c like language ( go is not c speed ) in speed, easy to write, memory safe, hell, even without a GC. Zig comes to mind but that is a one man show still.

Hard choices...

from app-servers.