www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - In the age of microservices and networking in general, were D is at?

reply ryuukk_ <ryuukk_ gmail.com> writes:
Hello

Today i want to talk a little bit about my experience trying to 
get a service setup in my server, so it could communicate with my 
existing solutions (i am in the process of porting everything i 
had to D)

So i wanted to replace a super basic piece, just to test things a 
little bit (i am already using D extensively for a game)

What do i need?

Basic HTTP Server to passively listen to messages

Basic HTTP Client to call some API services

TCP Server/Client to act as a proxy (needs SOCKS5 support)


Out of the box, D has:

Socket - without proxy support

HTTP client - with the help of CURL


Hmm, out of the box the experience is super poor, if one wanted 
to make a microservice, looking at the alternatives, GO is the 
only decent high level native language that has all needed out of 
the box

So i am forced to look at github/dub packages

And the expenrience there can varry a lot depending on the user 
(how he look for dub packages, google, github, code.dlang etc etc)

Couldn't the default experience be better?

What's preventing from having HTTP Server/Client, Socket with 
proxy support in the std lib?


In the day and age of microservices and networking in general, i 
think it is mandatory for any modern language to have such tools 
provided by default

A base where everyone could share expertise, and anyone could 
build middleware, on a same common base!

Right now the easiest solution would be to write microservice in 
other language..

Living is meant to consume current's air
Sep 13 2020
next sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
I forgot to add, but i personally volunter is starting the work 
on a better std.net solution

I'm not super experienced, but i think i can improve things, 
better than nothing? :D
Sep 13 2020
parent reply Seb <seb wilzba.ch> writes:
On Sunday, 13 September 2020 at 19:58:46 UTC, ryuukk_ wrote:
 I forgot to add, but i personally volunter is starting the work 
 on a better std.net solution

 I'm not super experienced, but i think i can improve things, 
 better than nothing? :D
 
 What's preventing from having HTTP Server/Client, Socket with 
 proxy support in the std lib?
We had this debate many, many times. There are _no_ plans to add anything to Phobos, it's essentially frozen for the same reasons as in all many other languages (e.g. stability >> features). tl;dr of these discussions: - Use https://code.dlang.org/packages/requests for a HTTP client - Use https://code.dlang.org/packages/vibe-d for a HTTP server Also, we aren't alone in our views here, see e.g. https://github.com/psf/requests/issues/2424.
 A base where everyone could share expertise, and anyone could 
 build middleware, on a same common base!
And then you want to fix/improve the API, but can't because you would break the world. Dub is _superior_ because it always semantic versioning and the community has figured out common bases e.g. https://code.dlang.org/packages/eventcore
 And the expenrience there can varry a lot depending on the user 
 (how he look for dub packages, google, github, code.dlang etc 
 etc)
 Couldn't the default experience be better?
It's on the front page of dlang.org: --- /+ dub.sdl: dependency "vibe-d" version="~>0.9.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } --- How could we improve that experience?
 Hmm, out of the box the experience is super poor
If using dub packages is hard or has a poor experience, then you/we should work on improving that experience. Ideas (and PRs) on this topic are always welcome.
Sep 13 2020
parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Sunday, 13 September 2020 at 20:57:47 UTC, Seb wrote:
 On Sunday, 13 September 2020 at 19:58:46 UTC, ryuukk_ wrote:
 I forgot to add, but i personally volunter is starting the 
 work on a better std.net solution

 I'm not super experienced, but i think i can improve things, 
 better than nothing? :D
 
 What's preventing from having HTTP Server/Client, Socket with 
 proxy support in the std lib?
We had this debate many, many times. There are _no_ plans to add anything to Phobos, it's essentially frozen for the same reasons as in all many other languages (e.g. stability >> features). tl;dr of these discussions: - Use https://code.dlang.org/packages/requests for a HTTP client - Use https://code.dlang.org/packages/vibe-d for a HTTP server Also, we aren't alone in our views here, see e.g. https://github.com/psf/requests/issues/2424.
 A base where everyone could share expertise, and anyone could 
 build middleware, on a same common base!
And then you want to fix/improve the API, but can't because you would break the world. Dub is _superior_ because it always semantic versioning and the community has figured out common bases e.g. https://code.dlang.org/packages/eventcore
 And the expenrience there can varry a lot depending on the 
 user (how he look for dub packages, google, github, code.dlang 
 etc etc)
 Couldn't the default experience be better?
It's on the front page of dlang.org: --- /+ dub.sdl: dependency "vibe-d" version="~>0.9.0" +/ void main() { import vibe.d; listenHTTP(":8080", (req, res) { res.writeBody("Hello, World: " ~ req.path); }); runApplication(); } --- How could we improve that experience?
After reflection and your post demonstrates that it is not an issue at all What i'm after thought is the phsycological part of it, getting started now involves having to consume a dependency, just to get an http listener If we look at things on a global scale, it doesn't matter since you usually need the whole middle ware But if you look much smaller scale, people who just want to test/experiment Having a simple way to create a listener, without having to add packages to a project, feels much better (look at GO, getting started with ease is key)
 Hmm, out of the box the experience is super poor
If using dub packages is hard or has a poor experience, then you/we should work on improving that experience. Ideas (and PRs) on this topic are always welcome.
DUB is AWESOME, i wouldn't use D that much without a proper package manager, and DUB is perfect for that! It's just the fact that it's something you have to pull to get started, on top of downloading the whole dmd + dub, it feels not needed, hence the need of something in the std lib Maybe i am just overthinking it, but yes you have a point, and i exaggerate a little bit on the "out of the box experience"
Sep 13 2020
parent Jacob Carlborg <doob me.com> writes:
On 2020-09-13 23:08, ryuukk_ wrote:

 What i'm after thought is the phsycological part of it, getting started 
 now involves having to consume a dependency, just to get an http listener
I can really agree with this. For someone new to the language and the ecosystem it can be difficult to find which dependency is the "right" choice to pick. -- /Jacob Carlborg
Sep 16 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 13 September 2020 at 19:52:52 UTC, ryuukk_ wrote:
 Out of the box, D has:

 Socket - without proxy support

 HTTP client - with the help of CURL
That was not quite complete. Further we have. A curl wrapper that works quite well. Curl is often the underlying library for microservices regardless if you use it directly or via an additional layer. Vibe.d, a very complete web application framework. Hunt framework is also available which is supposed a very complete framework. https://wiki.dlang.org/Web_Development_Libraries Also, out of the box is not really fair here. Many other languages has very good frameworks as well but they are 3rd party like Actix for Rust.
Sep 13 2020
parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Sunday, 13 September 2020 at 20:52:28 UTC, IGotD- wrote:
 On Sunday, 13 September 2020 at 19:52:52 UTC, ryuukk_ wrote:
 Out of the box, D has:

 Socket - without proxy support

 HTTP client - with the help of CURL
That was not quite complete. Further we have. A curl wrapper that works quite well. Curl is often the underlying library for microservices regardless if you use it directly or via an additional layer. Vibe.d, a very complete web application framework. Hunt framework is also available which is supposed a very complete framework. https://wiki.dlang.org/Web_Development_Libraries Also, out of the box is not really fair here. Many other languages has very good frameworks as well but they are 3rd party like Actix for Rust.
Rust isn't used that much on that field, i was mainly aiming at GOLANG Concerning vibe.d, i'm worried about the dependencies it pulls, also the benchmark: https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r GO vs D, it performs quite poorly Concerning hunt, unfortunately the simple fact of having import hunt.http; increase compile time from 2 to 8 seconds.. wich is not desirable at all.. Right now the blocker is a simple HTTP listener, there is no such thing in the std lib Maybe that is the one thing i can contribute in the near future, just for the sack of having something out of the box way to retain people i think
Sep 13 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 13 September 2020 at 20:58:10 UTC, ryuukk_ wrote:
 Right now the blocker is a simple HTTP listener, there is no 
 such thing in the std lib
Yes, there is, std.net.curl. I don't know what your definition of simple is but if you demand a totally independent one without curl, no there isn't.
Sep 13 2020
parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Sunday, 13 September 2020 at 21:07:03 UTC, IGotD- wrote:
 On Sunday, 13 September 2020 at 20:58:10 UTC, ryuukk_ wrote:
 Right now the blocker is a simple HTTP listener, there is no 
 such thing in the std lib
Yes, there is, std.net.curl. I don't know what your definition of simple is but if you demand a totally independent one without curl, no there isn't.
Can you show me how to setup an HTTP listener and with simple routes using std.net.curl?
Sep 13 2020
parent IGotD- <nise nise.com> writes:
On Sunday, 13 September 2020 at 21:09:48 UTC, ryuukk_ wrote:
 Can you show me how to setup an HTTP listener and with simple 
 routes using std.net.curl?
Sorry, I mixed up client and server here. No you can't.
Sep 13 2020
prev sibling next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 Concerning vibe.d, i'm worried about the dependencies it pulls,
 also the benchmark:

 https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r

 GO vs D, it performs quite poorly

 This benchmark is not perfect, vibe-d is fast, I can even rewrite those
benchmark to make vibe-d same fast as actix-core. So I would not be afraid of vibe-d performance.
Sep 13 2020
parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:
 On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 Concerning vibe.d, i'm worried about the dependencies it 
 pulls, also the benchmark:

 https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r

 GO vs D, it performs quite poorly

 This benchmark is not perfect, vibe-d is fast, I can even 
 rewrite those
benchmark to make vibe-d same fast as actix-core. So I would not be afraid of vibe-d performance.
I think it needs to be updated then, that would clear some of my concerns about vibe.d I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
Sep 13 2020
next sibling parent reply James Blachly <james.blachly gmail.com> writes:
On 9/13/20 5:16 PM, ryuukk_ wrote:
 I think it needs to be updated then, that would clear some of my 
 concerns about vibe.d
 
 I think the plain text one is the most important one to fix first, such 
 basic concept shouldn't be that slow
I haven't double checked vibe-d's benchmark code, but FYI many of the other "ultra performant" frameworks are essentially cheating (even if staying within the rules) by optimizing code paths to work ONLY for the benchmark. For example, instead of matching on the route, they match on the first character of, or the length of the route.
Sep 13 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 14 September 2020 at 02:01:09 UTC, James Blachly wrote:
 For example, instead of matching on the route, they match on 
 the first character of, or the length of the route.
So that's kinda sorta cheating, but like that kind of thing is one of the reasons why code like my cgi.d is why it is: you can use as much or as little of it as you need. For some programs, i use the fancy page generation framework. For others, I just write("hello world"). That's the way the lib is intended to be used, so I wouldn't really call it cheating if theirs are that flexible too.
Sep 13 2020
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Sun, Sep 13, 2020 at 11:20 PM ryuukk_ via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 I think the plain text one is the most important one to fix
 first, such basic concept shouldn't be that slow
As others already pointed out, it is not thats vibe-d perform bad. But the others use some not so nice tricks to be so fast. This is why I say I can make vibe-d same fast as the others, but it would be cheating from my perspective. They do not real http parsing, they generally just match only the minimum what they needed. They use static buffer with already prepared responses They do not send all http headers They use one char Server name http header. So when I use vibe-d without the http package and just use TCPconnection and do the same as the others I would have the same speed, but this is not what you generally want.
Sep 13 2020
prev sibling next sibling parent Daniel Kozak <kozzi11 gmail.com> writes:
On Mon, Sep 14, 2020 at 7:39 AM Daniel Kozak <kozzi11 gmail.com> wrote:

 On Sun, Sep 13, 2020 at 11:20 PM ryuukk_ via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 I think the plain text one is the most important one to fix
 first, such basic concept shouldn't be that slow
As others already pointed out, it is not thats vibe-d perform bad. But the others use some not so nice tricks to be so fast. This is why I say I can make vibe-d same fast as the others, but it would be cheating from my perspective. They do not real http parsing, they generally just match only the minimum what they needed. They use static buffer with already prepared responses They do not send all http headers They use one char Server name http header. So when I use vibe-d without the http package and just use TCPconnection and do the same as the others I would have the same speed, but this is not what you generally want.
But to be fair, there are many places where vibe-d performance could be improved: There is a big penalty when you use keep-alive smaller then Duration.max vibe-d write headers independet from body content which is one of other big performance penalty vibe-d do address translation with each request thats other performance hit
Sep 13 2020
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:
 On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak 
 wrote:
 On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 Concerning vibe.d, i'm worried about the dependencies it 
 pulls, also the benchmark:

 https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r

 GO vs D, it performs quite poorly
I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1r
Sep 18 2020
next sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Friday, 18 September 2020 at 12:11:58 UTC, Imperatorn wrote:
 On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:
 On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak 
 wrote:
 On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 Concerning vibe.d, i'm worried about the dependencies it 
 pulls, also the benchmark:

 https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijoc7-1r

 GO vs D, it performs quite poorly
I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1r
hunt looks promising but https://github.com/huntlabs/hunt-http/issues/20 = not so good
Sep 18 2020
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 18 September 2020 at 14:31:20 UTC, ryuukk_ wrote:
 On Friday, 18 September 2020 at 12:11:58 UTC, Imperatorn wrote:
 On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:
 On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak 
 wrote:
 On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 [...]
I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1r
hunt looks promising but https://github.com/huntlabs/hunt-http/issues/20 = not so good
Hmm, I'll try take a look later
Sep 19 2020
parent tchaloupka <chalucha gmail.com> writes:
On Saturday, 19 September 2020 at 17:15:03 UTC, Imperatorn wrote:
 On Friday, 18 September 2020 at 14:31:20 UTC, ryuukk_ wrote:
 On Friday, 18 September 2020 at 12:11:58 UTC, Imperatorn wrote:
 On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:
 On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak 
 wrote:
 On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d 
 < digitalmars-d puremagic.com> wrote:

 [...]
I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1r
hunt looks promising but https://github.com/huntlabs/hunt-http/issues/20 = not so good
Hmm, I'll try take a look later
As a longterm vibe-d user I'm interested in this comparison too and this comes out of this: https://github.com/tchaloupka/httpbench Hopefully it'd be useful - PR's are welcome.
Sep 20 2020
prev sibling parent James Blachly <james.blachly gmail.com> writes:
On 9/18/20 8:11 AM, Imperatorn wrote:
 On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:
 On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:
 On Sun, Sep 13, 2020 at 11:00 PM ryuukk_ via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 Concerning vibe.d, i'm worried about the dependencies it pulls, also 
 the benchmark:

 https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test
fortune&l=zijoc7-1r 


 GO vs D, it performs quite poorly
I think the plain text one is the most important one to fix first, such basic concept shouldn't be that slow
Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=p aintext&l=zijoc7-1r
The plaintext benchmark looks fast, but note that the router is simply matching on the exact length of the path name used in the benchmark: ``` override void onComplete(HttpRequest req) { string path = req.uri; if(path.length == plaintextLength) { // plaintext respondWith("Hello, World!", 200, textHeader); } else if(path.length == jsonLength) { // json JSONValue js = JSONValue(["message" : JSONValue("Hello, World!")]); respondWith(js.toJSON(), 200, jsonHeader); } else { ``` https://github.com/TechEmpower/FrameworkBenchmarks/blob/00fd915d843ce734f44a1af5385b4e321003bfee/frameworks/D/hunt/http/http/DemoProcessor.d#L43-L50
Sep 18 2020
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2020-09-13 22:58, ryuukk_ wrote:

 Concerning vibe.d, i'm worried about the dependencies it pulls, also the 
 benchmark: 
 https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test
fortune&l=zijoc7-1r 
I did some benchmark on some real world code at my previous work. We compared the performance (number of requests per second) of an HTTP endpoint. It fetched some data from a PostgreSQL database, did some processing and returned the result as JSON. We compared a highly optimized version implemented in Ruby, this was the baseline. Then a colleague implemented a version in Go and I did an implementation in D, using vibe.d . The end result was that the Go version ran at 0.5x of the Ruby version and the D version ran at 5x of the Ruby version. This was without trying to optimize the code afterwards. Only some common sense while writing the code, like if you can do it at compile time, do that. I'm pretty sure I didn't even used LDC for an optimized build. Of course, everyone at the company was only talking about how on earth the Go version could be slower than the Ruby version. Someone later did some improvements so that the Go version was up to the same speed as Ruby. Nobody talked about how much faster the D version was, except me :( . -- /Jacob Carlborg
Sep 16 2020
next sibling parent reply ryuukk_ <ryuukk_ gmail.com> writes:
On Wednesday, 16 September 2020 at 19:14:57 UTC, Jacob Carlborg 
wrote:
 On 2020-09-13 22:58, ryuukk_ wrote:

 [...]
I did some benchmark on some real world code at my previous work. We compared the performance (number of requests per second) of an HTTP endpoint. It fetched some data from a PostgreSQL database, did some processing and returned the result as JSON. We compared a highly optimized version implemented in Ruby, this was the baseline. Then a colleague implemented a version in Go and I did an implementation in D, using vibe.d . The end result was that the Go version ran at 0.5x of the Ruby version and the D version ran at 5x of the Ruby version. This was without trying to optimize the code afterwards. Only some common sense while writing the code, like if you can do it at compile time, do that. I'm pretty sure I didn't even used LDC for an optimized build. Of course, everyone at the company was only talking about how on earth the Go version could be slower than the Ruby version. Someone later did some improvements so that the Go version was up to the same speed as Ruby. Nobody talked about how much faster the D version was, except me :( .
I also experienced it, i am rewritting most of my server services and so far i get huge gain in performance, this allowed me to downgrade the server and save money! I plan to rewrite more, but i need better HTTP story..
Sep 18 2020
next sibling parent ryuukk_ <ryuukk_ gmail.com> writes:
On Friday, 18 September 2020 at 14:32:36 UTC, ryuukk_ wrote:
 On Wednesday, 16 September 2020 at 19:14:57 UTC, Jacob Carlborg 
 wrote:
 [...]
I also experienced it, i am rewritting most of my server services and so far i get huge gain in performance, this allowed me to downgrade the server and save money! I plan to rewrite more, but i need better HTTP story..
* networking in general, not just HTTP
Sep 18 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 18 September 2020 at 14:32:36 UTC, ryuukk_ wrote:
 I also experienced it, i am rewritting most of my server 
 services and so far i get huge gain in performance, this 
 allowed me to downgrade the server and save money!

 I plan to rewrite more, but i need better HTTP story..
Just to be more specific, you are rewriting from Ruby to Go or was it D?
Sep 18 2020
parent ryuukk_ <ryuukk_ gmail.com> writes:
On Friday, 18 September 2020 at 14:50:15 UTC, IGotD- wrote:
 On Friday, 18 September 2020 at 14:32:36 UTC, ryuukk_ wrote:
 I also experienced it, i am rewritting most of my server 
 services and so far i get huge gain in performance, this 
 allowed me to downgrade the server and save money!

 I plan to rewrite more, but i need better HTTP story..
Just to be more specific, you are rewriting from Ruby to Go or was it D?
java and some python to D
Sep 18 2020
prev sibling parent reply Pierce Ng <pierce samadhiweb.com> writes:
On Wednesday, 16 September 2020 at 19:14:57 UTC, Jacob Carlborg 
wrote:
 The end result was that the Go version ran at 0.5x of the Ruby 
 version and the D version ran at 5x of the Ruby version. This 
 was without trying to optimize the code afterwards. Only some 
 common sense while writing the code, like if you can do it at 
 compile time, do that. I'm pretty sure I didn't even used LDC 
 for an optimized build.
Apologies for replying to an old post, but "0.5x of Ruby" and "5x of Ruby" could be read to mean that the Go version ran in half the time of the Ruby version while the D version took 5 times as long to run.
 Of course, everyone at the company was only talking about how 
 on earth the Go version could be slower than the Ruby version. 
 Someone later did some improvements so that the Go version was 
 up to the same speed as Ruby. Nobody talked about how much 
 faster the D version was, except me :( .
Ok you meant Go version was half the performance of the Ruby version and D version was 5 times faster. This reply hopefully adds context to search engine indexing when people look for D performance. :-)
Jan 09
parent Jacob Carlborg <doob me.com> writes:
On 2021-01-10 02:50, Pierce Ng wrote:

 Apologies for replying to an old post, but "0.5x of Ruby" and "5x of 
 Ruby" could be read to mean that the Go version ran in half the time of 
 the Ruby version while the D version took 5 times as long to run.
I can see now that could have been misunderstood. What was measured was requests per seconds, not execution time. So a higher value is better.
 Ok you meant Go version was half the performance of the Ruby version and 
 D version was 5 times faster.
Yes. -- /Jacob Carlborg
Jan 09
prev sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Sun, Sep 13, 2020 at 9:55 PM ryuukk_ via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 Hello

 ....

 So i am forced to look at github/dub packages
What is wrong on this? Dub is official part of D ecosystem so this is the right way. Just select the package you need add it to your dub dependencies and thats all. There is vibe-d, hunt and maybe others packages which do what you need. I do not see any advantages to have this in phobos.
Sep 13 2020
parent ryuukk_ <ryuukk_ gmail.com> writes:
On Sunday, 13 September 2020 at 20:58:04 UTC, Daniel Kozak wrote:
 On Sun, Sep 13, 2020 at 9:55 PM ryuukk_ via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 Hello

 ....

 So i am forced to look at github/dub packages
What is wrong on this? Dub is official part of D ecosystem so this is the right way. Just select the package you need add it to your dub dependencies and thats all. There is vibe-d, hunt and maybe others packages which do what you need. I do not see any advantages to have this in phobos.
maybe i am just a different demographic.. What i mean is the dependencies, it being a dub package, doesn't prevent author from pulling ton of other dependencies If it was in the std lib, it would stay simple, without the need of external dependencies And everyone could contribute making it as fast as possible, making all other middleware profit from the improvements by default Dependencies feals heavy, the less you have, the better it is And there is nothing wrong with dub/github, for such heave used kind of API, it deserve a place in the std lib in my opinion
Sep 13 2020