On Thursday, 24 October 2019 at 12:35:43 UTC, Radu wrote:
> On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
>> This thread is for general feedback and discussion regarding Átila's blog post on his vision for D's future.
>>
>> https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
> ...

That's terrific feedback, a critique with actionable items drawn from experience.

I agree and share that experience, namely, I'm very positive about betterC, but there are many rough edges (yes, especially CTFE and missing library features) and I doubt I'd recommend it in it's current state for "real work" against the alternatives.

> All these problems are systemic and come from the lack of orthogonality in the core and std libs, the language had some improvements in using a template based run-time interface, but still has warts like no betterC CTFE. There are a lot of assumptions about what is available in terms of language and run-time, and vast majority of APIs in std lib is written with RTTI, exceptions and GC in mind.
> In a perfect world core/std APIs will be layered bottom-up, so you have access to some (most?) algorithms and data structures from the lower denominator (betterC) till up the chain with GC, exceptions, type info where it makes sense.
> It's the "pay as you go" mindset, that was discussed at length on this forum, that is not a reality yet.

That's the vision I could get behind. I think there are many on this list who have an aversion to this vision though, so I'm skeptical that it will happen anytime soon.

On 10/24/2019 5:35 AM, Radu wrote:
> And this comes from a semi failed experiment of mine trying to code a C library in D using -betterC. My conclusions:
> 
> - You miss the nice dynamic arrays and hash map structures, and others. You end-up rolling your own or wrapping C libraries, which requires lots of effort.
> - There is no way to generate C/C++ header files from your extern(C/C++) declaration, I know this is being worked on. So had to roll my own.
> - I had to roll out my own RefCount, Nullable and friends.
> - At that time copy ctor was not available, so me wanting to properly use immutable for non POD types was a pain.
> - CTFE is severely limited.
> Most of these are tracked as bugs already, in case *thatsomeone* asks :)

Since all but the second item are not C features, I don't see how these caused your DasBetterC project to fail.


> but still has warts like no betterC CTFE.

Specifics, please.

BTW, many of Phobos' modules are template only, meaning they should work with betterC.

On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:
> On 10/24/2019 5:35 AM, Radu wrote:
>> And this comes from a semi failed experiment of mine trying to code a C library in D using -betterC. My conclusions:
>> 
>> - You miss the nice dynamic arrays and hash map structures, and others. You end-up rolling your own or wrapping C libraries, which requires lots of effort.
>> - There is no way to generate C/C++ header files from your extern(C/C++) declaration, I know this is being worked on. So had to roll my own.
>> - I had to roll out my own RefCount, Nullable and friends.
>> - At that time copy ctor was not available, so me wanting to properly use immutable for non POD types was a pain.
>> - CTFE is severely limited.
>> Most of these are tracked as bugs already, in case *thatsomeone* asks :)
>
> Since all but the second item are not C features, I don't see how these caused your DasBetterC project to fail.
>
>
>> but still has warts like no betterC CTFE.
>
> Specifics, please.
>
> BTW, many of Phobos' modules are template only, meaning they should work with betterC.

For me the betterC problems arise more in mixin generate codes.
I believe that every function that interacts with strings fail.(i think that´s because it uses some autoencoding code that uses gc, at least looks like that when i tried to search for the problem)

ex:
//this fails with -betterC
import std.string : split;
return "int x; ,".split(",")[0];

> ex:
> //this fails with -betterC
> import std.string : split;
> return "int x; ,".split(",")[0];

Sorry, countUntil is a better example

> //this fails with -betterC
import std.algorithm : countUntil;
auto index = "int x; ,".countUntil(";");

On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:
> On 10/24/2019 5:35 AM, Radu wrote:
>> And this comes from a semi failed experiment of mine trying to code a C library in D using -betterC. My conclusions:
>> 
>> - You miss the nice dynamic arrays and hash map structures, and others. You end-up rolling your own or wrapping C libraries, which requires lots of effort.
>> - There is no way to generate C/C++ header files from your extern(C/C++) declaration, I know this is being worked on. So had to roll my own.
>> - I had to roll out my own RefCount, Nullable and friends.
>> - At that time copy ctor was not available, so me wanting to properly use immutable for non POD types was a pain.
>> - CTFE is severely limited.
>> Most of these are tracked as bugs already, in case *thatsomeone* asks :)
>
> Since all but the second item are not C features, I don't see how these caused your DasBetterC project to fail.
>

What do you mean? They are D issues, the only C "feature" you really use is the extern(C)
declaration on the API level.

>
>> but still has warts like no betterC CTFE.
>
> Specifics, please.
>
> BTW, many of Phobos' modules are template only, meaning they should work with betterC.

```
string foo()(string a, string b)
{
    return a ~ b;
}

extern(C) void main()
{
   enum x = foo("a", "b");
}
Error: array concatenation of expression a ~ b requires the GC which is not available with -betterC
```
Hey ho
https://issues.dlang.org/show_bug.cgi?id=20086
https://issues.dlang.org/show_bug.cgi?id=20101
https://github.com/dlang/dmd/pull/8253

Some algorithms are working indeed but it is a stupid trial and error exercise each time you want to use some template code from std. And you risk that the next compiler release could break them, because they are not really tested against -betterC.

```
import std.bitmanip : bitsSet;
import std.algorithm.comparison : equal;

extern(C) void main()
{
  assert(bitsSet(1).equal([0]));
}
Error: TypeInfo cannot be used with -betterC
```

On Friday, 25 October 2019 at 05:23:33 UTC, Radu wrote:
> On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:
>> On 10/24/2019 5:35 AM, Radu wrote:
>>> [...]
>>
>> Since all but the second item are not C features, I don't see how these caused your DasBetterC project to fail.
>>
>
> What do you mean? They are D issues, the only C "feature" you really use is the extern(C)
> declaration on the API level.
>
>>
>>> [...]
>>
>> Specifics, please.
>>
>> BTW, many of Phobos' modules are template only, meaning they should work with betterC.
>
> ```
> string foo()(string a, string b)
> {
>     return a ~ b;
> }
>
> extern(C) void main()
> {
>    enum x = foo("a", "b");
> }
> Error: array concatenation of expression a ~ b requires the GC which is not available with -betterC
> ```
> Hey ho
> https://issues.dlang.org/show_bug.cgi?id=20086
> https://issues.dlang.org/show_bug.cgi?id=20101
> https://github.com/dlang/dmd/pull/8253
>
> Some algorithms are working indeed but it is a stupid trial and error exercise each time you want to use some template code from std. And you risk that the next compiler release could break them, because they are not really tested against -betterC.
>
> ```
> import std.bitmanip : bitsSet;
> import std.algorithm.comparison : equal;
>
> extern(C) void main()
> {
>   assert(bitsSet(1).equal([0]));
> }
> Error: TypeInfo cannot be used with -betterC
> ```

Taken from the samples on front page
```
struct Point
{
    private double[2] p;
    // Forward all undefined symbols to p
    alias p this;
    double dot(Point rhs)
    {
        return p[0] * rhs.p[0] + p[1] * rhs.p[1];
    }
}

extern(C) void main()
{
    Point p1, p2; p1 = [2, 1], p2 = [1, 1];
    assert(p1[$ - 1] == 1);
}
error: undefined reference to '_memsetDouble'
collect2: error: ld returned 1 exit status
```
Same works in LDC, imagine you want to support both compilers...

On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:
>> but still has warts like no betterC CTFE.
>
> Specifics, please.
>
> BTW, many of Phobos' modules are template only, meaning they should work with betterC.

Many do indeed. And many don't.

Like `chain` https://run.dlang.io/is/sU4q80
Anything on strings like `toLower`, `canFind` https://run.dlang.io/is/8PS9Vd
Until recently tuple didn't work

Other times, some function should work, but they are inside a file that imports something that doesn't.

And of course the problem that anything that doesn't work at betterC runtime, won't work in CTFE as well. Which I understand, but goes against intuition.

Having said that, I am of the same opinion as Mike Franklin, and I would rather see work being done on a pay-as-you-go druntime than on a better betterC.

On 10/24/2019 11:44 PM, Sebastiaan Koppe wrote:
> Having said that, I am of the same opinion as Mike Franklin, and I would rather see work being done on a pay-as-you-go druntime than on a better betterC.

The two mostly go together.

On Thursday, 17 October 2019 at 07:18:15 UTC, Russel Winder wrote:
> On Wed, 2019-10-16 at 21:20 +0000, aberba via Digitalmars-d wrote: […]
>> GTK is great as a GUI toolkit especially with the use of CSS for styling, UI markup/xml/json-like support and modern smart layouts. Very basic and flexible to powerful theming with CSS. Only issue is its not cross platform by design...and its C.
>
> Does it matter what language a library being used is written in as long as the binding/wrapper to D is a good quality one? GtkD is a great binding/wrapper to GTK created using the correct tools for creating binding/wrapper to a GObject- based library.
>
> Also of course D is supposed to be able to use C libraries without the masses
> of overhead that Rust requires.

 I would agree with Russel. Indeed we have some resource that maintains GtkD, it work well to create a D heavy application.

To my point of view the market is not bound to a D GUI. They are 2 two targets:

1/ light application so we need a killer framework "à la" jhipster (https://www.jhipster.tech)
This allow to create in less than 10 min minutes a three-tier architecture with these features: ready to be packaged (build script and dockerfile are generated), draw me your data I generate the code (uml to query), security ready (SSO technology are provided), database agnostics (choose cassandra, mysql, postgrsql, mongodb) I create the query for you.

2/ data scientist framework, python start to become famous around 2012 but its reputation grow hugely with the new frameworks around data analysis, mining and learning. Especially with tensorflow, pytorch and so on ...

D can be a player in this fields if we prowide such powerful framework easy to use for the end user. Or easy to use for a any developer in such case we need to look what it is done by Apache with yarn,parquet,spark,hbase ...

For me D can become a huge player with one or bih killer application in this two fields.

On Thursday, 17 October 2019 at 07:18:15 UTC, Russel Winder wrote:
> On Wed, 2019-10-16 at 21:20 +0000, aberba via Digitalmars-d wrote: […]
>> GTK is great as a GUI toolkit especially with the use of CSS for styling, UI markup/xml/json-like support and modern smart layouts. Very basic and flexible to powerful theming with CSS. Only issue is its not cross platform by design...and its C.
>
> Does it matter what language a library being used is written in as long as the binding/wrapper to D is a good quality one? GtkD is a great binding/wrapper to GTK created using the correct tools for creating binding/wrapper to a GObject- based library.
>
> Also of course D is supposed to be able to use C libraries without the masses
> of overhead that Rust requires.

 I would agree with Russel. Indeed we have some resource that maintains GtkD, it works well to create a D heavy application.

To my point of view, the market is not bound to a D GUI. They are 2 two targets:

1/ light application so we need a killer framework "à la" jhipster (https://www.jhipster.tech)
This allows to create in less than 10 min minutes a three-tier architecture with these features: ready to be packaged (build script and dockerfile are generated), draw me your data I generate the code (UML to query), security ready (SSO technology are provided), database agnostics (choose Cassandra, MySQL, PostgreSQL, MongoDB) I create the query for you.

2/ data scientist framework, python start to become famous around 2012 but its reputation grows hugely with the new frameworks around data analysis, mining and learning. Especially with Tensorflow, PyTorch and so on ...

D can be a player in these fields if we provide such powerful framework easy to use for the end-user. Or easy to use for by any developer in such case we need to look at what is done by Apache with yarn, parquet, spark, HBase ...

For me D can become a huge player with one or both killer applications in these two fields.