digitalmars.D - In the age of microservices and networking in general, were D is at?
- ryuukk_ (32/32) Sep 13 2020 Hello
- ryuukk_ (4/4) Sep 13 2020 I forgot to add, but i personally volunter is starting the work
- Seb (33/47) Sep 13 2020 We had this debate many, many times. There are _no_ plans to add
- ryuukk_ (20/69) Sep 13 2020 After reflection and your post demonstrates that it is not an
- Jacob Carlborg (6/8) Sep 16 2020 I can really agree with this. For someone new to the language and the
- IGotD- (13/16) Sep 13 2020 That was not quite complete.
- ryuukk_ (16/36) Sep 13 2020 Rust isn't used that much on that field, i was mainly aiming at
- IGotD- (4/6) Sep 13 2020 Yes, there is, std.net.curl. I don't know what your definition of
- ryuukk_ (3/11) Sep 13 2020 Can you show me how to setup an HTTP listener and with simple
- IGotD- (2/4) Sep 13 2020 Sorry, I mixed up client and server here. No you can't.
- Daniel Kozak (4/9) Sep 13 2020 benchmark to make vibe-d same fast as actix-core.
- ryuukk_ (5/19) Sep 13 2020 I think it needs to be updated then, that would clear some of my
- James Blachly (6/11) Sep 13 2020 I haven't double checked vibe-d's benchmark code, but FYI many of the
- Adam D. Ruppe (8/10) Sep 13 2020 So that's kinda sorta cheating, but like that kind of thing is
- Daniel Kozak (14/16) Sep 13 2020 As others already pointed out, it is not thats vibe-d perform bad. But t...
- Daniel Kozak (7/25) Sep 13 2020 But to be fair, there are many places where vibe-d performance could be
- Imperatorn (3/17) Sep 18 2020 Did you take a look at hunt?
- ryuukk_ (3/20) Sep 18 2020 hunt looks promising but
- Imperatorn (2/18) Sep 19 2020 Hmm, I'll try take a look later
- tchaloupka (5/24) Sep 20 2020 As a longterm vibe-d user I'm interested in this comparison too
- James Blachly (15/35) Sep 18 2020 The plaintext benchmark looks fast, but note that the router is simply
- Jacob Carlborg (19/22) Sep 16 2020 I did some benchmark on some real world code at my previous work. We
- ryuukk_ (6/27) Sep 18 2020 I also experienced it, i am rewritting most of my server services
- ryuukk_ (2/9) Sep 18 2020 * networking in general, not just HTTP
- IGotD- (3/7) Sep 18 2020 Just to be more specific, you are rewriting from Ruby to Go or
- ryuukk_ (2/11) Sep 18 2020 java and some python to D
- Pierce Ng (10/21) Jan 09 2021 Apologies for replying to an old post, but "0.5x of Ruby" and "5x
- Jacob Carlborg (6/11) Jan 09 2021 I can see now that could have been misunderstood. What was measured was
- Daniel Kozak (7/10) Sep 13 2020 What is wrong on this? Dub is official part of D ecosystem so this is t...
- ryuukk_ (12/29) Sep 13 2020 maybe i am just a different demographic..
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
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
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/eventcoreAnd 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 poorIf 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
On Sunday, 13 September 2020 at 20:57:47 UTC, Seb wrote:On Sunday, 13 September 2020 at 19:58:46 UTC, ryuukk_ wrote: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)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/eventcoreAnd 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?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"Hmm, out of the box the experience is super poorIf 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
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 listenerI 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
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 CURLThat 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
On Sunday, 13 September 2020 at 20:52:28 UTC, IGotD- wrote:On Sunday, 13 September 2020 at 19:52:52 UTC, ryuukk_ wrote: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 thinkOut of the box, D has: Socket - without proxy support HTTP client - with the help of CURLThat 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
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 libYes, 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
On Sunday, 13 September 2020 at 21:07:03 UTC, IGotD- wrote:On Sunday, 13 September 2020 at 20:58:10 UTC, ryuukk_ wrote:Can you show me how to setup an HTTP listener and with simple routes using std.net.curl?Right now the blocker is a simple HTTP listener, there is no such thing in the std libYes, 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
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
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 thosebenchmark to make vibe-d same fast as actix-core. So I would not be afraid of vibe-d performance.
Sep 13 2020
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 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 slowConcerning 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 thosebenchmark to make vibe-d same fast as actix-core. So I would not be afraid of vibe-d performance.
Sep 13 2020
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 slowI 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
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
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 slowAs 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
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: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 hitI think the plain text one is the most important one to fix first, such basic concept shouldn't be that slowAs 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
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:Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1rOn 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 slowConcerning 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
Sep 18 2020
On Friday, 18 September 2020 at 12:11:58 UTC, Imperatorn wrote:On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:hunt looks promising but https://github.com/huntlabs/hunt-http/issues/20 = not so goodOn Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1rOn 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 slowConcerning 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
Sep 18 2020
On Friday, 18 September 2020 at 14:31:20 UTC, ryuukk_ wrote:On Friday, 18 September 2020 at 12:11:58 UTC, Imperatorn wrote:Hmm, I'll try take a look laterOn Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:hunt looks promising but https://github.com/huntlabs/hunt-http/issues/20 = not so goodOn Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1rOn 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[...]
Sep 19 2020
On Saturday, 19 September 2020 at 17:15:03 UTC, Imperatorn wrote:On Friday, 18 September 2020 at 14:31:20 UTC, ryuukk_ wrote: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.On Friday, 18 September 2020 at 12:11:58 UTC, Imperatorn wrote:Hmm, I'll try take a look laterOn Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote:hunt looks promising but https://github.com/huntlabs/hunt-http/issues/20 = not so goodOn Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext&l=zijoc7-1rOn 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[...]
Sep 20 2020
On 9/18/20 8:11 AM, Imperatorn wrote:On Sunday, 13 September 2020 at 21:16:52 UTC, ryuukk_ wrote: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-L50On Sunday, 13 September 2020 at 21:09:55 UTC, Daniel Kozak wrote:Did you take a look at hunt? https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=p aintext&l=zijoc7-1rOn 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 slowConcerning 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
Sep 18 2020
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-1rI 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
On Wednesday, 16 September 2020 at 19:14:57 UTC, Jacob Carlborg wrote:On 2020-09-13 22:58, 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..[...]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 :( .
Sep 18 2020
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:* networking in general, not just HTTP[...]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
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
On Friday, 18 September 2020 at 14:50:15 UTC, IGotD- wrote:On Friday, 18 September 2020 at 14:32:36 UTC, ryuukk_ wrote:java and some python to DI 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
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 2021
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 2021
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 packagesWhat 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
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: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 opinionHello .... So i am forced to look at github/dub packagesWhat 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