On Wed, 2020-04-22 at 11:19 +0000, aliak via Digitalmars-d-learn wrote:
> On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote:
> > Now I discover Python, Rust, and Go have far nicer abstractions for writing Internet code than D does. Does D really not have a TcpListener abstraction?
> 
> It really doesn't :(

:-(

Even GTK+ has it's own wrappers around the base socket API to make it sensible for programmers. GtkD offers these for GtkD-based applications, but D has no language support for asynchronous (via Futures/Promises/event loops) which leaves Rust (and Python) far ahead in this race to support asynchronous programming.

> And D has so much potential as server tech with the potential combination of fibers + TLS + shared + static introspection.

Potential is necessary but not sufficient. Vibe.d seems to be one solution (in the Rust Async_std and Tokio sense) but Rust has language level support for Futures that make everything a lot easier in Rust than seemingly in D.

> The package Vibe-d is quite nice though. I don't know if you've tried it but it's very simple to get a listener up with it.

And now it seems we have Hunt. I am now dithering whether to use Vibe.d or
Hunt for my async TCP (but not HTTP(S)) server.

[…]
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Wednesday, 22 April 2020 at 10:32:48 UTC, Russel Winder wrote:
> I ended up creating the following project structure:
>
> .
> ├── dub.sdl
> ├── dub.selections.json
> ├── source
> │   ├── arcam_protocol.d
> │   └── main.d
> ├── tests
> │   └── integration_tests.d
> └── test_support
>     └── mock_avr850
>         └── main.d
>
> with the following Dub control file:
>
> name "arcamclient"
> description "arcamclient is a Rust/gtk-rs/GTK+ desktop application to control an Arcam amplifier over the Ethernet connection."
> authors "Russel Winder"
> copyright "Copyright © 2020 Russel Winder."
> license "GPL-3.0"
> targetType "executable"
> targetPath "bin"
>
> configuration "application" {
> }
>
> configuration "unittest" {
>     targetName "arcamclient_test"
>     dependency "unit-threaded" version="*"
>     mainSourceFile "bin/ut.d"
>     excludedSourceFiles "source/main.d"
>     preBuildCommands "$DUB run --compiler=$$DC unit-threaded -c gen_ut_main -- -f bin/ut.d -d $DUB"
>     preBuildCommands "$DUB build arcamclient:mock_avr850"
>     importPaths "tests"
>     sourcePaths "tests"
> }
>
> subPackage {
>     name "mock_avr850"
>     targetName "mock_avr850"
>     targetType "executable"
>     targetPath "bin"
>     sourcePaths "source" "test_support/mock_avr850"
>     importPaths "source" "test_support/mock_avr850"
>     excludedSourceFiles "source/main.d"
> }
>
> This seems a bit more sensible that what I have been able to achieve with Rust, but is still second rate compared to how easy things are using Python.
>

Have you try Silly? I found far more straightforward to use, that unit-threaded.

On my pet game engine, I got it working with this :

"configurations": [
...
    {
        "dependencies": {
            "beep": "~>0.0.2",
            "silly": "~>1.0.2"
        },
        "name": "unittest",
        "targetType": "library"
    }
],

Sadly, Silly only is the test runner (and one far prettier that unit-threaded). I need to add separated dub module to make assertion more easy and fluent. Beep go on the correct path with a API like this :

@("My test")
unittest {
    myFunc(1, 2, 3).expect!equals(42);
    auto a = [1, 2 ,3];
    a.expect!contains(2);
    a.lenght.expect!great(0);
    true.expect!true();
}

And the output on case of fail, shows a human friendly message with the expected value and the real value.

Another assertion module that not depends on unit-threaded and have better API, is pyjamas . But actually is abandoned. I did a try to get it working again, but depends on another dead dub module... another test runner called "bed" (that I did a PR to fix it to get it working against the actual DMD version).

Finally... What I really miss are two things :

- A test/integration framework like Spock (Yeah, I professionally  work on Java world :( )
- Test runners had a common output format that make IDE/tools work far more easy. See https://github.com/nomad-software/dunit/issues/19#issuecomment-435209223

Offtopic: Should be a way to mark a dub module dead on dub register. This last weeks I don't stop of finding dead/not working stuff and given a really bad image of the state of D.