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

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

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.

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:

---
#!/usr/bin/env dub
/+ 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.

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.

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

Java, C#, Go, all have that, out of the box, seems to be a good way to retain people i think

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.

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:
>
> ---
> #!/usr/bin/env dub
> /+ 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"

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?

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.