www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D is our last hope

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
Is there really any other language than D that can replace C++ 
and Rust?

Go is good, but very tedious to write.
Zig, Odin, Beef, V and Jai are not production ready (according to 
the creators themselves).


Forget about Java, Kotlin or whatever.



I don't think Rust is the answer, for many reasons.

Well, maybe Nim would actually be a serious alternative, however, 
I'm kinda used to the C-style.

Any feedback?
Nov 26 2023
next sibling parent reply Daniel N <no public.email> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


What's wrong with native kotlin?
Nov 26 2023
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 26 November 2023 at 18:23:13 UTC, Daniel N wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


 What's wrong with native kotlin?



too. Thanks for the tip though.
Nov 26 2023
prev sibling parent reply Kagamin <spam here.lot> writes:
On Sunday, 26 November 2023 at 18:23:13 UTC, Daniel N wrote:

 What's wrong with native kotlin?


It's in hybrid pascal family.
```
fun <T> Sequence<T>.chunked(size: Int): Sequence<List<T>>
```
Is Sequence its approach to slices?
Nov 27 2023
parent reply Daniel N <no public.email> writes:
On Monday, 27 November 2023 at 10:22:52 UTC, Kagamin wrote:

 On Sunday, 26 November 2023 at 18:23:13 UTC, Daniel N wrote:

 What's wrong with native kotlin?


 It's in hybrid pascal family.
 ```
 fun <T> Sequence<T>.chunked(size: Int): Sequence<List<T>>
 ```
 Is Sequence its approach to slices?


Well...
```kotlin
val array = arrayOf(1, 2, 3, 4, 5, 6, 7, 8, 9)
val slice = array.sliceArray(0..3)
```

But check this sugar
https://kotlinlang.org/docs/lambdas.html#it-implicit-name-of-a-single-parameter

```kotlin
val sequenceResult = sequenceOf(1, 2, 3, 4, 5)
     .filter { it % 2 == 0 }
     .map { it * 2 }
     .toList()
```
Nov 27 2023
parent Kagamin <spam here.lot> writes:
```
public fun ByteArray.sliceArray(indices: IntRange): ByteArray {
     if (indices.isEmpty()) return ByteArray(0)
     return copyOfRange(indices.start, indices.endInclusive + 1)
}
```
Is this accurate? copyOfRange?
Nov 27 2023
prev sibling next sibling parent Dmitry Ponyatov <dponyatov gmail.com> writes:
 Is there really any other language than D that can replace C++ 
 and Rust?


It depends on what exactly you want to replace, and how large 
free computing resources you have to run JIT or incremental 
compilation into memory in runtime.

As an example, Julia was noted as a thing able to use compile&run 
model, with lot of code optimizations via LLVM.

Or maybe it can be not a language, but a large kit of top-level 
components for fast building of DSL compilers (something like 
metacompiler that provides a special language and tools for 
making arbitrary compilers).
Nov 26 2023
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


I'm in the same boat as you. I have tried several languages 
besides C++ and D but have been anything I digested with please. 
C++ is on its last legs now as I see it (it will not go away 
because of the huge code base but new projects I should certainly 
check out other languages and you should too) and D it is almost 
the only escape route right now.

This is why it is sometimes to painful to read this forum because 
D is a nice language but needs to be continued and adapted, 
memory management is one of them for example.

I've tried Nim but it is not better than D. Meta programming with 
Nim is more difficult and annoying than meta programming in C++. 
The syntax is tedious when you get into some serious programming.

There is one programming language that I like and that is Swift. 
Meta programming doesn't exist and generics isn't fully supported 
yet. In general though I like the language, it is what Rust 
should have been. The problem Swift is developed by Apple for 
Apple which means that other platforms are a bit behind. Also the 
performance isn't there yet, it is usually behind C++, Rust, D, 
Nim etc.
Nov 26 2023
parent sighoya <sighoya gmail.com> writes:
On Sunday, 26 November 2023 at 20:47:50 UTC, IGotD- wrote:

 There is one programming language that I like and that is 
 Swift. Meta programming doesn't exist and generics isn't fully 
 supported yet.


They have macros now as preview, but they are definitely coming.
Nov 26 2023
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?
 ...


Just testing, because suddenly my last post requires moderation 
even I don't even post a lot.

Matheus.
Nov 26 2023
parent matheus <matheus gmail.com> writes:
On Sunday, 26 November 2023 at 23:12:29 UTC, matheus wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?
 ...


 Just testing, because suddenly my last post requires moderation 
 even I don't even post a lot.

 Matheus.


Hmm I think my post have been flagged. Let's try another time, 
changing some words.


 Is there really any other language than D that can replace C++ 
 and Rust?
 ...


Serious question: Is C ++ still a thing?

I mean despite of some n.i.che (OS, Games!?) I barely see people 
talking about writing software in this language.


J.a.v.a and P.y.t.h.on, I barely see for C ++, only if a really 
look for it.

Matheus.
Nov 26 2023
prev sibling next sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?



A D developer/supporter, when having discussions about Rust, Zig, 
Odin, Go, etc... are going to include D in the conversation as 
well.

Sadly, a developer of the other said languages are unlikely to 
include D in theirs.

To me - this is the reality.

It is probably strong words to suggest that the D language has an 
identity crisis - but I don't think many people include D in the 
discussion of these languages because it is hard to tell :-

Is it a competitor of C++       ?

Oh.. is is a competitor of Rust ?

D can support so many ways to solve a problem. I believe the 
impression people have is that it is always trying to move the 
goal posts. What is the target audience, here?


I am at an age now where I cannot be bothered to learn a new 
language. Maybe I just have "learning new language fatigue" - if 
that is a thing. Apparently Rust has a bit of a learning curve. I 
looked at Zig and just lost interest. This is why I liked D in 


I have, however, played with Odin and I do like it. I am 
seriously thinking of using it if I build a game in future. Odin 
goals are laid out plain and simple - what it will be and what it 
wont. Very straight forward. I think Jai will be similar.

Just my thoughts. Dlang, I think, goes in the same category as
Nov 27 2023
next sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Monday, 27 November 2023 at 13:08:18 UTC, Martyn wrote:

 ...
 ...
 Just my thoughts. Dlang, I think, goes in the same category as 



I accidentally hit send.



I think that depends on what you are trying to do.
Depending on what it is you are doing, alternatives could be Go, 
Dart, Kotlin, or to some degree.... node. (please dont throw 
stones at me!)

Of course - we also have D.
Nov 27 2023
parent reply Kagamin <spam here.lot> writes:
On Monday, 27 November 2023 at 13:31:31 UTC, Martyn wrote:

 Depending on what it is you are doing, alternatives could be 
 Go, Dart, Kotlin, or to some degree.... node.


It's a quite asinine myth that you need to learn a new language 
for every program you write. Coincidentally today languages tend 
to compete everywhere from native to web and kernels.
Nov 27 2023
parent reply Martyn <martyn.developer googlemail.com> writes:
On Monday, 27 November 2023 at 16:11:34 UTC, Kagamin wrote:

 On Monday, 27 November 2023 at 13:31:31 UTC, Martyn wrote:

 Depending on what it is you are doing, alternatives could be 
 Go, Dart, Kotlin, or to some degree.... node.


 ...
 It's a quite asinine myth that you need to learn a new language 
 for every program you write.
 ...


It was not my intention for my comment to come across this way. 
Some languages are generally suited for certain things but not 
others. I mean, I know there has been a comment from someone on 
here saying that D is great for server-side/background programs 
but **** for client/frontend.

Of course, there are languages that are doing well for most types 

suggested, they are just that.. but if you already know or good
Nov 28 2023
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 28 November 2023 at 09:17:57 UTC, Martyn wrote:

 It was not my intention for my comment to come across this way. 
 Some languages are generally suited for certain things but not 
 others. I mean, I know there has been a comment from someone on 
 here saying that D is great for server-side/background programs 
 but **** for client/frontend.


I use D for both regularly and don't see any obvious preference.
Nov 28 2023
parent Kagamin <spam here.lot> writes:
My recent project is gitlab automerger that automates its asinine 
branch-commit-request-merge workflow so that I don't see its 
humongous web 2.0 interface.
Nov 28 2023
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 27 November 2023 at 13:08:18 UTC, Martyn wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 [...]



 A D developer/supporter, when having discussions about Rust, 
 Zig, Odin, Go, etc... are going to include D in the 
 conversation as well.

 [...]


Personally I think D could be really great if just a little more 
attention would be given to the ecosystem and tooling.
Nov 28 2023
parent reply DrDread <DrDread cheese.com> writes:
On Tuesday, 28 November 2023 at 15:17:50 UTC, Imperatorn wrote:

 On Monday, 27 November 2023 at 13:08:18 UTC, Martyn wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 [...]



 A D developer/supporter, when having discussions about Rust, 
 Zig, Odin, Go, etc... are going to include D in the 
 conversation as well.

 [...]


 Personally I think D could be really great if just a little 
 more attention would be given to the ecosystem and tooling.


why don't you start giving it the attention then?
Nov 28 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Tuesday, 28 November 2023 at 15:19:25 UTC, DrDread wrote:

 why don't you start giving it the attention then?


I tried, but after they broke my code for the tenth time I 
relaised that I'm putting much too effor into something nobody 
gives a pig's arse about.

And it's not like building tools/3rd party for D is a good idea 
anyway. Since the language can't decide what it wants to be, and 
you end up having to either overengineer your code, either listen 
to a lot of complaints how your code is unsupported in certain 
cases.
Dec 04 2023
next sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Monday, 4 December 2023 at 09:31:16 UTC, GrimMaple wrote:

 On Tuesday, 28 November 2023 at 15:19:25 UTC, DrDread wrote:

 why don't you start giving it the attention then?


 I tried, but after they broke my code for the tenth time I 
 relaised that I'm putting much too effor into something nobody 
 gives a pig's arse about.

 And it's not like building tools/3rd party for D is a good idea 
 anyway. Since the language can't decide what it wants to be, 
 and you end up having to either overengineer your code, either 
 listen to a lot of complaints how your code is unsupported in 
 certain cases.


My solution was simply just sticking to what you're doing and 
what you're gonna use. If the case falls out over my usage, I 
simply don't implement since I don't have infinite time. If 
someday we reach the level where people are willing to help make 
it more compatible, then, we can accept, while that does not 
happen, just focusing on our own projects should be more than 
enough. I don't want to implement a feature for people which I 
know that after 1 week they're just going over on other thing 
anyway.
Dec 05 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Tuesday, 5 December 2023 at 18:42:13 UTC, Hipreme wrote:

 My solution was simply just sticking to what you're doing and 
 what you're gonna use.


I'm sorry, but this is exactly the issue OP was talking about. 
When everyone is "just sticking to what they're doing", you can't 
get tooling/3rdparty going. It needs to be a collective effort of 
sorts. And unless there is collective effort, there never will be 
enough 3rdparty to make D viable for most people.


 If the case falls out over my usage, I simply don't implement 
 since I don't have infinite time.


Contrary, what I've tried to say was: it's extremely difficult 
(in D) to implement a "good for everyone" solution, because the 
language contradicts itself. If you design a ` nogc` library, 
then GC people are left out. If you design a GC library, then 
` nogc` users are left out. And yes, I'm aware of templates and 
metaprogramming, but the code becomes a mess if you try to keep 
your stuff double-ended.

And then you have `worseD` users, they don't have half of the 
language available. What should you, as a framework designer, do? 
Ignore them? Then you get a lot of complaints how "there is no 
good framework for X. This one doesn't support betterC". And if 
you design your library for use with `worseD`, you're left out 
with basically C on steroids. No GC, half of std, etc.

As a result, the already scarce D programming force is scattered 
around projects that do essentially the same but with some unique 
subset of D.
Dec 05 2023
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:

 worseD
 half the std


I feel like the big thing is that slices depend on gc, and if you 
dont have slices how exactly can you use all the algorithms 
which, oh yeah, like to try to make ranges of dchar if you use 
any char then which wont be fitting in whatever you allocated

not the std; most of the std isnt relivent
Dec 05 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Wed, Dec 06, 2023 at 01:42:02AM +0000, monkyyy via Digitalmars-d wrote:

 On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:

 worseD
 half the std


 
 I feel like the big thing is that slices depend on gc, and if you dont
 have slices how exactly can you use all the algorithms which, oh yeah,
 like to try to make ranges of dchar if you use any char then which
 wont be fitting in whatever you allocated


[...]

This is wrong, slices do not depend on gc.  *Appending* to slices does
(because you have to allocate memory to store the result), but you can
pass slices around  nogc code no problem. Taking slices of an existing
array (which need not be GC-allocated) is also  nogc. In fact, most of
std.algorithm, std.range, can be used with  nogc, the primary blocker
there is Exceptions which are GC-allocated.

(Incidentally this is why there was talk about  nogc Exceptions a while
back, the idea being that once we get rid of GC dependency for
Exception, then basically all of std.algorithm and std.range would be
usable in  nogc.)


T

-- 
Let X be the set not defined by this sentence...
Dec 05 2023
next sibling parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 6 December 2023 at 02:32:20 UTC, H. S. Teoh wrote:
[...]

 (Incidentally this is why there was talk about  nogc Exceptions 
 a while back, the idea being that once we get rid of GC 
 dependency for Exception, then basically all of std.algorithm 
 and std.range would be usable in  nogc.)


The exception itself doesn't need to be GC allocated and this 
already kinda works with some limitations (not good enough for 
Phobos, but maybe usable for the other  nogc use cases). This 
reminds me of 
https://forum.dlang.org/post/kjkjagzrengbynkoffgy forum.dlang.org
Dec 05 2023
prev sibling parent IGotD- <nise nise.com> writes:
On Wednesday, 6 December 2023 at 02:32:20 UTC, H. S. Teoh wrote:

 This is wrong, slices do not depend on gc.  *Appending* to 
 slices does (because you have to allocate memory to store the 
 result), but you can pass slices around  nogc code no problem. 
 Taking slices of an existing array (which need not be 
 GC-allocated) is also  nogc. In fact, most of std.algorithm, 
 std.range, can be used with  nogc, the primary blocker there is 
 Exceptions which are GC-allocated.

 (Incidentally this is why there was talk about  nogc Exceptions 
 a while back, the idea being that once we get rid of GC 
 dependency for Exception, then basically all of std.algorithm 
 and std.range would be usable in  nogc.)


 T


True but D has this duality between slices and dynamic arrays and 
they are sometimes hard to distinguish and there can be 
allocations underneath when you least expect it.

For me the problem with D isn't really GC but rather the type of 
GC. For embedded systems memory allocations are fine but the huge 
amount of instrumentation in order to get the GC to work is 
unacceptable (stopping threads, reading registers, reading TLS 
etc). The default GC is also too old and not up to the task for a 
modern desktop/laptop/server computer systems. D was created when 
dual core processors was the coolest thing for desktops. Now 
normal computers have up to 32 cores and multithreading is more 
common. Stopping 32+ threads takes time as is a really ugly 
approach. Therefore D needs to evolve in order to accommodate for 
a more variety of GC types and not only the stop the world type. 
Now it only supports one GC type which is a design error built 
into the language/library.

Honestly, I couldn't care less about  nogc even if I'm doing 
embedded systems. The embedded systems that are so memory 
constrained that you have avoid do memory allocations, then 
better C or C alone is the obvious choice for those systems, not 
using the D library at all.
Dec 06 2023
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:


 Contrary, what I've tried to say was: it's extremely difficult 
 (in D) to implement a "good for everyone" solution, because the 
 language contradicts itself. If you design a ` nogc` library, 
 then GC people are left out. If you design a GC library, then 
 ` nogc` users are left out. And yes, I'm aware of templates and 
 metaprogramming, but the code becomes a mess if you try to keep 
 your stuff double-ended.


Just ignore those nitpicking. They're not going to use it anyway. 
VS code for D got a lot of that till it eventually became the 
defacto code editor. Vibe.d has also gotten a lot of such. It 
works just fine for me being web developer. You simply can't 
satisfy everyone.

Nitpicking is almost unavoidable.
Dec 06 2023
prev sibling next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:

 If you design a ` nogc` library, then GC people are left out.


Is this actually true? My understanding is that ` nogc` code 
fragments can be called from the GC code just fine. Though some 
problems may arise with callback functions or delegates/closures 
here and there. An example of ` nogc` induced friction:

```D
import std;
void main() {
   auto a = new BigInt[](100);
   a[] = BigInt(1);  // works fine
   a[] += BigInt(1); // Error: ` nogc` function 
`core.internal.array.operations.arrayOp!
                     // (BigInt[], BigInt, "+=").arrayOp` cannot 
call non- nogc function
                     // `std.bigint.BigInt.opOpAssign!("+", 
BigInt).opOpAssign`
}
```

Or do you mean that manual dynamic memory allocation/deallocation 
in the ` nogc` library can make things much more complicated? But 
if a ` nogc` library never exposes manually allocated memory 
slices to its API users, then everything is fine. In fact, 
various C libraries (such as glibc, zlib, sqlite) are all 
effectively ` nogc` and they can be used from D code.
Dec 07 2023
next sibling parent Dennis <dkorpel gmail.com> writes:
On Thursday, 7 December 2023 at 10:08:14 UTC, Siarhei Siamashka 
wrote:

 Though some problems may arise with callback functions or 
 delegates/closures here and there. An example of ` nogc` 
 induced friction:


This seems to be an issue with the `arrayOp` template being 
annotated with function attributes. Filed as: 
https://issues.dlang.org/show_bug.cgi?id=24272
Dec 07 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Thursday, 7 December 2023 at 10:08:14 UTC, Siarhei Siamashka 
wrote:

 Is this actually true? My understanding is that ` nogc` code 
 fragments can be called from the GC code just fine. Though some 
 problems may arise with callback functions or 
 delegates/closures here and there.


I would've lied if I said you can't use ` nogc` code in GC code. 
But in a reasonably sized framework (eg UI framework) ` nogc` 
will start bringing in too much issues eventually. Delegates is 
just one of the things where ` nogc` issues are apparent. If you 
want to have a ` nogc` control in a UI framework and have 
callbacks/events in it, you are going to force the user of that 
control to use ` nogc` code.

The less apparent issue with ` nogc` are interfaces\subclasses. 
If you have a ` nogc` in your interface, you're kind of forcing 
` nogc` onto all of the users of that interface:

```d
interface A
{
     void a()  nogc;
}

class B : A
{
     void a() { writeln("b"); } // Oops -- a() is  nogc
}
```


 Or do you mean that manual dynamic memory 
 allocation/deallocation in the ` nogc` library can make things 
 much more complicated?


This is probably the least of my concerns, because


 But if a ` nogc` library never exposes manually allocated 
 memory slices to its API users, then everything is fine. In 
 fact, various C libraries (such as glibc, zlib, sqlite) are all 
 effectively ` nogc` and they can be used from D code.


that only works if you don't have any reasonably complex 
inheritance structure in your code. If you have subclasses and 
stuff, this manually allocated stuff becomes almost impossible to 
reasonabley control from either side.
Dec 07 2023
next sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 7 December 2023 at 19:01:26 UTC, GrimMaple wrote:

 Delegates is just one of the things where ` nogc` issues are 
 apparent. If you want to have a ` nogc` control in a UI 
 framework and have callbacks/events in it, you are going to 
 force the user of that control to use ` nogc` code.


I write code without GC and don't annotate anything with ` nogc` 
and don't use betterC, things work better that way.
Dec 07 2023
parent Kagamin <spam here.lot> writes:
Wait, this means D is great by default. The more you overengineer 
the worse you make it.
Dec 07 2023
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Thursday, 7 December 2023 at 19:01:26 UTC, GrimMaple wrote:

 If you want to have a ` nogc` control in a UI framework and 
 have callbacks/events in it, you are going to force the user of 
 that control to use ` nogc` code.


A similar problem happens when ` safe` code calls ` system` 
callbacks. I recommend to make the callback setter to be declared 
` system` and then cast it to ` safe`, so if something goes 
wrong, it's not your mistake.
Dec 11 2023
parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Monday, 11 December 2023 at 09:08:25 UTC, Kagamin wrote:

 On Thursday, 7 December 2023 at 19:01:26 UTC, GrimMaple wrote:

 If you want to have a ` nogc` control in a UI framework and 
 have callbacks/events in it, you are going to force the user 
 of that control to use ` nogc` code.


 A similar problem happens when ` safe` code calls ` system` 
 callbacks.


You can have ` trusted` callbacks in this case. It's just a 
matter of adding this attribute to each function after making an 
effort to attest that the function looks bug free despite using 
dangerous language features. Whereas the actual GC code can't 
just magically become ` nogc` if it actually relies on the 
garbage collector.


 I recommend to make the callback setter to be declared 
 ` system` and then cast it to ` safe`, so if something goes 
 wrong, it's not your mistake.


I'm not sure if I understand your suggestion correctly. If 
something goes wrong because you did something fishy, then it's 
probably your mistake after all.
Dec 11 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/7/2023 11:01 AM, GrimMaple wrote:

 Delegates is just one of the things where ` nogc` issues 
 are apparent. If you want to have a ` nogc` control in a UI framework and have 
 callbacks/events in it, you are going to force the user of that control to use 
 ` nogc` code.


A delegate will use the GC if both these conditions apply:

1. it references variables in the function it is enclosed by

2. the delegate escapes the context of that function, i.e. it outlives the 
lifetime of that function, so its stack frame no longer exists. In that case, 
the compiler will allocate that function's stack frame using the GC.

To avoid this, do one of:

1. capture the values from the enclosed variables, rather than simply referring 
to them

2. don't use the delegate in such a way that it outlives the function it is 
nested inside
Dec 19 2023
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:

 Contrary, what I've tried to say was: it's extremely difficult 
 (in D) to implement a "good for everyone" solution, because the 
 language contradicts itself. If you design a ` nogc` library, 
 then GC people are left out. If you design a GC library, then 
 ` nogc` users are left out.


If you design a Qt library, then GTK people are left out. There's 
no solution, only tradeoffs. You commit the nirvana fallacy. It's 
useless to complain that nirvana doesn't exist, of course it 
doesn't and never did.
Dec 08 2023
prev sibling next sibling parent reply Hors <q q.com> writes:
On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:

 Contrary, what I've tried to say was: it's extremely difficult 
 (in D) to implement a "good for everyone" solution


This is one of biggest mistakes in dlang's design. They tried to 
be "everything" (being both garbage collected and not, being both 
safe and unsafe system language...), it backfired because as you 
said, you always need to exclude some people or features.
IMO dlang needs to be splitted into two different languages one 
for system and one for general-purpose safe language, but then 
this means a breaking change to simply every existing D project.
Dec 08 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Friday, 8 December 2023 at 09:06:34 UTC, Hors wrote:

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, being 
 both safe and unsafe system language...), it backfired because 
 as you said, you always need to exclude some people or features.


I couldn't agree more. D needs to pick its poison :)


 IMO dlang needs to be splitted into two different languages one 
 for system and one for general-purpose safe language, but then 
 this means a breaking change to simply every existing D project.


I don't think there is enough people interested in a high level 
language in the D community. If anything, I see D becoming more 
and more of a system language over time.
Therefore, I am *thiiiiiiiiiiis* close to just forking it and 
tweaking it to be more high-level language. I'm mostly stopped by 
needing to write code completion though
Dec 08 2023
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 8 December 2023 at 13:27:46 UTC, GrimMaple wrote:

 On Friday, 8 December 2023 at 09:06:34 UTC, Hors wrote:

 I couldn't agree more. D needs to pick its poison :)


I thought we're way past that decision after 10yrs. I doubt D is 
changing to anything other than what it is now. The language is 
mature and set. It's already being used put there.
Dec 10 2023
parent Hors <ho rs.com> writes:
On Sunday, 10 December 2023 at 10:34:37 UTC, aberba wrote:

 On Friday, 8 December 2023 at 13:27:46 UTC, GrimMaple wrote:

 On Friday, 8 December 2023 at 09:06:34 UTC, Hors wrote:

 I couldn't agree more. D needs to pick its poison :)


 I thought we're way past that decision after 10yrs. I doubt D 
 is changing to anything other than what it is now. The language 
 is mature and set. It's already being used put there.


I dont really agree with dlang already being used, we have a lot 
of dead libraries in DUB, and we hardly see new libraries comes 
into play. Also I dont think we should stick what d was 10 years 
ago, if we want to be success then we shoudln't be scared from 
changing.
Dec 11 2023
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 8 December 2023 at 13:27:46 UTC, GrimMaple wrote:

 On Friday, 8 December 2023 at 09:06:34 UTC, Hors wrote:

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, 
 being both safe and unsafe system language...), it backfired 
 because as you said, you always need to exclude some people or 
 features.


 I couldn't agree more. D needs to pick its poison :)


That D treats those two domains equally is supposed to be its 
unique selling point that no mainstream language does. I still 
fail to see why so many people pick D and then advocate for 
killing that fundamental feature. Aren't you excited about the 
thought that you can use one language to excel in both domains?


 IMO dlang needs to be splitted into two different languages 
 one for system and one for general-purpose safe language, but 
 then this means a breaking change to simply every existing D 
 project.


 I don't think there is enough people interested in a high level 
 language in the D community. If anything, I see D becoming more 
 and more of a system language over time.
 Therefore, I am *thiiiiiiiiiiis* close to just forking it and 
 tweaking it to be more high-level language. I'm mostly stopped 
 by needing to write code completion though


Consider the two probably biggest companies using D. Symmetry 
investments used D for high level purposes. Weka.io on the other 
hand vendors a file system, which is a systems langauge job. If 
we were to declare either domain a second class citizen, we have 
to anger one of those companies.
Dec 10 2023
next sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 11 December 2023 at 07:18:44 UTC, Dukc wrote:

 Symmetry investments used D for high level purposes.


Clarification: this is a typo. I meant "uses", not that Symmetry 
would have stopped using D.
Dec 11 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 11 December 2023 at 07:18:44 UTC, Dukc wrote:

 That D treats those two domains equally is supposed to be its 
 unique selling point that no mainstream language does. I still 
 fail to see why so many people pick D and then advocate for 
 killing that fundamental feature. Aren't you excited about the 
 thought that you can use one language to excel in both domains?


Actually, having written D full time for over 2 years now (I 
chose D for my indie game stuff), I don't really see D excelling 
in pretty much anything. The only stuff where I'd barely consider 
using D now is its `betterC` stuff where it at least does as 
advertised, and even then getting C dependencies is problematic 
enough that I'd rather just use C in the first place. High level 

where I need to be faster, even though the actual code writing is 
slightly slower. D has the potential to match it, but it all 
boils down to the lack of sane 3rd party libraries. Dub is a 
graveyard at this point. And when you have to reinvent the wheel 
all the time, it wears you down very quickly.


 Consider the two probably biggest companies using D. Symmetry 
 investments used D for high level purposes. Weka.io on the 
 other hand vendors a file system, which is a systems langauge 
 job. If we were to declare either domain a second class 
 citizen, we have to anger one of those companies.


I would've definitely rephrased that to `Consider the two 
probably **only** companies using D`. I'm sorry, but this point 
is laughable, considering how many companies **ditched** D in 
comparison. Yeah, those two (and some more) are using D. But how 
many have moved on? Take a look at "D Success Stories" page, you 
will find that most of the corps listed there stopped using D a 
while back.
Dec 11 2023
next sibling parent bachmeier <no spam.net> writes:
On Monday, 11 December 2023 at 18:28:10 UTC, GrimMaple wrote:


 Actually, having written D full time for over 2 years now (I 
 chose D for my indie game stuff), I don't really see D 
 excelling in pretty much anything. The only stuff where I'd 
 barely consider using D now is its `betterC` stuff where it at 
 least does as advertised, and even then getting C dependencies 
 is problematic enough that I'd rather just use C in the first 
 place.


I guess everyone has their own story, but it's hard to understand 
what's difficult about using D to access C dependencies in 2023. 
That's been my use case for a decade and I have no desire to move 
to anything else. C compiler extensions and the preprocessor get 
in the way from time to time, but you just have to deal with that 
crap when you're working with C.
Dec 11 2023
prev sibling parent reply Hipreme <msnmancini hotmail.com> writes:
On Monday, 11 December 2023 at 18:28:10 UTC, GrimMaple wrote:

 On Monday, 11 December 2023 at 07:18:44 UTC, Dukc wrote:

 That D treats those two domains equally is supposed to be its 
 unique selling point that no mainstream language does. I still 
 fail to see why so many people pick D and then advocate for 
 killing that fundamental feature. Aren't you excited about the 
 thought that you can use one language to excel in both domains?


 Actually, having written D full time for over 2 years now (I 
 chose D for my indie game stuff), I don't really see D 
 excelling in pretty much anything. The only stuff where I'd 
 barely consider using D now is its `betterC` stuff where it at 
 least does as advertised, and even then getting C dependencies 
 is problematic enough that I'd rather just use C in the first 
 place. High level stuff though... Yeah, D goes straight into 

 actual code writing is slightly slower. D has the potential to 
 match it, but it all boils down to the lack of sane 3rd party 
 libraries. Dub is a graveyard at this point. And when you have 
 to reinvent the wheel all the time, it wears you down very 
 quickly.


 Consider the two probably biggest companies using D. Symmetry 
 investments used D for high level purposes. Weka.io on the 
 other hand vendors a file system, which is a systems langauge 
 job. If we were to declare either domain a second class 
 citizen, we have to anger one of those companies.


 I would've definitely rephrased that to `Consider the two 
 probably **only** companies using D`. I'm sorry, but this point 
 is laughable, considering how many companies **ditched** D in 
 comparison. Yeah, those two (and some more) are using D. But 
 how many have moved on? Take a look at "D Success Stories" 
 page, you will find that most of the corps listed there stopped 
 using D a while back.



I still think that D's problem is how much work a single person 
needs to do.
Right now, I'll list projects that I'm maintaining that was 
supposed to be unrelated to my project:

- GLES Binding
- Metal Binding
- DirectX binding
- A custom runtime for being able to use real D on WASM
- OpenSL ES binding
- AVAudioEngine binding
- A custom build tool because `dub` is far from being enough to 
my purpose
- Windowing libraries because when I started it, I didn't knew 
about adam's simpledisplay
- Even JSON I had to reimplement, since the implementations I 
tested bring features which I don't have in my custom runtime, D 
code just seem to depend on everything, always.



Beyond that, I have forfeit:

- Phobos usage, since it is not portable enough for me, it breaks 
on releases, and it makes your compilation time go down a lot
- Code completion (I don't remember when it worked again on 
Windows)
- Go-to definition (yes, it is simply faster to just try to 
memorize in which file something was defined)
- Using C dependencies: this is more of a C problem, but I really 
find it hard to manage multiple dependencies from C with D, and 
this should be easier since this is what the language sells


Most of the problems we have is the lack of existing work. D's 
std coverage is very good, but has this big problem which is a 
lot more of a concern when you're not using it as a script.

I'm not that unhappy with D, but it is quite exhausting to beyond 
having to develop your project, develop the tools for helping you 
develop the project.
Dec 11 2023
next sibling parent reply Bradley Chatha <sealabjaster gmail.com> writes:
On Monday, 11 December 2023 at 20:29:36 UTC, Hipreme wrote:

 Most of the problems we have is the lack of existing work. D's 
 std coverage is very good, but has this big problem which is a 
 lot more of a concern when you're not using it as a script.

 I'm not that unhappy with D, but it is quite exhausting to 
 beyond having to develop your project, develop the tools for 
 helping you develop the project.



of libraries for things like Databases+ORMs, high performing 
(excluding Python) and well documented frameworks for things like 
web APIs or even server side rendering, and also easy just-works 
SDKs to access modern application development platforms (AWS; 
GCP, Azure if you're unfortunate enough), and so on.

When you don't have an easy to access, plug-and-play solution to 
access these external resources, for developers to tinker around 
with and prototype ideas with, then effectively a ton of more 
casual developers will never really touch D.

With D you just have to do it all from scratch yourself: 
Something I'm very very very slowly making progress towards, but 
ultimately I understand it's almost pointless in the long run.

However for things that _do_ require you to make a lot of 
functionality from scratch, D definitely is pretty awesome to 
work with... if you have the time :(
Dec 11 2023
next sibling parent Hors <ho rs.com> writes:
On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha wrote:

 On Monday, 11 December 2023 at 20:29:36 UTC, Hipreme wrote:

 [...]



 wealth of libraries for things like Databases+ORMs, high 
 performing (excluding Python) and well documented frameworks 
 for things like web APIs or even server side rendering, and 
 also easy just-works SDKs to access modern application 
 development platforms (AWS; GCP, Azure if you're unfortunate 
 enough), and so on.

 [...]


It would be awesome if dlang improved interop with other 
languages, so you dont have to re-implement everything or use 
wrapper
Dec 12 2023
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha wrote:



 wealth of libraries for things like Databases+ORMs, high 
 performing (excluding Python) and well documented frameworks 
 for things like web APIs or even server side rendering, and 
 also easy just-works SDKs to access modern application 
 development platforms (AWS; GCP, Azure if you're unfortunate 
 enough), and so on.

 When you don't have an easy to access, plug-and-play solution 
 to access these external resources, for developers to tinker 
 around with and prototype ideas with, then effectively a ton of 
 more casual developers will never really touch D.


I suppose this is why my experience with D has been much better 
than reported by others. When I started, I was able to call into 
R for anything I needed, with no loss of efficiency. Need a 
database? It's there. Need a machine learning library like 
TensorFlow? It's there. Need parallel random number generation? 
It's there.

One of the things I've noticed is that - for reasons I'll never 
understand - most developers using D are not willing to do that. 
I understand that might not work for a commercial project, but if 
you just want to get work done, why not reuse the work that's 
been done for other languages?


 With D you just have to do it all from scratch yourself: 
 Something I'm very very very slowly making progress towards, 
 but ultimately I understand it's almost pointless in the long 
 run.


Well, yeah, it's pointless to reinvent the wheel if you don't 
have to. First get something that works. Then rewrite all the 
low-level stuff in D so it's more convenient/exactly the way you 
want/specialized to your use case.
Dec 12 2023
next sibling parent bachmeier <no spam.net> writes:
On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha 
 wrote:



 wealth of libraries for things like Databases+ORMs, high 
 performing (excluding Python) and well documented frameworks 
 for things like web APIs or even server side rendering, and 
 also easy just-works SDKs to access modern application 
 development platforms (AWS; GCP, Azure if you're unfortunate 
 enough), and so on.

 When you don't have an easy to access, plug-and-play solution 
 to access these external resources, for developers to tinker 
 around with and prototype ideas with, then effectively a ton 
 of more casual developers will never really touch D.


 I suppose this is why my experience with D has been much better 
 than reported by others. When I started, I was able to call 
 into R for anything I needed, with no loss of efficiency. Need 
 a database? It's there. Need a machine learning library like 
 TensorFlow? It's there. Need parallel random number generation? 
 It's there.


Just for the heck of it, I checked how hard it would be for me to 
access AWS services. I found this package: 
https://www.paws-r-sdk.com/ "Paws provides access to the full 
suite of AWS services from within R."
Dec 12 2023
prev sibling parent reply Hors <ho rs.com> writes:
On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha 
 wrote:


 [...]


 I suppose this is why my experience with D has been much better 
 than reported by others. When I started, I was able to call 
 into R for anything I needed, with no loss of efficiency. Need 
 a database? It's there. Need a machine learning library like 
 TensorFlow? It's there. Need parallel random number generation? 
 It's there.

 [...]


D is not the best when it comes to interop with other languages
Dec 13 2023
parent reply bachmeier <no spam.net> writes:
On Thursday, 14 December 2023 at 05:40:04 UTC, Hors wrote:

 On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha 
 wrote:


 [...]


 I suppose this is why my experience with D has been much 
 better than reported by others. When I started, I was able to 
 call into R for anything I needed, with no loss of efficiency. 
 Need a database? It's there. Need a machine learning library 
 like TensorFlow? It's there. Need parallel random number 
 generation? It's there.

 [...]


 D is not the best when it comes to interop with other languages


It's not terribly helpful to post something like that without 
elaborating. I've been doing that for ten years and it works 
great.
Dec 14 2023
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 14 December 2023 at 14:02:26 UTC, bachmeier wrote:

 On Thursday, 14 December 2023 at 05:40:04 UTC, Hors wrote:

 On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha 
 wrote:


 [...]


 I suppose this is why my experience with D has been much 
 better than reported by others. When I started, I was able to 
 call into R for anything I needed, with no loss of 
 efficiency. Need a database? It's there. Need a machine 
 learning library like TensorFlow? It's there. Need parallel 
 random number generation? It's there.

 [...]


 D is not the best when it comes to interop with other languages


 It's not terribly helpful to post something like that without 
 elaborating. I've been doing that for ten years and it works 
 great.


Sometimes I wonder how many of the D criticisms come from those 
who have been using the language for yrs in this community or 
have experience enough to make an informed critique.


 From my limited understanding, D allows nogc code, GC code, safe 
code, interop with many langs, etc. yet it's always not enough 
for some reason.

I wonder how many of those folks are really serious about using 
the language cus it *seems* to me that a lot of experienced D 
devs are quietly getting things done.


Is there something I'm missing?
Dec 16 2023
next sibling parent Abdulhaq <alynch4048 gmail.com> writes:
On Saturday, 16 December 2023 at 21:11:42 UTC, aberba wrote:

 On Thursday, 14 December 2023 at 14:02:26 UTC, bachmeier wrote:

 On Thursday, 14 December 2023 at 05:40:04 UTC, Hors wrote:

 On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha 
 wrote:


 [...]


 I suppose this is why my experience with D has been much 
 better than reported by others. When I started, I was able 
 to call into R for anything I needed, with no loss of 
 efficiency. Need a database? It's there. Need a machine 
 learning library like TensorFlow? It's there. Need parallel 
 random number generation? It's there.

 [...]


 D is not the best when it comes to interop with other 
 languages


 It's not terribly helpful to post something like that without 
 elaborating. I've been doing that for ten years and it works 
 great.


 Sometimes I wonder how many of the D criticisms come from those 
 who have been using the language for yrs in this community or 
 have experience enough to make an informed critique.


 From my limited understanding, D allows nogc code, GC code, 
 safe code, interop with many langs, etc. yet it's always not 
 enough for some reason.

 I wonder how many of those folks are really serious about using 
 the language cus it *seems* to me that a lot of experienced D 
 devs are quietly getting things done.


 Is there something I'm missing?


Well said
Dec 17 2023
prev sibling next sibling parent reply Hors <q q.com> writes:
On Saturday, 16 December 2023 at 21:11:42 UTC, aberba wrote:

 On Thursday, 14 December 2023 at 14:02:26 UTC, bachmeier wrote:

 On Thursday, 14 December 2023 at 05:40:04 UTC, Hors wrote:

 On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 On Monday, 11 December 2023 at 21:21:46 UTC, Bradley Chatha 
 wrote:


 [...]


 I suppose this is why my experience with D has been much 
 better than reported by others. When I started, I was able 
 to call into R for anything I needed, with no loss of 
 efficiency. Need a database? It's there. Need a machine 
 learning library like TensorFlow? It's there. Need parallel 
 random number generation? It's there.

 [...]


 D is not the best when it comes to interop with other 
 languages


 It's not terribly helpful to post something like that without 
 elaborating. I've been doing that for ten years and it works 
 great.


 Sometimes I wonder how many of the D criticisms come from those 
 who have been using the language for yrs in this community or 
 have experience enough to make an informed critique.


 From my limited understanding, D allows nogc code, GC code, 
 safe code, interop with many langs, etc. yet it's always not 
 enough for some reason.

 I wonder how many of those folks are really serious about using 
 the language cus it *seems* to me that a lot of experienced D 
 devs are quietly getting things done.


 Is there something I'm missing?


How many is "a lot" actually, we literally only have two 
sponsors, many of dead projects in DUB and hardly seeing new 
projects registered (only to get abandoned after a few months or 
even a few weeks). Also telling they get the job done "quietly", 
are you trying to hide the fact dlang is nearly dead and say 
"they just do it quietly", Dlang's libraries are really limited, 
you either have to write from scratch, or interop with another 
language (which will usually require to write some bridge code by 
hand)


 I wonder how many of those folks are really serious about using 
 the language


Are you telling me I'm not even serious about using the language? 
Then why I'm even writing here?

My goal is not calling dlang is bad, but I think potential of 
dlang is being wasted, that's why I am writing here.

The gap of system programming is already filled with Zig, C, C++ 
and Rust. Making a mixed programming language of system and 
general-purpose just means the language is not a system language 
nor a general purpose language, dlang have to select a side, no 
language can be used everywhere.
Dec 17 2023
parent reply bachmeier <no spam.net> writes:
On Sunday, 17 December 2023 at 12:32:13 UTC, Hors wrote:


 How many is "a lot" actually, we literally only have two 
 sponsors, many of dead projects in DUB and hardly seeing new 
 projects registered (only to get abandoned after a few months 
 or even a few weeks).


There are only two kinds of languages: the ones with many dead 
projects and the ones nobody use.


 Also telling they get the job done "quietly", are you trying to 
 hide the fact dlang is nearly dead


It doesn't add anything to the conversation to make ridiculous 
claims like this with no evidence. Calling D "nearly dead" 
indicates you're not making a good faith effort to participate in 
a discussion.


 and say "they just do it quietly", Dlang's libraries are really 
 limited, you either have to write from scratch, or interop with 
 another language (which will usually require to write some 
 bridge code by hand)


You weren't using Python in the 1990s. You couldn't do a heck of 
a lot with it. Someone spent a lot of time writing a lot of 
libraries between then and now. They didn't post complaints, they 
wrote code. Then once they wrote all those libraries, other 
people used them.


 I wonder how many of those folks are really serious about 
 using the language


 Are you telling me I'm not even serious about using the 
 language? Then why I'm even writing here?

 My goal is not calling dlang is bad, but I think potential of 
 dlang is being wasted, that's why I am writing here.


What will help this language at this point is working on 
libraries, documentation, tutorials, etc.
Dec 18 2023
next sibling parent reply Hors <q q.com> writes:
On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:

 On Sunday, 17 December 2023 at 12:32:13 UTC, Hors wrote:


 How many is "a lot" actually, we literally only have two 
 sponsors, many of dead projects in DUB and hardly seeing new 
 projects registered (only to get abandoned after a few months 
 or even a few weeks).


 There are only two kinds of languages: the ones with many dead 
 projects and the ones nobody use.


 Also telling they get the job done "quietly", are you trying 
 to hide the fact dlang is nearly dead


 It doesn't add anything to the conversation to make ridiculous 
 claims like this with no evidence. Calling D "nearly dead" 
 indicates you're not making a good faith effort to participate 
 in a discussion.


 and say "they just do it quietly", Dlang's libraries are 
 really limited, you either have to write from scratch, or 
 interop with another language (which will usually require to 
 write some bridge code by hand)


 You weren't using Python in the 1990s. You couldn't do a heck 
 of a lot with it. Someone spent a lot of time writing a lot of 
 libraries between then and now. They didn't post complaints, 
 they wrote code. Then once they wrote all those libraries, 
 other people used them.


 I wonder how many of those folks are really serious about 
 using the language


 Are you telling me I'm not even serious about using the 
 language? Then why I'm even writing here?

 My goal is not calling dlang is bad, but I think potential of 
 dlang is being wasted, that's why I am writing here.


 What will help this language at this point is working on 
 libraries, documentation, tutorials, etc.


It's been +10 year and there's reasons why not many people wants 
to make libraries for Dlang. from GrimMaple's point:


 I would've lied if I said you can't use  nogc code in GC code. 
 But in a reasonably sized framework (eg UI framework)  nogc 
 will start bringing in too much issues eventually. Delegates is 
 just one of the things where  nogc issues are apparent. If you 
 want to have a  nogc control in a UI framework and have 
 callbacks/events in it, you are going to force the user of that 
 control to use  nogc code.

 The less apparent issue with  nogc are interfaces\subclasses. 
 If you have a  nogc in your interface, you're kind of forcing 
  nogc onto all of the users of that interface:


GrimMaple is the author of dlangui, and talking about why writing 
libraries in D is not a good experience.

 From me: all languages haves something to offer, like python is 
beginner friendly, C was the master of it's time, Rust allows you 
to write good performant and safe code. But I can't really see 
whats D has to offer, D has many features of course, but when you 
using libraries, you may need to throw away half of the D.

Another comment by GrimMaple:


 And it's not like building tools/3rd party for D is a good idea 
 anyway. Since the language can't decide what it wants to be, 
 and you end up having to either overengineer your code, either 
 listen to a lot of complaints how your code is unsupported in 
 certain cases.


GrimMaple here again talks about why writing libraries in D is 
not a good experience.
If you want developers to use and write libraries for your 
language, you need to have something good and stable to offer 
them.
Dec 18 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Monday, 18 December 2023 at 15:14:51 UTC, Hors wrote:

 GrimMaple is the author of dlangui, and talking about why 
 writing libraries in D is not a good experience.


Grim is the current maintainer of dlangui, but most the code was 
written by buggins, who I'd call the author.
Dec 18 2023
parent Hors <q q.com> writes:
On Monday, 18 December 2023 at 15:31:19 UTC, Adam D Ruppe wrote:

 On Monday, 18 December 2023 at 15:14:51 UTC, Hors wrote:

 GrimMaple is the author of dlangui, and talking about why 
 writing libraries in D is not a good experience.


 Grim is the current maintainer of dlangui, but most the code 
 was written by buggins, who I'd call the author.


well, thanks for correcting me
Dec 18 2023
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Monday, 18 December 2023 at 15:14:51 UTC, Hors wrote:

 On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:



 GrimMaple is the author of dlangui, and talking about why 
 writing libraries in D is not a good experience.


Seems you're quite relatively new here. DlangUI was authored by 
someone else. It doesn't look like it changed much since. But I'm 
glad he's keeping it alive. DlangUI is packed with features. If I 
had a $1m to spend on D, that's where it would go.

Its become obvious to me that a lot of D devs don't have interest 
in GUI apps, at least the kind that some would call a "real app". 
Those that do, know D enough to interop with C or c++ to use one 
of those toolkits. It could explain why projects like DlangUI, 
beamUI, and the others that got halfway there all didn't gain 
much adoption. You could argue none of them became stable enough 
to use. GUI toolkits are hard for an individual from what I 
understand.

With that said, we have...

* arsd.mingui by Adam which surprisingly is packed although it 
doesn't look pretty on Linux 😅

* gtk-d which I personally like since its native to Linux and can 
be styled to look great on Windows too.
![CSS styling 
gtkd](https://raw.githubusercontent.com/aberba/pos/master/screenshot.jpg?token=GHSAT0AAAAAACLTJEBLA7OGOIXBDEKYMRBEZMAXJRA)


D seems to be more popular for tooling, server-side web dev, and 
non-gui uses. I personally curious to know how people use D now. 
I haven't been active for the past 3yrs lol.


 Another comment by GrimMaple:


 And it's not like building tools/3rd party for D is a good 
 idea anyway. Since the language can't decide what it wants to 
 be, and you end up having to either overengineer your code, 
 either listen to a lot of complaints how your code is 
 unsupported in certain cases.


 GrimMaple here again talks about why writing libraries in D is 
 not a good experience.
 If you want developers to use and write libraries for your 
 language, you need to have something good and stable to offer 
 them.



GrimMaple seems like me from 4 yrs ago complaining about what I 
thought D needed to be lol. I've since moved on to contributing 
my fair share to increase adoption.
Dec 18 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:

 Also telling they get the job done "quietly", are you trying 
 to hide the fact dlang is nearly dead


 It doesn't add anything to the conversation to make ridiculous 
 claims like this with no evidence. Calling D "nearly dead" 
 indicates you're not making a good faith effort to participate 
 in a discussion.


I find it very funny how every time I ask anybody to show me any 
"real app" written in D (to prove that D isn't dead), nobody can 
do it. All I hear is "Symmetry this" and "Symmetry that". 
Sometimes DPlug comes by. But I still haven't seen any real life 
useful app being developed in D. Never. So it's always either 
Symmetry, either some rumors about some company allegedly using D 
back in 2015 to do something with no real proof that D is still 
there or it was used in the first place.

What is the point of a programming language? For me, it's to make 
software. If the software isn't being made - the language is dead.


 They didn't post complaints, they wrote code. Then once they 
 wrote all those libraries, other people used them.


For real? People complain about Python all the time. And because 
of those complaints something is being done about it. People 
complain because they care. When people stop complaining it's a 
telltale sign that they stopped caring (or left). Which is 
probably why you don't see a lot of complaints about D - because 
nobody is really writing D anyway. Every single person has left 
already.


 What will help this language at this point is working on 
 libraries, documentation, tutorials, etc.


I have been saying the same thing for a logn time now. But 
now-now, I say nobody will write libraries for a language that 
actively prevents you from writing libraries in the first place. 
Like, why do you expect someone to do their job when they 
**dare** to complain about stuff? The amount of times I've been 
told to "shut up and do it yourself" is seriously unacceptable. 
To a degree of being told "just fork the lang if you don't like 
it". This is no way to drive in contributors.

On Monday, 18 December 2023 at 15:14:51 UTC, Hors wrote:

 From me: all languages haves something to offer, like python is 
 beginner friendly, C was the master of it's time, Rust allows 
 you to write good performant and safe code. But I can't really 
 see whats D has to offer, D has many features of course, but 
 when you using libraries, you may need to throw away half of 
 the D.


Actually, over time, D became significantly lacking in features 
compared to other languages. The world has changed, and at this 
point in time, with Native AOT being a thing and producing 

me. And guess where I'm going to :)
Dec 18 2023
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Monday, 18 December 2023 at 15:48:02 UTC, GrimMaple wrote:

 On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:

 Also telling they get the job done "quietly", are you trying 
 to hide the fact dlang is nearly dead


 It doesn't add anything to the conversation to make ridiculous 
 claims like this with no evidence. Calling D "nearly dead" 
 indicates you're not making a good faith effort to participate 
 in a discussion.


 I find it very funny how every time I ask anybody to show me 
 any "real app" written in D (to prove that D isn't dead), 
 nobody can do it. All I hear is "Symmetry this" and "Symmetry 
 that". Sometimes DPlug comes by. But I still haven't seen any 
 real life useful app being developed in D. Never. So it's 
 always either Symmetry, either some rumors about some company 
 allegedly using D back in 2015 to do something with no real 
 proof that D is still there or it was used in the first place.


Here we go:
*) Vtube software - https://inochi2d.com/
*) Photo management software - https://aspect.bildhuus.com/
*) VST music things - https://www.auburnsounds.com/
*) OneDrive Linux client - https://abraunegg.github.io/
*) PasteBin "better" alternative - https://paste.myst.rs/

This is some big (with web-sites). Also Hipreme's game engine, a 
lot of stuff from Adam.
A bit outdated, but still relevant project from Netflix 
(vectorflow) and eBay(tsv-utils).
Dec 18 2023
parent reply Hors <q q.com> writes:
On Monday, 18 December 2023 at 16:30:23 UTC, Sergey wrote:

 On Monday, 18 December 2023 at 15:48:02 UTC, GrimMaple wrote:

 [...]


 Here we go:
 *) Vtube software - https://inochi2d.com/
 *) Photo management software - https://aspect.bildhuus.com/
 *) VST music things - https://www.auburnsounds.com/
 *) OneDrive Linux client - https://abraunegg.github.io/
 *) PasteBin "better" alternative - https://paste.myst.rs/

 This is some big (with web-sites). Also Hipreme's game engine, 
 a lot of stuff from Adam.
 A bit outdated, but still relevant project from Netflix 
 (vectorflow) and eBay(tsv-utils).


"A bit outdated" is very likely to mean they switched from D to 
another programming language or simply abandoned the project.

Tbh It's cool to see D has some uses, but why just "some" when 
clearly it has potential to be something bigger, thats why we 
complaint
Dec 18 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 18 December 2023 at 16:42:42 UTC, Hors wrote:


 Tbh It's cool to see D has some uses, but why just "some" when 
 clearly it has potential to be something bigger, thats why we 
 complaint


People have been proclaiming that D is dead or predicting its 
demise ever since I've been in the community. Twenty years later, 
it's still here, still evolving, the community is still slowly 
and steadily growing, and people are still getting work done with 
it.

There's nothing wrong with complaining. That's how things 
improve. But anyone interested in seeing the rate of growth and 
improvement pick up speed can publish blog articles about their 
projects and share them on social media, tweet regularly about 
what they're working on, show off their projects on YouTube, 
submit talks to tech conferences where it's appropriate to do so, 
talk to friends and colleagues about the joys of programming in 
D...

D isn't for everyone and never will be. Trying to make everyone 
happy is an exercise in futility. But the ones who for whom it 
does scratch that itch can do a lot of good just by telling the 
world about it. The more of us doing that, the better it will be 
for all of us.
Dec 18 2023
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 19 December 2023 at 01:48:57 UTC, Mike Parker wrote:

 Twenty years later, it's still here, still evolving, the 
 community is still slowly and steadily growing


How do you measure growth?
Dec 18 2023
parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 19 December 2023 at 02:39:16 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 01:48:57 UTC, Mike Parker wrote:

 Twenty years later, it's still here, still evolving, the 
 community is still slowly and steadily growing


 How do you measure growth?


New companies keep popping up using D, new users keep coming in 
through the Discord community and stick around over time, new 
contributors show up in the GitHub logs. It's slow, but 
perceptible.
Dec 18 2023
next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 19 December 2023 at 03:18:44 UTC, Mike Parker wrote:

 On Tuesday, 19 December 2023 at 02:39:16 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 01:48:57 UTC, Mike Parker 
 wrote:

 Twenty years later, it's still here, still evolving, the 
 community is still slowly and steadily growing


 How do you measure growth?


 New companies keep popping up using D, new users keep coming in 
 through the Discord community and stick around over time, new 
 contributors show up in the GitHub logs. It's slow, but 
 perceptible.


I saw one job listing this year.

Growth is more than just new people, it is more new people than 
those who leave, I would think d shrank this year compared to 
corona years when I picked it up. You can the github contributor 
list will only increase, that doesn't make it ok that there's no 
jobs.
Dec 18 2023
prev sibling parent reply Hors <q q.com> writes:
On Tuesday, 19 December 2023 at 03:18:44 UTC, Mike Parker wrote:

 On Tuesday, 19 December 2023 at 02:39:16 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 01:48:57 UTC, Mike Parker 
 wrote:

 Twenty years later, it's still here, still evolving, the 
 community is still slowly and steadily growing


 How do you measure growth?


 New companies keep popping up using D, new users keep coming in 
 through the Discord community and stick around over time, new 
 contributors show up in the GitHub logs. It's slow, but 
 perceptible.


new contributors show up, but are the old ones still work for 
improve D?
Dec 18 2023
parent reply Sergey <kornburn yandex.ru> writes:
On Tuesday, 19 December 2023 at 05:47:42 UTC, Hors wrote:

 On Tuesday, 19 December 2023 at 03:18:44 UTC, Mike Parker wrote:

 On Tuesday, 19 December 2023 at 02:39:16 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 01:48:57 UTC, Mike Parker 
 wrote:

 Twenty years later, it's still here, still evolving, the 
 community is still slowly and steadily growing


 How do you measure growth?


 New companies keep popping up using D, new users keep coming 
 in through the Discord community and stick around over time, 
 new contributors show up in the GitHub logs. It's slow, but 
 perceptible.


 new contributors show up, but are the old ones still work for 
 improve D?


https://www.youtube.com/watch?v=mpTBYiUSidA

Nice video about complaints :D
Dec 19 2023
parent reply Hors <q q.com> writes:
On Tuesday, 19 December 2023 at 13:02:29 UTC, Sergey wrote:

 On Tuesday, 19 December 2023 at 05:47:42 UTC, Hors wrote:

 On Tuesday, 19 December 2023 at 03:18:44 UTC, Mike Parker 
 wrote:

 On Tuesday, 19 December 2023 at 02:39:16 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 01:48:57 UTC, Mike Parker 
 wrote:

 Twenty years later, it's still here, still evolving, the 
 community is still slowly and steadily growing


 How do you measure growth?


 New companies keep popping up using D, new users keep coming 
 in through the Discord community and stick around over time, 
 new contributors show up in the GitHub logs. It's slow, but 
 perceptible.


 new contributors show up, but are the old ones still work for 
 improve D?


 https://www.youtube.com/watch?v=mpTBYiUSidA

 Nice video about complaints :D


how this is related to D
Dec 19 2023
parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 19 December 2023 at 13:25:56 UTC, Hors wrote:

 Nice video about complaints :D


 how this is related to D


Directly
Dec 19 2023
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Monday, 18 December 2023 at 15:48:02 UTC, GrimMaple wrote:

 On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:
 I find it very funny how every time I ask anybody to show me 
 any "real app" written in D (to prove that D isn't dead), 
 nobody can do it.


Maybe they're just ignoring your request, because as soon as 
"real" enters the discussion, you know everything being said is 
BS. In discussions of programming languages, real applications 
are what I write, toy applications are what everyone else writes.

All I have to do is open my computer to see it being used for 
real apps. I'm not going to waste my time telling you about it, 
because you'll dismiss it as a toy, and I won't get those five 
minutes back.
Dec 18 2023
next sibling parent Hors <q q.com> writes:
On Monday, 18 December 2023 at 16:44:38 UTC, bachmeier wrote:

 On Monday, 18 December 2023 at 15:48:02 UTC, GrimMaple wrote:

 On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:
 I find it very funny how every time I ask anybody to show me 
 any "real app" written in D (to prove that D isn't dead), 
 nobody can do it.


 Maybe they're just ignoring your request, because as soon as 
 "real" enters the discussion, you know everything being said is 
 BS. In discussions of programming languages, real applications 
 are what I write, toy applications are what everyone else 
 writes.

 All I have to do is open my computer to see it being used for 
 real apps. I'm not going to waste my time telling you about it, 
 because you'll dismiss it as a toy, and I won't get those five 
 minutes back.


Now calm urself down, you dont have any rights to insult people 
"they are not worth my time" just because they dont agree with 
you.
Dec 18 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Monday, 18 December 2023 at 16:44:38 UTC, bachmeier wrote:

 Maybe they're just ignoring your request, because as soon as 
 "real" enters the discussion, you know everything being said is 
 BS. In discussions of programming languages, real applications 
 are what I write, toy applications are what everyone else 
 writes.

 All I have to do is open my computer to see it being used for 
 real apps. I'm not going to waste my time telling you about it, 
 because you'll dismiss it as a toy, and I won't get those five 
 minutes back.


They are ignoring me because they know what I really mean. Just 
pointing a few projects isn't going to cut it, and people 
understand it. Obviously, even the most dead language in the 
world is going to have a few projects written in them. For any 
non-dead language the list should be miles long, as is the case 

`A bit outdated, but still relevant project` to name even 
hundreds of programs written in Kotlin, yet here it begins after 
naming just 5. Not to mention, that I contributed personally to 
several things off that list and have to keep a vectorflow fork 
up just to make it compile since original author won't accept PRs 
anymore ¯\_(ツ)_/¯

Also, I think D is the only language that needs to reassure its 
alive-ness by having "orgs using D" page (which in reality does 
even more harm than good, and it's kind of funny in its own way). 
I have never seen anything like that for other languages. Why 
don't we just admit that people are not really doing much with D 
and work on fixing it?

P.S. That "I've got to fix this myself because the original 
author isn't doing much themselves anymore" thing has happened to 
me so many times at this point that I'm genuinely sick of it.
Dec 18 2023
next sibling parent Hors <q q.com> writes:
On Monday, 18 December 2023 at 17:54:14 UTC, GrimMaple wrote:

 On Monday, 18 December 2023 at 16:44:38 UTC, bachmeier wrote:

 Maybe they're just ignoring your request, because as soon as 
 "real" enters the discussion, you know everything being said 
 is BS. In discussions of programming languages, real 
 applications are what I write, toy applications are what 
 everyone else writes.

 All I have to do is open my computer to see it being used for 
 real apps. I'm not going to waste my time telling you about 
 it, because you'll dismiss it as a toy, and I won't get those 
 five minutes back.


 They are ignoring me because they know what I really mean. Just 
 pointing a few projects isn't going to cut it, and people 
 understand it. Obviously, even the most dead language in the 
 world is going to have a few projects written in them. For any 
 non-dead language the list should be miles long, as is the case 

 to `A bit outdated, but still relevant project` to name even 
 hundreds of programs written in Kotlin, yet here it begins 
 after naming just 5. Not to mention, that I contributed 
 personally to several things off that list and have to keep a 
 vectorflow fork up just to make it compile since original 
 author won't accept PRs anymore ¯\_(ツ)_/¯

 Also, I think D is the only language that needs to reassure its 
 alive-ness by having "orgs using D" page (which in reality does 
 even more harm than good, and it's kind of funny in its own 
 way). I have never seen anything like that for other languages. 
 Why don't we just admit that people are not really doing much 
 with D and work on fixing it?

 P.S. That "I've got to fix this myself because the original 
 author isn't doing much themselves anymore" thing has happened 
 to me so many times at this point that I'm genuinely sick of it.


Some people wants to just make things stay how they want, while 
ignoring others. Of course this can never be case for real, no 
one is superior to me (and vice versa), my existence can't be 
ignored just because others don't agree with me.

And I am sure they will soon reply "Just quit D and use other 
languages", I am answering:
Of course it is easy to just switch language and never look back. 
if we discuss here, then we still care about D and hope to change 
things (in a good way), but of course some "superiors" here not 
wants that and tries making things harder (just to waste their 
and our time).
Dec 18 2023
prev sibling next sibling parent Sergey <kornburn yandex.ru> writes:
On Monday, 18 December 2023 at 17:54:14 UTC, GrimMaple wrote:

 Also, I think D is the only language that needs to reassure its 
 alive-ness by having "orgs using D" page (which in reality does 
 even more harm than good, and it's kind of funny in its own 
 way). I have never seen anything like that for other languages.


Let's go!

* https://ocaml.org/ - "Trusted by Industry Leaders"
* https://fsharp.org/- "Sponsor Members"
* https://dotnet.microsoft.com/en-us/languages/csharp - "Loved by 
developers, trusted by enterprise"
* https://www.rust-lang.org/ - "Rust in production"
* https://www.jetbrains.com/kotlin-multiplatform/ - "Real-world 
success stories"

It was fun, Grim, it was fun :)
Dec 18 2023
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 18 December 2023 at 17:54:14 UTC, GrimMaple wrote:

 They are ignoring me because they know what I really mean. Just 
 pointing a few projects isn't going to cut it, and people 
 understand it. Obviously, even the most dead language in the 
 world is going to have a few projects written in them.


You are exaggregating all the time. Langauge being dead means 
that no-one is using it. Think some academic research language 
that was used to write a proof of concept project by a few people 
and then everyone moved on. _That's_ what dead means. You can 
make a reasonable case that D has too little adoption and/or 
growth, but please call the problem that, and nothing else. 
Exaggregating the failings of the language serves only to make 
people annoyed and hence defensive.
Dec 19 2023
next sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Tuesday, 19 December 2023 at 12:58:16 UTC, Dukc wrote:

 You are exaggregating all the time. Langauge being dead means 
 that no-one is using it. Think some academic research language 
 that was used to write a proof of concept project by a few 
 people and then everyone moved on. _That's_ what dead means.


You're saying all this as if it's some kind of hidden truth and 
you're exsposing me or something, when it should be clear as day 
that I'm exaggerating. But I'm exaggerating to make a point, not 
to argue about definition of a "dead langauge". But if you really 
want to, the word "dead" has various meanings, including (but not 
limited to)[1]:

* having the appearance of death
* no longer producing or functioning
* lacking power or effect
* no longer having interest, relevance, or significance
* no longer in use
* commercially idle or unproductive
* certain to be doomed
* devoid of former occupants

When someone says "My phone's battery is dead", do you reply to 
them "you are exaggerating, it still has 1% left, it's only dead 
when it's 0%"?


 You can make a reasonable case that D has too little adoption 
 and/or growth, but please call the problem that, and nothing 
 else. Exaggregating the failings of the language serves only to 
 make people annoyed and hence defensive.


You know, I have tried to reasonably argue. I even went through 
the hussle of personally counting up registered/updated libraries 
on DUB, and ever since (IIRC, I did the counting a long time ago) 
2018 the amount of stuff being updated declined with every year. 
I mean, what would it take to confirm that D is dead or in a 
dying state? "Orgs using D" page being 75% filled with ones who 
ditched D is not enough? Dub statistics going down isn't enough?
Mike said something about "new contributors", but where are they?

As of now, the page lists 869 contributors. In Dec 2022 it was 
834 [2]. In Dec 2021 it was 783[3]. So the amount of new 
contributors basically halved in a year. Where is the said growth?
In Dec 2020, the list had 716 entries [4], showing no growth in 
new contributors for the year 2021.
That is not to mention that the list only shows new contributors 
and doesn't account those who have left.

So, I will reiterate: what would it take you to admit that D is 
more dead than alive and that something must be done about it? If 
you will only admit deadness when literally nobody is using the 
lang anymore, isn't it a tad too late for you?


[1] https://www.merriam-webster.com/dictionary/dead
[2] 
https://web.archive.org/web/20221207092606/https://dlang.org/foundation/contributors.html
[3] 
https://web.archive.org/web/20211204222010/https://dlang.org/foundation/contributors.html
[4] 
https://web.archive.org/web/20201125184925/https://dlang.org/foundation/contributors.html
Dec 19 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 19 December 2023 at 14:09:35 UTC, GrimMaple wrote:

 So, I will reiterate: what would it take you to admit that D is 
 more dead than alive and that something must be done about it?


D could show it is still alive by merging these two PRs before 
the new year:

https://github.com/dlang/dmd/pull/15537

Note that this one was approved at the August 2023 DLF meeting, 
implemented shortly thereafter, yet still sitting in limbo.

https://github.com/dlang/dmd/pull/15715

This is the culmination of about 6 years of work by the D 
community, yet is waiting on a pointless bit of red tape.


So many contributors have been driven away by similar situations. 
And it is going to happen again if they do not act within the 
next twelve days.
Dec 19 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 December 2023 at 14:27:15 UTC, Adam D Ruppe wrote:

 On Tuesday, 19 December 2023 at 14:09:35 UTC, GrimMaple wrote:

 So, I will reiterate: what would it take you to admit that D 
 is more dead than alive and that something must be done about 
 it?


 D could show it is still alive by merging these two PRs before 
 the new year:

 https://github.com/dlang/dmd/pull/15537

 Note that this one was approved at the August 2023 DLF meeting, 
 implemented shortly thereafter, yet still sitting in limbo.

 https://github.com/dlang/dmd/pull/15715

 This is the culmination of about 6 years of work by the D 
 community, yet is waiting on a pointless bit of red tape.


 So many contributors have been driven away by similar 
 situations. And it is going to happen again if they do not act 
 within the next twelve days.


I'm sympathetic to your frustrations on the string interpolation 
DIP (I don't know anything about the other one you mention). 
However, even if there has been a lot of work on and off for a 
number of years, that specific PR has only been outstanding since 
the second half of October. Most DIPs take longer than 3 months 
to get approved and language changes in other languages don't 
typically move that fast either (which isn't to say that D 
shouldn't try to move faster than other languages). Hopefully 
Walter can review before year end, but it seems like an arbitrary 
deadline to demand it be merged by then or you will no longer 
contribute. No doubt that DIP will be an uphill battle with 
Walter.

But I wouldn't disagree that with someone saying that D can 
certainly be a frustrating experience sometimes.

For some mir packages (no idea if this is a problem more 
generally), code.dlang.org won't catch updated tags without a 
force update. No idea why. But I only have the ability to force 
update some of them, but not all, and not the one I need to 
continue with what I've been working on.

I'm also confused why we can't come to some kind of agreement on 
issue 23479 [1]. That played out back in February and has been 
crickets since then.

[1] https://issues.dlang.org/show_bug.cgi?id=23479
Dec 19 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 19 December 2023 at 15:14:00 UTC, jmh530 wrote:

 Most DIPs take longer than 3 months to get approved and 
 language changes in other languages don't typically move that 
 fast either (which isn't to say that D shouldn't try to move 
 faster than other languages).


This needs to be corrected for D to thrive.


 For some mir packages (no idea if this is a problem more 
 generally), code.dlang.org won't catch updated tags without a 
 force update. No idea why.


Yeah, I think it does it in order on a timer and it just runs out 
of time and starts over from the beginning or something. dub 
needs a lot of work, no part of it actually works *well*.

(thankfully, you can be perfectly productive in D never using it!)


 I'm also confused why we can't come to some kind of agreement 
 on issue 23479 [1]. That played out back in February and has 
 been crickets since then.


Yeah, same root problem, as stalled PRs.
Dec 19 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 7:14 AM, jmh530 wrote:

 I'm sympathetic to your frustrations on the string interpolation DIP (I don't 
 know anything about the other one you mention).


I reviewed the DIP, and was informed the DIP had little to do with the 
implementation. I have asked for a specification of the actual implementation, 
and was told to read the the code.

My experience with specifications is that implementing them results in 
discovering all kinds of oversights and errors in the specification. 
Implementing it first and then writing a specification reveals all kinds of 
shortcomings in the implementation.

I'll review the proposal again when there's a specification for it. In the 
meantime, there is a competing proposal with specification and implementation
to 
compare:

https://github.com/dlang/dmd/pull/15722



 No doubt that DIP will be an uphill battle with Walter.


I'll reserve judgement on that until there is a specification.



 I'm also confused why we can't come to some kind of agreement on issue 23479 
 [1]. That played out back in February and has been crickets since then.
 
 [1] https://issues.dlang.org/show_bug.cgi?id=23479


This is because there are people who have .h files mixed in with their .d files 
along the import search path, and the resulting confusion about which file gets 
imported.
Dec 19 2023
next sibling parent reply duckchess <duckchess chess.com> writes:
On Tuesday, 19 December 2023 at 19:20:30 UTC, Walter Bright wrote:

 On 12/19/2023 7:14 AM, jmh530 wrote:

 [...]


 I reviewed the DIP, and was informed the DIP had little to do 
 with the implementation. I have asked for a specification of 
 the actual implementation, and was told to read the the code.

 My experience with specifications is that implementing them 
 results in discovering all kinds of oversights and errors in 
 the specification. Implementing it first and then writing a 
 specification reveals all kinds of shortcomings in the 
 implementation.

 I'll review the proposal again when there's a specification for 
 it. In the meantime, there is a competing proposal with 
 specification and implementation to compare:

 https://github.com/dlang/dmd/pull/15722



 [...]


 I'll reserve judgement on that until there is a specification.



 [...]


 This is because there are people who have .h files mixed in 
 with their .d files along the import search path, and the 
 resulting confusion about which file gets imported.


and DIP1027 is bad. it's been discussed to death why it's so bad. 
and yet you refuse to let it go and look at the proposal everyone 
else agrees is the best option.
it's literally why I refuse to even start to submit a DIP. it's a 
pointless waste of time.
Dec 19 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 11:29 AM, duckchess wrote:

 and DIP1027 is bad. it's been discussed to death why it's so bad. and yet you 
 refuse to let it go and look at the proposal everyone else agrees is the best 
 option.
 it's literally why I refuse to even start to submit a DIP. it's a pointless 
 waste of time.


I spent a whole afternoon carefully reviewing the DIP, only to be told that 
wasn't what was implemented and I should read the code. That was a waste of
time.

When there's a specification of it, I will give it a fair review.
Dec 19 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
I'm kind of tired of this argument, so this will be the only 
reply.

On Tuesday, 19 December 2023 at 20:22:13 UTC, Walter Bright wrote:

 On 12/19/2023 11:29 AM, duckchess wrote:

 and DIP1027 is bad. it's been discussed to death why it's so 
 bad. and yet you refuse to let it go and look at the proposal 
 everyone else agrees is the best option.
 it's literally why I refuse to even start to submit a DIP. 
 it's a pointless waste of time.


 I spent a whole afternoon carefully reviewing the DIP, only to 
 be told that wasn't what was implemented and I should read the 
 code. That was a waste of time.


No, no you weren't. You were told exactly what the spec is. What 
you did was take the examples of things *that are possible with 
the DIP* (not the specification), and complain that we can't add 
those to phobos and that the hypothetical examples were missing 
specification (because they are *examples* and not actual 
proposal).

As done before 
[here](https://forum.dlang.org/post/idrwdpwalhjaonsgmqtr forum.dlang.org) and
[here](https://forum.dlang.org/post/jhjocootfnfbcmgrcakj forum.dlang.org) and
[here](https://forum.dlang.org/post/nslqrrucnxrctqagtsfu forum.dlang.org)

-Steve
Dec 19 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 12:59 PM, Steven Schveighoffer wrote:

 I spent a whole afternoon carefully reviewing the DIP, only to be told that 
 wasn't what was implemented and I should read the code. That was a waste of
time.


 
 No, no you weren't. You were told exactly what the spec is. What you did was 
 take the examples of things *that are possible with the DIP* (not the 
 specification),


The dip was not the specification? The whole point of a dip is to be a 
specification. Where is the specification, then? Why is Atila reading the code 
and reverse engineering a specification for it?
Dec 19 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 20 December 2023 at 00:34:18 UTC, Walter Bright 
wrote:

 On 12/19/2023 12:59 PM, Steven Schveighoffer wrote:

 I spent a whole afternoon carefully reviewing the DIP, only 
 to be told that wasn't what was implemented and I should read 
 the code. That was a waste of time.


 
 No, no you weren't. You were told exactly what the spec is. 
 What you did was take the examples of things *that are 
 possible with the DIP* (not the specification),


 The dip was not the specification? The whole point of a dip is 
 to be a specification. Where is the specification, then? Why is 
 Atila reading the code and reverse engineering a specification 
 for it?


Clarifying here. I said you were arguing against the examples, 
which were in the DIP. Not the specification which also was in 
the DIP. Examples are examples, not specification. They *use* the 
feature to demonstrate its utility. They aren't intended to be 
part of the language additions.

The DIP has 2 parts:

part 1: Description (specification), and it is complete
part 2: Use Cases <= you are here, looking for the specification.

It would be like looking at [this part of 
DIP1010](https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#visitor-p
ttern-mathias-lang) and saying "where is the specification for the type Base?
We can't add Base to the language, because it would be a breaking change for
users who have made a type named Base! I can't continue review until this is
resolved".

Which is not, of course, what happened. It was accepted. I don't 
know what the difference is or how to make you recognize it.

-Steve
Dec 19 2023
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 6:33 PM, Steven Schveighoffer wrote:

 I said you were arguing against the examples, which were in the 
 DIP. Not the specification which also was in the DIP. Examples are examples,
not 
 specification. They *use* the feature to demonstrate its utility. They aren't 
 intended to be part of the language additions.


I used the examples to demonstrate problems with the specification. I used the 
examples in the DIP so I would not be accused of making up strawmen. I assumed 
the examples were supposed to conform to the specification.
Dec 19 2023
parent reply duckchess <duckchess chess.com> writes:
On Wednesday, 20 December 2023 at 07:47:12 UTC, Walter Bright 
wrote:

 On 12/19/2023 6:33 PM, Steven Schveighoffer wrote:

 I said you were arguing against the examples, which were in 
 the DIP. Not the specification which also was in the DIP. 
 Examples are examples, not specification. They *use* the 
 feature to demonstrate its utility. They aren't intended to be 
 part of the language additions.


 I used the examples to demonstrate problems with the 
 specification. I used the examples in the DIP so I would not be 
 accused of making up strawmen. I assumed the examples were 
 supposed to conform to the specification.


no, you took the examples while completely misunderstanding what 
the specification actually said, and then argued a strawman with 
those examples.
that's why you are now told to "just look at the implementation", 
because you cannot misunderstand that one.

if you insist on a specification, ask the D language foundation 
to pay someone to write one.
Dec 20 2023
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 20 December 2023 at 11:19:55 UTC, duckchess wrote:

 On Wednesday, 20 December 2023 at 07:47:12 UTC, Walter Bright 
 wrote:

 On 12/19/2023 6:33 PM, Steven Schveighoffer wrote:

 I said you were arguing against the examples, which were in 
 the DIP. Not the specification which also was in the DIP. 
 Examples are examples, not specification. They *use* the 
 feature to demonstrate its utility. They aren't intended to 
 be part of the language additions.


 I used the examples to demonstrate problems with the 
 specification. I used the examples in the DIP so I would not 
 be accused of making up strawmen. I assumed the examples were 
 supposed to conform to the specification.


 no, you took the examples while completely misunderstanding 
 what the specification actually said, and then argued a 
 strawman with those examples.
 that's why you are now told to "just look at the 
 implementation", because you cannot misunderstand that one.

 if you insist on a specification, ask the D language foundation 
 to pay someone to write one.


It can also be funny!

I would say: just directly try-out to code some more example, and 
see out it behave, when you are in doubt about the specification 
or if you think there's some ambiguity in it.

Everything is perfectible of course!

/P
Dec 20 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2023 3:19 AM, duckchess wrote:

 no, you took the examples while completely misunderstanding what the 
 specification actually said, and then argued a strawman with those examples.


Then the specification was unclear.
Dec 20 2023
parent reply DrDread <DrDread cheese.com> writes:
On Wednesday, 20 December 2023 at 19:07:06 UTC, Walter Bright 
wrote:

 On 12/20/2023 3:19 AM, duckchess wrote:

 no, you took the examples while completely misunderstanding 
 what the specification actually said, and then argued a 
 strawman with those examples.


 Then the specification was unclear.


It really was not unclear. but you are missing the point here.
it doesn't matter if it was or wasn't unclear, we are losing 
contributors because of this whole attitude.
there an implementation now so you cannot misunderstand it. 
people are running their own compiler fork because it's too much 
pain to get anything into dmd.
and you refuse to just look at the implementation and insist on 
having a specification again, but people are doing this in their 
free time, and are annoyed their work is constantly getting 
dismissed.

that'S why i said, if you really want to insist on a spec getting 
written, please just go and ask the D language foundation to pay 
adam to write one. or we will just again lose all the good work 
and probably more contributors.

we need a change to attract contributors.
Dec 21 2023
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 21 December 2023 at 10:59:29 UTC, DrDread wrote:

 On Wednesday, 20 December 2023 at 19:07:06 UTC, Walter Bright 
 wrote:

 On 12/20/2023 3:19 AM, duckchess wrote:

 no, you took the examples while completely misunderstanding 
 what the specification actually said, and then argued a 
 strawman with those examples.


 Then the specification was unclear.


 It really was not unclear. but you are missing the point here.
 it doesn't matter if it was or wasn't unclear, we are losing 
 contributors because of this whole attitude.
 there an implementation now so you cannot misunderstand it. 
 people are running their own compiler fork because it's too 
 much pain to get anything into dmd.
 and you refuse to just look at the implementation and insist on 
 having a specification again, but people are doing this in 
 their free time, and are annoyed their work is constantly 
 getting dismissed.

 that'S why i said, if you really want to insist on a spec 
 getting written, please just go and ask the D language 
 foundation to pay adam to write one. or we will just again lose 
 all the good work and probably more contributors.

 we need a change to attract contributors.


Alright, this is getting out of hand. Walter asked for a spec so 
he could fully grasp the implementation, and Adam refused to 
write it. Atila volunteered to do so. He explained he was going 
on vacation for a few weeks and would get to it when he got back. 
He got back, got caught up on work, and has since been working to 
write the spec from Adam's implementation.

This is in spite of our policy right now to focus on 
stabilization and bug fixes rather than new features. Moreover, 
Atila has prioritized this over the editions document, so that's 
going to be delayed because of it.

So, let's be clear, Adam isn't being ignored here. Walter is 
going to review the spec once Atila finishes it. And then he will 
make a decision on it.

I'm sorry that Adam feels it isn't happening fast enough, but his 
string interpolation implementation is not the only thing that 
needs attention right now. It's going to get a fair shake, even 
if it doesn't happen as quickly as he or anyone else would like.
Dec 21 2023
next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Thursday, 21 December 2023 at 12:29:25 UTC, Mike Parker wrote:

 I'm sorry that Adam feels it isn't happening fast enough, but 
 his string interpolation implementation is not the only thing 
 that needs attention right now.


How do you prioritize things that need attention? For example, 
DMD is one of the flagship products of the D Language Foundation. 
Its main selling point is the compilation speed. However the 
out-of-the-box performance of `rdmd helloworld.d` is very far 
from perfect and looks inferior compared to `go run 
helloworld.go`. For more details see 
https://forum.dlang.org/thread/fqziujkpdbivsqxsgszu forum.dlang.org and
https://issues.dlang.org/show_bug.cgi?id=24289

Any business oriented company, let alone Apple, would normally 
address a similar issue as their absolutely top priority before 
anything else. But unpolished bad looking products are much more 
common in the open source world. The developers enjoy working on 
over-engineered contraptions, but neglect the boringly simple 
obvious usability fixes.
Dec 21 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 21 December 2023 at 15:13:03 UTC, Siarhei Siamashka 
wrote:

 However the out-of-the-box performance of `rdmd helloworld.d` 
 is very far from perfect and looks inferior


Wanna know the worst part? `rdmd` has been deprecated for... 
about 6 years now. A replacement was written that is about twice 
as fast, leveraging a major improvement to the compiler (the -i 
switch).

Care to guess what happened to it... and the people who wrote 
those contributions?
Dec 21 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2023 7:13 AM, Siarhei Siamashka wrote:

 Its main selling point is the 
 compilation speed. However the out-of-the-box performance of `rdmd
helloworld.d` 
 is very far from perfect and looks inferior compared to `go run
helloworld.go`. 


It's a good point. One of the likely suspects is object.d. It started out as a 
small, single file. But it has bloated up to biblical proportions, which have
to 
be compiled by every separately compiled D module. (If all the modules to a 
project are presented on the same command line, object.d only gets compiled 
once, and that effort is amortized over the other modules.)

For example, object.d has unit tests in it. Unit tests are a great feature of
D, 
but there they are in the wrong place. object.d should be split into object.d 
and object.di. The unit tests and definitions go in object.d, the declarations 
go in object.di.

Another culprit is writefln(). For all its faults, printf() is compact, fast, 
does not allocate memory, and:

```
extern (C) pragma(printf) int printf(const(char)* format, ...);
```

If anyone wants to pick up the flag on this,
https://issues.dlang.org/show_bug.cgi?id=24296

is all the compiler needs to see to use it. writefln() is anything but. We can 
do better.

Another problem is nobody ever profiles dmd anymore. There are no instructions 
in build.d in how to run the profiler.
Dec 21 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 21 December 2023 at 23:04:30 UTC, Walter Bright 
wrote:

 It's a good point. One of the likely suspects is object.d.


object.d is not significantly to blame.

First, important to establish a baseline. Just make an empty file 
and compile it:

$ time dmd -c empty

real    0m0.011s

Even if you brought the import time of object.d to absolute zero, 
you'd have *at most* 10ms to gain from it. This is less than 5% 
of the test times.

Even if you do a compile and link:

$ time dmd empty -main

real    0m0.163s

Most this time is spent in the linker, not the compiler. 
druntime's pre-compiled lib could potentially be smaller to 
reduce link times, but changing object.d will do very little for 
this.


 have to be compiled by every separately compiled D module.


Secondly, even if it were true that object.d were to blame, this 
would be an incorrect path. object.d is never *compiled*, it is 
merely imported.

Which means:


 For example, object.d has unit tests in it.


This is irrelevant. The unit tests are skipped with extreme 
rapidity. So are function bodies. The things the .di process 
strips out are already automatically skipped by the existing 
import process!

I went into more detail recently here:
http://dpldocs.info/this-week-in-d/Blog.Posted_2023_10_09.html#ctfe-caching


 Another culprit is writefln(). For all its faults, printf() is 
 compact, fast, does not allocate memory, and:


This is a more fruitful line of attack, but anyone looking into 
this, remember to be empirically driven. Test your assumptions - 
you'll probably be surprised at what actually makes a difference.


 Another problem is nobody ever profiles dmd anymore. There are 
 no instructions in build.d in how to run the profiler.


...but as you collect data, make sure it doesn't lead you astray. 
I remember when the dmd profiler said freeing memory was a 
significant cost, so everyone just stopped trying. Memory usage 
ballooned... and there was no actual impact on speed in the real 
world, because it turns out the specific `free()` implementation 
in the profile had a bug that no other implementation shared. 
Simply building dmd with the ldc compiler and using the Microsoft 
and GNU  C libraries completely erased that difference.
Dec 21 2023
prev sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 22/12/2023 12:04 PM, Walter Bright wrote:

 On 12/21/2023 7:13 AM, Siarhei Siamashka wrote:

 Its main selling point is the compilation speed. However the 
 out-of-the-box performance of `rdmd helloworld.d` is very far from 
 perfect and looks inferior compared to `go run helloworld.go`. 


 
 It's a good point. One of the likely suspects is object.d. It started 
 out as a small, single file. But it has bloated up to biblical 
 proportions, which have to be compiled by every separately compiled D 
 module. (If all the modules to a project are presented on the same 
 command line, object.d only gets compiled once, and that effort is 
 amortized over the other modules.)
 
 For example, object.d has unit tests in it. Unit tests are a great 
 feature of D, but there they are in the wrong place. object.d should be 
 split into object.d and object.di. The unit tests and definitions go in 
 object.d, the declarations go in object.di.


I want to see a significant chunk of object.d removed.

I have a proposal on how to proceed on this, I have already talked with 
Adam Wilson about it, so even if you don't hear from me directly you'll 
hear from him about it ;)

This isn't just for speeding imports up, it will also help custom 
druntime implementers quite significantly (as in, they'll stop 
complaining entirely).
Dec 21 2023
prev sibling next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 21 December 2023 at 12:29:25 UTC, Mike Parker wrote:

 Alright, this is getting out of hand.


It has been out of hand for *years*. Nice that you're finally 
recognizing it, too late for several quality contributors. Not 
too late for me....yet.

Phobos had a big inrush of development many years ago, but since 
then it has been a trickle, leaving wide gaps in functionality 
and questionable design that everyone agrees should be changed, 
yet it remains entrenched. Sure, some nice things are added, some 
bugs fixed, but they are few and far between. Is this because of 
a lack of people power? No! There's lots of people willing, some 
even *eager* to contribute to Phobos, but they are instead turned 
away or given contradictory requirements that are impossible to 
fulfill even with a million dollar budget, and certainly not 
going to happen with volunteer time.

The state of D documentation is still a mess - the official 
website still has two versions of the docs, both of which are 
broken in their own ways, and it has been.... i think about 9 
years now just sitting like that. The bugs in ddox have never 
been fixed, the decision to transition just sitting in limbo. Is 
this because of a lack of people power? No! I cared enough to fix 
it myself 7 years ago. Spent about a hundred hours over my 
Christmas break doing it. Got rejected with a message where they 
openly admitted they didn't bother looking at it.

Language bugs and features that have been in popular demand for 
ages sit unmerged. Is this because of a lack of people power? No! 
The discussions have been had, the code written. All the dictator 
has to do is lift his arbitrary holds and let the PR manager 
click the green button. Instead, more red tape gets added to the 
tangle until the ongoing time commitment to keep rebasing the PRs 
is proven to be a sunk cost fallacy, throwing good time after 
bad, and the contributors quit trying.

This has been the pattern repeated, over and over again, since 
before I joined the D. Remember Tango?

Insomuch as there is a lack of people power, it is the *result* 
of D's dysfunctional development, not the cause.

With all the talk about IVY and reformation this year, I really 
hoped things would be different.

Well, the year isn't over yet. There might still be hope.


 So, let's be clear, Adam isn't being ignored here. Walter is 
 going to review the spec once Atila finishes it. And then he 
 will make a decision on it.


The problem is that the entire D community is help up because one 
stubborn fool is held up by the rest of you as a "dictator".


 I'm sorry that Adam feels it isn't happening fast enough, but 
 his string interpolation implementation is not the only thing 
 that needs attention right now. It's going to get a fair shake, 
 even if it doesn't happen as quickly as he or anyone else would 
 like.


It would take about five seconds to click the button and move on 
to the next issue. Don't pretend this is some necessary process 
imposed by God that must be followed to the letter. You all are 
*choosing* to waste gobs of multiple people's time over an 
arbitrary hold.

You could choose instead to ... just not do that.
Dec 21 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 21 December 2023 at 15:19:27 UTC, Adam D Ruppe wrote:

 Phobos had a big inrush of development many years ago, but 
 since then it has been a trickle, leaving wide gaps in 
 functionality and questionable design that everyone agrees 
 should be changed, yet it remains entrenched. Sure, some nice 
 things are added, some bugs fixed, but they are few and far 
 between. Is this because of a lack of people power? No! There's 
 lots of people willing, some even *eager* to contribute to 
 Phobos, but they are instead turned away


I pulled some historical information today. The phobos rush of 
development around 2010 was the outlier; the rest of its life has 
been similar - slow and virtually closed.

You might have heard of the old stdlib wars; Tango vs Phobos. 
Care to guess how this started? 2004 - D was very young - and 
substantial parts of the community felt that Phobos "wasn't 
moving in any direction, useful features were missing and no one 
could easily provide code (or didn't feel as though they 
could)"[1] (this quote was written in November 2008, exact author 
unknown), so Sean Kelly, et.al., created a project later called 
"Ares" with a key goal of "produc[ing] a fully functional 
standard library for D" with a very important note that 
differentiated it from Phobos: "The Ares project will gladly 
accept all submissions for review and/or inclusion. Contributors 
are encouraged to respond to any community feedback and re-submit 
any changes or improvements they deem appropriate." [2] (that 
summary written in Sept 2005)

As one contemporaneous account summarized working with upstream: 
"Walter blesses many ideas. What I'm wondering is how quickly he 
incorporates the results." and citing, as a downside of an 
upstart competitor (which btw ive never heard of until now): "and 
it's still dependent on Walter, as it usually is." [3] (Sept 2004)

In 2006, a new user asked about the library situation. The 
answer: "Ares is also likely to be the staging point for other 
low-level enhancements by the community; last I checked, Sean was 
faster at responding to library contributions than Walter." [4]

It is worth noting that in Oct 2008, after being eviscerated in 
the press over having "two standard libraries", upstream FINALLY 
relented and merged parts of Ares (then known better as a major 
component of the Tango library) upstream as "druntime" in 2.020. 
[5]

But, despite some positive changes and some exciting periods of 
development, many of those 18 year old posts could just as well 
be posted today.

1: http://www.prowiki.org/wiki4d/wiki.cgi?StandardLib
2: http://www.dsource.org/forums/viewtopic.php?t=990
3: http://www.dsource.org/forums/viewtopic.php?t=342
4: http://www.dsource.org/forums/viewtopic.php?t=1873
5: http://www.dsource.org/forums/viewtopic.php?t=4229
Dec 22 2023
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 21 December 2023 at 12:29:25 UTC, Mike Parker wrote:

 On Thursday, 21 December 2023 at 10:59:29 UTC, DrDread wrote:

 [...]


 Alright, this is getting out of hand. Walter asked for a spec 
 so he could fully grasp the implementation, and Adam refused to 
 write it. Atila volunteered to do so. He explained he was going 
 on vacation for a few weeks and would get to it when he got 
 back. He got back, got caught up on work, and has since been 
 working to write the spec from Adam's implementation.

 [...]


Is a spec required when submitting a feature?


Looks like it a lot of work. Must it be done initially even when 
the implementation will likely be rejected?
Dec 21 2023
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2023 9:14 AM, aberba wrote:

 Is a spec required when submitting a feature?


Yes, unless it is trivial.


 Looks like it a lot of work.


They're not that much work, they're certainly a lot easier than an
implementation.


 Must it be done initially even when the 
 implementation will likely be rejected?


It is normal for organized language communities to require a spec for any 
language changes. I'm not aware of any that don't.
Dec 21 2023
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 22 December 2023 at 00:19:36 UTC, Walter Bright wrote:

 On 12/21/2023 9:14 AM, aberba wrote:

 Is a spec required when submitting a feature?


 Yes, unless it is trivial.



 Looks like it a lot of work.


 They're not that much work, they're certainly a lot easier than 
 an implementation.


Wouldn't it be easier if there's at least an interest shown 
towards such efforts? It looks to me that the implementation is 
good (considering Atila is looking to write the Spec in the 
format you consider appropriate). So now, with an implementation 
and docs already done, it could be reassuring if the authors are 
made to know if you're willing to include the implementation or 
not considering it's a lot of work implementing the feature and 
writing a spec only to find out it's not going to be included at 
all. D is a small community so I feel it makes sense that the 
process is adjusted a bit to be more "human".



 Must it be done initially even when the implementation will 
 likely be rejected?


 It is normal for organized language communities to require a 
 spec for any language changes. I'm not aware of any that don't.


Hmm. I understand your point. But that's when the change is 
DEFINITELY going to be included, right?

But until then, are you able to comment whether you're happy with 
the current implementation or not?

I think a small community like D should be able to facilitate 
such a process. We shouldn't have a bureaucracy problem at this 
stage. Could be demoralizing.
Dec 22 2023
parent Mike Parker <aldacron gmail.com> writes:
On Friday, 22 December 2023 at 20:54:02 UTC, aberba wrote:

 On Friday, 22 December 2023 at 00:19:36 UTC, Walter Bright 
 wrote:

 On 12/21/2023 9:14 AM, aberba wrote:

 Is a spec required when submitting a feature?


 Yes, unless it is trivial.



 Looks like it a lot of work.


 They're not that much work, they're certainly a lot easier 
 than an implementation.


 Wouldn't it be easier if there's at least an interest shown 
 towards such efforts? It looks to me that the implementation is 
 good (considering Atila is looking to write the Spec in the 
 format you consider appropriate). So now, with an 
 implementation and docs already done, it could be reassuring if 
 the authors are made to know if you're willing to include the 
 implementation or not considering it's a lot of work 
 implementing the feature and writing a spec only to find out 
 it's not going to be included at all. D is a small community so 
 I feel it makes sense that the process is adjusted a bit to be 
 more "human".


This isn't about the feature itself, but the implementation. 
We're going to get string interpolation. Walter has an 
implementation that he prefers. There's already been a good deal 
of discussion about Adam's implementation here in the forums. 
Adam brought it up in a monthly meeting. That's when Walter asked 
for a spec. He wants to be sure he understands it fully so that 
he can make a fair judgement.
Dec 22 2023
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 22 December 2023 at 00:19:36 UTC, Walter Bright wrote:

 It is normal for organized language communities to require a 
 spec for any language changes. I'm not aware of any that don't.


We do not have a committee, your are a dictator for life, formal 
documents are how committees communicate *among* themselves, we 
are often peasants before a king. I don't sit on a committee, I 
don't how a title, why should I try to be fancy? Im better off 
playing a jester to amase the king.

We should pretend to balance concerns trying to get a majority to 
vote on something, its ummmmm you and your aesthetic concerns for 
what will make news on hn or something.

If you wish to make a commmitty, I suggest you get a list of 
names of people with d projects, pick 30 by lottery, and give 
them the power to merge a patch *despite your objections* with a 
supermajority.
Dec 22 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
To communicate a proposal to users, a specification is also needed. Telling 
users to read the code isn't going to work.

A specification is needed to determine what the proposal is, and what it is
not. 
It is also used to judge whether the implementation is correct or not.
Dec 22 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 23 December 2023 at 06:18:16 UTC, Walter Bright 
wrote:

 To communicate a proposal to users, a specification is also 
 needed. Telling users to read the code isn't going to work.


Dozens of other people have had no trouble reading the extensive 
documentation and numerous usage examples.

In fact, more often than not, telling users to read a 
specification doesn't work - documentation and examples tend to 
be much better teaching tools.


 A specification is needed to determine what the proposal is, 
 and what it is not. It is also used to judge whether the 
 implementation is correct or not.


For a new feature, there is no meaningful difference between a 
spec bug and an impl bug. The question at hand is if the behavior 
is *useful* or not.
Dec 22 2023
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 23 December 2023 at 06:18:16 UTC, Walter Bright 
wrote:

 To communicate a proposal to users, a specification is also 
 needed. Telling users to read the code isn't going to work.


Well, as a user I often click through to the source when reading 
Phobos and other D docs and rarely, if ever, do I read specs 
unless tasked with verifying compliance or with creating a 
de-novo implementation against an extant spec.  Fortunately, Adam 
already has working code and examples while Attila is, 
reportedly, hammering away on the spec.

I think this is a good way to do things.  An independent spec 
writer may shine a spot on some unexpectedly dark corners, some 
implementer "blind spots".


 A specification is needed to determine what the proposal is, 
 and what it is not. It is also used to judge whether the 
 implementation is correct or not.


Yes, but specs need to be "debugged" too, and directed testing 
against a working body of code can be very helpful there... 
probably much more helpful than a bunch of code-free language 
lawyering.

At the very least a working implementation with examples should 
let us skip past a lot of the "proof by assertion" noise 
regarding difficulty of implementation and marginal utility.

Here's hoping for swift understanding and a useful addition to D.
Dec 23 2023
prev sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 21 December 2023 at 17:14:32 UTC, aberba wrote:

 Is a spec required when submitting a feature?


Well, it defines how you define "spec". Like I said earlier in 
this thread, I *did*, in fact, write several different 
explanations, including ddoc intended for users to understand:

https://github.com/dlang/dmd/pull/15715/files#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768db3dd974967751b37e1

There's also several examples of what is and isn't supposed to 
work:

what isn't supposed to work:
https://github.com/dlang/dmd/pull/15715/files#diff-31ab43241663a2bcdd12070866771b2018119e8d53db31ce8be4b7b4fe43b11c

what is supposed to work, including some specific edge cases:
https://github.com/dlang/dmd/pull/15715/files#diff-4f34bcd1d367aaf71ec21d197bb1f9fa43020ffa76e189633fe60a8e9d315b82

You're fairly new to this discussion... can you understand the 
feature from those links?
Dec 21 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2023 4:38 PM, Adam D Ruppe wrote:

 Well, it defines how you define "spec".


It's a document that describes the complete and exact behavior of the language 
change.

 From the spec alone one should be able to create a complete and conforming 
implementation of it.

Clarifying usage examples are often part of the spec. Tutorials are not part of 
the spec.

The text of the specification, once the proposal is adopted, will be merged
with 
the language specification.

I don't expect it to be as formal as, say, the C Standard is. But it should be 
good enough that someone could implement it completely and correctly without 
needing to refer to an existing implementation.
Dec 22 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2023 2:59 AM, DrDread wrote:

 It really was not unclear. but you are missing the point here.
 it doesn't matter if it was or wasn't unclear, we are losing contributors 
 because of this whole attitude.
 there an implementation now so you cannot misunderstand it. people are running 
 their own compiler fork because it's too much pain to get anything into dmd.
 and you refuse to just look at the implementation and insist on having a 
 specification again, but people are doing this in their free time, and are 
 annoyed their work is constantly getting dismissed.
 
 that'S why i said, if you really want to insist on a spec getting written, 
 please just go and ask the D language foundation to pay adam to write one. or
we 
 will just again lose all the good work and probably more contributors.
 
 we need a change to attract contributors.


Every organized and professional product I know of requires a specification to 
come with every formal proposal for a language change.

There are excellent reasons for that. It works to do it this way.

For example, consider Python Enhancement Proposals:

https://peps.python.org/pep-0001/#what-belongs-in-a-successful-pep

"Specification – The technical specification should describe the syntax and 
semantics of any new language feature. The specification should be detailed 
enough to allow competing, interoperable implementations for at least the 
current major Python platforms (CPython, Jython, IronPython, PyPy)."
Dec 21 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Friday, 22 December 2023 at 00:02:01 UTC, Walter Bright wrote:

 Every organized and professional product I know of requires a 
 specification to come with every formal proposal for a language 
 change.


Not the case with ImportC apparently, when you can just show up, 
make a 5K LOC PR out of thin air, mark it "trivial" and have 0 
spec or rationale prepared. Good double standards bro.


 They're not that much work, they're certainly a lot easier than 
 an implementation.


Don't you just go around assuming what is easy for people and 
what isn't. And it's not even a question of being easy, it's a 
question of wasting time on something that you would just veto 
anyway, so why bother?


 It is normal for organized language communities to require a 
 spec for any language changes. I'm not aware of any that don't.


Here is an example of such language: D. Because, apparently, spec 
is only requried when you personally feel like it, otherwise it's 
whatever goes.
Dec 22 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/22/2023 1:47 AM, GrimMaple wrote:

 Not the case with ImportC apparently, when you can just show up, make a 5K LOC 
 PR out of thin air, mark it "trivial" and have 0 spec or rationale prepared. 
 Good double standards bro.


ImportC was not a D language change. C has a standard, C11, which ImportC 
implements.
Dec 22 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Saturday, 23 December 2023 at 06:51:38 UTC, Walter Bright 
wrote:

 On 12/22/2023 1:47 AM, GrimMaple wrote:

 Not the case with ImportC apparently, when you can just show 
 up, make a 5K LOC PR out of thin air, mark it "trivial" and 
 have 0 spec or rationale prepared. Good double standards bro.


 ImportC was not a D language change. C has a standard, C11, 
 which ImportC implements.


We had this talk before, and you now it's a lie. If ImportC was 
just a C compiler - fine (not really fine, but at least your 
point would stand). But ImportC has to extensively communicate 
with D code, which requires specification on topics including, 
but not limited to:

* How C code should be imported in the first place (directly 
changes how `import` works)
* How parts of C code should be translated to usable D code 
(unclear, nobody discussed that)
* How to translate incompatible C `const` to D's `const` (no 
solution exists to this day, and you choose to ignore criticism 
on this topic)
* How to expand and use macros

And that's just what I could thinkg of from the top of my head. 
Go ahead and tell me all of that requires no specification.
Dec 23 2023
next sibling parent reply Daniel N <no public.email> writes:
On Saturday, 23 December 2023 at 09:49:09 UTC, GrimMaple wrote:

 On Saturday, 23 December 2023 at 06:51:38 UTC, Walter Bright 
 wrote:

 On 12/22/2023 1:47 AM, GrimMaple wrote:

 Not the case with ImportC apparently, when you can just show 
 up, make a 5K LOC PR out of thin air, mark it "trivial" and 
 have 0 spec or rationale prepared. Good double standards bro.




 And that's just what I could thinkg of from the top of my head. 
 Go ahead and tell me all of that requires no specification.


That can be incrementally improved, quality of implementation, no 
spec needed.

Has anyone actually found a concrete problem? Then create a 
thread and discuss that.

11 out of 10 times Walter delivers beyond expectations. There are 
of course some rare counter examples, but then please focus on 
those and not hypothetical arguments.
Dec 23 2023
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 23 December 2023 at 10:13:50 UTC, Daniel N wrote:


 Has anyone actually found a concrete problem?


There are a few in the bugzilla. None is really a blocker, but 
some defeat the purpose of the feature, which is importing 
unmodified C headers. dstep + tweaks or manual translation is 
still a saner option.
Dec 23 2023
prev sibling next sibling parent GrimMaple <grimmaple95 gmail.com> writes:
On Saturday, 23 December 2023 at 10:13:50 UTC, Daniel N wrote:

 That can be incrementally improved, quality of implementation, 
 no spec needed.


Same could be said about Adam's string interpolation, couldn't 
it? Yet here Walter sits demanding some kind of "spec" and not 
using this "can be incrementally improved" argument. Why is it 
that Walter's changes can be "improved later", and Adam's can 
not? You have to understand that I'm not trying to attack ImportC 
personally, even though I might be the biggest ImportC protester 
to this day. I'm trying to attack an obviously doubly standarded 
practice when one person demands specs and compliance from 
everyone else, even when the rest of the community disagrees, and 
feels no need to commit in the same way. If you want specs, then 
write them youself for your own changes too.


 Has anyone actually found a concrete problem? Then create a 
 thread and discuss that.


Again, same could be said about Adam's string interpolation. 
Where is the discussion besides "gib spec"?

As for ImportC, there are __plenty__ of fundamental issues with 
it that just get ignored.


 11 out of 10 times Walter delivers beyond expectations. There 
 are of course some rare counter examples, but then please focus 
 on those and not hypothetical arguments.


This is exactly the thing I'm talking about. He shows up, burdens 
the community with his Super Cool Ideaâ„¢, doesn't write specs, 
doesn't explain anything, people find sink holes in it, he merges 
it anyway. And now we are in this room: ImportC is already a 
thing (or rather, a broken mess) that __all__ the DMD 
contributors have to deal with. And it's not like this 
"discussing" is going to change the sad reality of this mess 
being broken. No amount of arguing is going to undo the 
maintenance burden that was forced upon contributors, no matter 
what you do.
Dec 23 2023
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 23 December 2023 at 10:13:50 UTC, Daniel N wrote:

 Has anyone actually found a concrete problem? Then create a 
 thread and discuss that.


(this one is old, it has since been mostly corrected, but the 
question of macros in general remains open)
http://dpldocs.info/this-week-in-d/Blog.Posted_2021_11_01.html

at one year old, the question of macros has still not been 
addressed, leaving importC well short of its potential:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_09.html#importc

And the namespace problem with conflicts was at that point, and 
still is, a serious problem for widespread adoption:
http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html


ImportC is 2 1/2 years old and still hasn't addressed fundamental 
problems with its model. It finally works ok if you use it alone, 
but it still has trouble if you use it with others.
Dec 23 2023
prev sibling parent reply Araq <rumpf_a web.de> writes:
On Saturday, 23 December 2023 at 09:49:09 UTC, GrimMaple wrote:

 And that's just what I could thinkg of from the top of my head. 
 Go ahead and tell me all of that requires no specification.


There is also nothing "simple" about implementing C11 anyway with 
its "sequence points" and memory model and atomics and "volatile" 
and its undefined behaviors. But hey, it was simple in 1988 I 
guess when Mr Bright found his love for C...
Dec 23 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 23 December 2023 at 13:11:11 UTC, Araq wrote:

 There is also nothing "simple" about implementing C11 anyway


This, and as he learned the hard way, C11 alone is virtually 
useless for importC's mission, since vendor extensions are used 
heavily in the existing header files.
Dec 23 2023
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 20 December 2023 at 02:33:37 UTC, Steven 
Schveighoffer wrote:

 On Wednesday, 20 December 2023 at 00:34:18 UTC, Walter Bright 
 wrote:

 On 12/19/2023 12:59 PM, Steven Schveighoffer wrote:

[...]


 
 No, no you weren't. You were told exactly what the spec is. 
 What you did was take the examples of things *that are 
 possible with the DIP* (not the specification),


 The dip was not the specification? The whole point of a dip is 
 to be a specification. Where is the specification, then? Why 
 is Atila reading the code and reverse engineering a 
 specification for it?


 Clarifying here. I said you were arguing against the examples, 
 which were in the DIP. Not the specification which also was in 
 the DIP. Examples are examples, not specification. They *use* 
 the feature to demonstrate its utility. They aren't intended to 
 be part of the language additions.

 The DIP has 2 parts:

 part 1: Description (specification), and it is complete

 [snip]


I'm confused by what you mean by this. I can't recall seeing a 
DIP 1036e specification, just an implementation and examples. 
YADIP had a specification, but was superseded by 1036e.
Dec 20 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 20 December 2023 at 13:40:00 UTC, jmh530 wrote:

 I'm confused by what you mean by this. I can't recall seeing a 
 DIP 1036e specification, just an implementation and examples. 
 YADIP had a specification, but was superseded by 1036e.


Walter incorrectly read the YAIDIP specification. There was a 
hope that by implementing it 
<https://github.com/dlang/dmd/pull/15714>, it'd clear up the 
misconceptions.

After implementing the YAIDIP, as written, I decided to go ahead 
and fix some of its shortcomings, and opened that as a separate 
PR <https://github.com/dlang/dmd/pull/15715> which I called 
1036e, since it is a bit closer in design to 1036, but enhanced 
with ideas from YAIDIP.

The implementations of all three (these two and Walter's own 
DIP1027) ever *very* similar. Even to the point of me and Walter 
using - purely coincidentally - almost exactly the same tricks.

Look at how MixinExp is used in both of these diffs, for example:

https://github.com/dlang/dmd/pull/15715/files#diff-a556a8e6917dd4042f541bdb19673f96940149ec3d416b0156af4d0e4cc5e4bd

https://github.com/dlang/dmd/pull/15722/files#diff-a556a8e6917dd4042f541bdb19673f96940149ec3d416b0156af4d0e4cc5e4bd


I marked it as "FIXME" in mine, figuring it was a quick and easy 
hack to make it work, but surely there was a better way. Then I 
looked at Walter's, and he did exactly the same thing!

The biggest difference between the implementations is Walter's 
says things like:

"// Note: doesn't deal with Unicode code units in identifiers" 
and  "// Note: parsing is crude; not handling parens in literals"

Whereas mine handles all these correctly (as you can see in the 
unit tests included in my PR) thanks to doing lexing in the 
lexer, reusing all that existing machinery instead of crudely 
reinventing it: 
<https://github.com/dlang/dmd/pull/15715/files#diff-b893f1fe9a8dab286d255483a3dd8cd982bc321c655ab2be5f8d14402aeea5be>

But they're still built on the same concepts, and in many places, 
almost the same code! The core of the implementation is quite 
simple: lex the string, using sub-lexers for the interpolated 
elements, then lower to a tuple of the elements. There's even 
comments in the code showing the idea.

A big reason why my diff is bigger is that my PR includes 
user-facing documentation comments: 
<https://github.com/dlang/dmd/pull/15715/files#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768
b3dd974967751b37e1> which further, along with the half dozen examples of use
cases I wrote up (separately, but also including some design rationale
<https://github.com/adamdruppe/interpolation-examples/#feature-design-faq>),
help to explain what is going on beyond sharing the same conceptual foundation
as the other DIPs.

If you want to know how this works, you can:

1) Read the ddoc included in the PR. This is written for library 
authors, not compiler implementers, so hopefully it is accessible.

2) Read the examples repo. This is written for end users, to show 
them of the possibilities.

3) Read the comments in the implementation, which explain what 
the code does in simpler terms than dmd's AST, and the included 
unit tests which show what is and is not expected to work.

4) Compile it and try it for yourself!
Dec 20 2023
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 20 December 2023 at 15:33:40 UTC, Adam D Ruppe 
wrote:

 
 [snip]

 If you want to know how this works, you can:

 1) Read the ddoc included in the PR. This is written for 
 library authors, not compiler implementers, so hopefully it is 
 accessible.

 2) Read the examples repo. This is written for end users, to 
 show them of the possibilities.

 3) Read the comments in the implementation, which explain what 
 the code does in simpler terms than dmd's AST, and the included 
 unit tests which show what is and is not expected to work.

 4) Compile it and try it for yourself!


Thanks for the detailed explanation, but I think Walter will 
still come back with the response from before...
Dec 20 2023
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 December 2023 at 19:20:30 UTC, Walter Bright wrote:

 On 12/19/2023 7:14 AM, jmh530 wrote:
[snip]

 I'm also confused why we can't come to some kind of agreement 
 on issue 23479 [1]. That played out back in February and has 
 been crickets since then.
 
 [1] https://issues.dlang.org/show_bug.cgi?id=23479


 This is because there are people who have .h files mixed in 
 with their .d files along the import search path, and the 
 resulting confusion about which file gets imported.


I understand that. My point was just that still hasn't been 
resolved.

Steve suggested a separate import path flag for C imports. He 
explained [1]:


 For instance, if you want both C and D files imported from 
 directory a/b/c, you would do -Ia/b/c -CIa/b/c. If you only 
 wanted D files, you do -Ia/b/c. If you only wanted C files you 
 do -CIa/b/c. If you wanted C files first, and then D files, you 
 do -CIa/b/c -Ia/b/c.


You said it was a good idea and that it could work, but then you 
gave another approach of putting files with duplicate names on 
the command line to override search pattern behavior. Iain said 
that can lead to duplicate symbols. And the discussion petered 
out.


[1] 
https://github.com/dlang/dmd/pull/14864#issuecomment-1432080786
Dec 19 2023
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 19 December 2023 at 21:42:40 UTC, jmh530 wrote:

 I understand that. My point was just that still hasn't been 
 resolved.

 Steve suggested a separate import path flag for C imports. He 
 explained


I still say the best thing to do is to ditch the overloading of 
the `import` keyword and instead embrace the `mixin` keyword.

mixin[C](`#include<stdio.h>`);

you can now use the full file name, with .h or .c or whatever you 
want. And you can do this in context of D, meaning you can do 
things like :

 nogc {
    mixin[C](`#include<stdio.h>`);
}


And potentially use macros:

enum C_Context = mixin[C](`#define foo bar`);
mixin[C, C_Context](`use foo here`);

or something like that.
Dec 19 2023
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 1:52 PM, Adam D Ruppe wrote:

 I still say the best thing to do is to ditch the overloading of the `import` 
 keyword and instead embrace the `mixin` keyword.
 
 mixin[C](`#include<stdio.h>`);
 
 you can now use the full file name, with .h or .c or whatever you want. And
you 
 can do this in context of D, meaning you can do things like :
 
  nogc {
     mixin[C](`#include<stdio.h>`);
 }
 
 
 And potentially use macros:
 
 enum C_Context = mixin[C](`#define foo bar`);
 mixin[C, C_Context](`use foo here`);
 
 or something like that.


Programming with multiple languages is complicated, and it can work if the 
import mechanism gets to say what language the imported file is in.

I really like making things as simple as possible, and having them "just work". 
It's hard to beat:

     import whatever;

and not having file.d, file.c, and file.h in the same directory. Then life gets 
a lot simpler. After all, D was designed with the notion of package.module 
mapping directly onto directory/file. That inevitably results with some 
compromises on the names of the directories and files, etc., but it is worth it 
for the vast simplification of a 1:1 mapping.
Dec 19 2023
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 December 2023 at 21:52:01 UTC, Adam D Ruppe wrote:

 On Tuesday, 19 December 2023 at 21:42:40 UTC, jmh530 wrote:

 I understand that. My point was just that still hasn't been 
 resolved.

 Steve suggested a separate import path flag for C imports. He 
 explained


 I still say the best thing to do is to ditch the overloading of 
 the `import` keyword and instead embrace the `mixin` keyword.

 mixin[C](`#include<stdio.h>`);

 you can now use the full file name, with .h or .c or whatever 
 you want. And you can do this in context of D, meaning you can 
 do things like :

  nogc {
    mixin[C](`#include<stdio.h>`);
 }


 And potentially use macros:

 enum C_Context = mixin[C](`#define foo bar`);
 mixin[C, C_Context](`use foo here`);

 or something like that.


ImportC is a cool idea. It’s just got limitations right now that 
prevent it from being great. If rethinking it as mixin makes it 
smoother to use (does your idea resolve the duplicate symbol 
issue?), then it could make some sense.

I don’t know if it’s an either/or sort of thing, but I think you 
would need to introduce this with some sort of way to migrate 
existing importC code since importC wasn’t put behind a preview 
switch.

While you’re at it, a hypothetical D3 could have mixin[asm] and 
remove the asm block. You could also have `mixin[C/asm] template 
{}`.
Dec 19 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 20 December 2023 at 02:45:48 UTC, jmh530 wrote:

 (does your idea resolve the duplicate symbol issue?)


No, that's a separate issue, along with the namespace needing to 
be shared for C struct matching. These need to be addressed 
regardless of how the C code is discovered.


 While you’re at it, a hypothetical D3 could have mixin[asm] and 
 remove the asm block. You could also have `mixin[C/asm] 
 template {}`.


hmm, yeah, i suppose so, that is similar to how gcc does it 
anyway.
Dec 19 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 6:45 PM, jmh530 wrote:

 ImportC is a cool idea. It’s just got limitations right now that prevent it
from 
 being great. If rethinking it as mixin makes it smoother to use (does your
idea 
 resolve the duplicate symbol issue?), then it could make some sense.


ImportC is already great :-) People who have been using it have reported that
it 
has saved them gobs of time. And that's what its mission is!

The desire to extend ImportC is a clear and inevitable sign of its success.



 I don’t know if it’s an either/or sort of thing, but I think you would
need to 
 introduce this with some sort of way to migrate existing importC code since 
 importC wasn’t put behind a preview switch.


ImportC isn't behind a preview switch because it is not a language change. 
Nothing changed in the language semantics.
Dec 20 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 1:42 PM, jmh530 wrote:

 You said it was a good idea and that it could work, but then you gave another 
 approach of putting files with duplicate names on the command line to override 
 search pattern behavior. Iain said that can lead to duplicate symbols. And the 
 discussion petered out.


We couldn't find a solution that satisfied both of us.

It's not a showstopper problem. At worst, you can do:

---file.c---
#include "file.h"
------------

thereby "converting" a .h file to a .c file.
Dec 19 2023
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 20 December 2023 at 00:36:31 UTC, Walter Bright 
wrote:

 On 12/19/2023 1:42 PM, jmh530 wrote:

 You said it was a good idea and that it could work, but then 
 you gave another approach of putting files with duplicate 
 names on the command line to override search pattern behavior. 
 Iain said that can lead to duplicate symbols. And the 
 discussion petered out.


 We couldn't find a solution that satisfied both of us.

 It's not a showstopper problem. At worst, you can do:

 ---file.c---
 #include "file.h"
 ------------

 thereby "converting" a .h file to a .c file.


I agree its not a showstopper problem, but it is a marketing 
problem for importC.
Dec 20 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2023 5:33 AM, jmh530 wrote:

 I agree its not a showstopper problem, but it is a marketing problem for
importC.


I agree with your assessment. I don't like the current state, either.
Dec 20 2023
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 19 December 2023 at 14:09:35 UTC, GrimMaple wrote:

 When someone says "My phone's battery is dead", do you reply to 
 them "you are exaggerating, it still has 1% left, it's only 
 dead when it's 0%"?


The difference is that this forum is full of language 
enthusiasts. Criticising the language here, whether for sound 
reasons or not, is always more or less difficult to read. This 
doesn't mean we have to pretend there aren't problems when there 
are, but it does mean that dramatising the issues beyond what 
they actually are stris people for no benefit for anyone.


 So, I will reiterate: what would it take you to admit that D is 
 more dead than alive and that something must be done about it?


Why would I do that? It's clear that the leadership is, in 
general, trying. Granted, Walter is stubborn about some issues 
and in most of them I tend to agree with "the crowd", which I 
maybe could bring up a bit more often. But in general, what would 
me complaining that "D is failing" without any concrete 
improvement ideas gain? I think they're already aware of D's 
position in, say, the TIOBE index, and more than enough people 
are reminding them about that already.

Or are you referring to my earlier comment that D should stay 
both a systems and an application programming language? That much 
opinion I do have that if we're to try something random to the 
language because nothing else is working, we shouldn't start by 
killing our existing unique selling points.

I think you might just feel that we don't believe you're having 

work better for you than D. Because we do like the language, and 
are just people, it's true that we're reluctant to admit even the 
actual problems, and that can come out as unsymphatetic towards 
those who bring those up. But making lots of angry noises about 
the issue only makes the situation worse.
Dec 19 2023
next sibling parent Hors <q q.com> writes:
On Tuesday, 19 December 2023 at 15:33:05 UTC, Dukc wrote:

 On Tuesday, 19 December 2023 at 14:09:35 UTC, GrimMaple wrote:

 [...]


 The difference is that this forum is full of language 
 enthusiasts. Criticising the language here, whether for sound 
 reasons or not, is always more or less difficult to read. This 
 doesn't mean we have to pretend there aren't problems when 
 there are, but it does mean that dramatising the issues beyond 
 what they actually are stris people for no benefit for anyone.

 [...]


One problem is here for fix the problems, some breaking changes 
are needed, which would make people just re-code same thing again 
and again. So I think we need to have some roadmap and list of 
possible breaking changes (so developers who dont want to re-code 
can avoid using such features).
Dec 19 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 19 December 2023 at 15:33:05 UTC, Dukc wrote:

 The difference is that this forum is full of language 
 enthusiasts. Criticising the language here, whether for sound 
 reasons or not, is always more or less difficult to read. This 
 doesn't mean we have to pretend there aren't problems when 
 there are, but it does mean that dramatising the issues beyond 
 what they actually are stris people for no benefit for anyone.

 Why would I do that? It's clear that the leadership is, in 
 general, trying. Granted, Walter is stubborn about some issues 
 and in most of them I tend to agree with "the crowd", which I 
 maybe could bring up a bit more often. But in general, what 
 would me complaining that "D is failing" without any concrete 
 improvement ideas gain? I think they're already aware of D's 
 position in, say, the TIOBE index, and more than enough people 
 are reminding them about that already.

 Or are you referring to my earlier comment that D should stay 
 both a systems and an application programming language? That 
 much opinion I do have that if we're to try something random to 
 the language because nothing else is working, we shouldn't 
 start by killing our existing unique selling points.

 I think you might just feel that we don't believe you're having 

 work better for you than D. Because we do like the language, 
 and are just people, it's true that we're reluctant to admit 
 even the actual problems, and that can come out as 
 unsymphatetic towards those who bring those up. But making lots 
 of angry noises about the issue only makes the situation worse.


My opinion has now for several years been that D must be forked 
because there are a lot of people that wants D to progress and 
catch up. Walter is a no sayer that puts Linus Torvalds to shame 
which makes D just sitting without any progress. It is time to 
part from this management and continue with people who are tired 
of being blocked by often strange decisions that are rooted from 
some stigma from the 80s. It's sad really but it is the truth. It 
is time to move on.
Dec 19 2023
next sibling parent reply Konstantin <kostya.hm2 gmail.com> writes:
On Tuesday, 19 December 2023 at 16:59:21 UTC, IGotD- wrote:


 My opinion has now for several years been that D must be forked 
 because there are a lot of people that wants D to progress and 
 catch up.


* So why is there no language forks? Maybe they are existed, but 
I have never heard about them.
* What features should be added to a derived language, in your 
opinion?
Dec 19 2023
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 19 December 2023 at 19:24:49 UTC, Konstantin wrote:

 On Tuesday, 19 December 2023 at 16:59:21 UTC, IGotD- wrote:


 My opinion has now for several years been that D must be 
 forked because there are a lot of people that wants D to 
 progress and catch up.


 * So why is there no language forks? Maybe they are existed, 
 but I have never heard about them.


Theres several "I HATE THIS CODE BASE IM MAKING MY OWN LANGUGE"; 
"neat" for example
Dec 19 2023
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 December 2023 at 19:46:07 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 19:24:49 UTC, Konstantin wrote:

 On Tuesday, 19 December 2023 at 16:59:21 UTC, IGotD- wrote:


 My opinion has now for several years been that D must be 
 forked because there are a lot of people that wants D to 
 progress and catch up.


 * So why is there no language forks? Maybe they are existed, 
 but I have never heard about them.


 Theres several "I HATE THIS CODE BASE IM MAKING MY OWN 
 LANGUGE"; "neat" for example


Neat is not a fork! While I do think the DMDFE code base has 
problems (seriously, figure out a way to dogfood Phobos, it's 
insane that the premier project in the language refuses to use 
its stdlib), Neat is more trying to pull D into directions that 
it's reluctant to go at the moment, ie. good refcounting, better 
caching, macros, proper package system. See my DConf23 talk! At 
any rate, it's not a fork though, it's a straight-up different 
language. I steal D syntax wherever I can, but that's just 
imitation, there's no lineage from DMD to the Neat compiler.
Dec 19 2023
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 12:07 PM, FeepingCreature wrote:

 figure out a way to dogfood Phobos, it's insane that the premier 
 project in the language refuses to use its stdlib)


There is a good reason for that. It's very difficult to debug the compiler when 
the reason it is failing is a code gen bug that is breaking Phobos in some 
unknown way. Debugging Phobos is (unfortunately) difficult because too much of 
Phobos imports every other module in Phobos. (We'd like to fix that for the
next 
iteration of Phobos.)

It's hard to port dmd to a new platform when it relies on Phobos and Phobos is 
not working on the new platform, a chicken-and-egg problem.

In order for our ease of debugging, we keep dmd's dependence on other code at a 
minimum.
Dec 19 2023
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 December 2023 at 20:37:02 UTC, Walter Bright wrote:

 On 12/19/2023 12:07 PM, FeepingCreature wrote:

 figure out a way to dogfood Phobos, it's insane that the 
 premier project in the language refuses to use its stdlib)


 There is a good reason for that. It's very difficult to debug 
 the compiler when the reason it is failing is a code gen bug 
 that is breaking Phobos in some unknown way. Debugging Phobos 
 is (unfortunately) difficult because too much of Phobos imports 
 every other module in Phobos. (We'd like to fix that for the 
 next iteration of Phobos.)

 It's hard to port dmd to a new platform when it relies on 
 Phobos and Phobos is not working on the new platform, a 
 chicken-and-egg problem.

 In order for our ease of debugging, we keep dmd's dependence on 
 other code at a minimum.


This makes little sense to me. You wouldn't *start* by making DMD 
run on the new platform, but the port would start with a 
cross-build from your old platform to the new platform, surely? 
I'd want to have the testsuite and every other tool passing on 
the new platform before I even try running DMD natively. And this 
problem only arises when you try to run DMD natively from the 
start, right? Or am I misunderstanding?
Dec 19 2023
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 19 December 2023 at 20:48:04 UTC, FeepingCreature 
wrote:

 On Tuesday, 19 December 2023 at 20:37:02 UTC, Walter Bright 
 wrote:

 On 12/19/2023 12:07 PM, FeepingCreature wrote:

 figure out a way to dogfood Phobos, it's insane that the 
 premier project in the language refuses to use its stdlib)


 There is a good reason for that. It's very difficult to debug 
 the compiler when the reason it is failing is a code gen bug 
 that is breaking Phobos in some unknown way. Debugging Phobos 
 is (unfortunately) difficult because too much of Phobos 
 imports every other module in Phobos. (We'd like to fix that 
 for the next iteration of Phobos.)

 It's hard to port dmd to a new platform when it relies on 
 Phobos and Phobos is not working on the new platform, a 
 chicken-and-egg problem.

 In order for our ease of debugging, we keep dmd's dependence 
 on other code at a minimum.


 This makes little sense to me. You wouldn't *start* by making 
 DMD run on the new platform, but the port would start with a 
 cross-build from your old platform to the new platform, surely? 
 I'd want to have the testsuite and every other tool passing on 
 the new platform before I even try running DMD natively. And 
 this problem only arises when you try to run DMD natively from 
 the start, right? Or am I misunderstanding?


With some made-up version numbers:

Let's say dmd-0.2 only builds correctly with phobos-0.1, dmd-0.3 
only builds correctly with phobos-0.2, and dmd-0.4 builds 
correctly with phobos-0.3, and due to a weird bug in phobos-0.2 
it builds against it, but crashes.

This means the only *reliable* way to bootstrap dmd-0.50 is to 
first build dmd-0.1, then use it to build dmd-0.2, etc. until you 
catch up. While this might seem like a reasonable choice, it's 
also very brittle (and unnecessarily so).

Since phobos is changing every version, and we don't want to hold 
back that progress (or bug fixes), it's better to have a *subset* 
of library that we can maintain separately, and with the front 
end, and we know it only changes infrequently, and we can ensure 
it builds correctly with some large range of compilers. This 
means bootstrapping is much faster, and more reliable. I'd much 
prefer this over that.

An alternative universe where phobos is versioned separately from 
dmd might have been an answer, but we don't have that situation.

Keep in mind that gdc has the *requirement* that you can build 
the compiler with the last 3 versions. We can't break that, 
regardless of how good the dogfood is.

-Steve
Dec 19 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 12:48 PM, FeepingCreature wrote:

 This makes little sense to me. You wouldn't *start* by making DMD run on the
new 
 platform, but the port would start with a cross-build from your old platform
to 
 the new platform, surely? I'd want to have the testsuite and every other tool 
 passing on the new platform before I even try running DMD natively. And this 
 problem only arises when you try to run DMD natively from the start, right? Or 
 am I misunderstanding?


The test suite is carefully designed to test the compiler. It's proven to be 
really good at that, too. But when the compiler doesn't run because Phobos
isn't 
working, I can't run the test suite.

Cross-compiling isn't been an option, and is still pretty darned clumsy with 
Windows<=>Linux.

The fewer the dependencies, the easier the debugging is. And tracking down 
obscure code gen bugs can be pretty hard enough.

There also isn't much that Phobos can add to the compiler. Some things that did 
help were just incorporated into the compiler source.
Dec 19 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
None of that would be an issue if we had a c++ dump backend.

After that its just a matter of distribution for druntime/phobos, rather 
than a hard problem that has to be solved on a case by case basis.

But alas, that wasn't how D was built or structured.
Dec 19 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 5:26 PM, Richard (Rikki) Andrew Cattermole wrote:

 None of that would be an issue if we had a c++ dump backend.


I don't know what that is.
Dec 19 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
All it means is to convert D to C++ mechanically.

We have a partial implementation for C++ headers already.
Dec 19 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 02:18:15 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 All it means is to convert D to C++ mechanically.

 We have a partial implementation for C++ headers already.


GDC 11 is a C++ implementation. If somebody labelled it as a 
"2017 edition" of D language and kept this implementation in 
maintenance mode in future GCC releases, then it (together with 
its Phobos) could be used for bootstrapping any modern D compiler.
Dec 19 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
That isn't going to work long term.

We already have at least one more release in between that one and 
current versions.

Using the C++ dump approach is significantly better, you go immediately 
to the latest version. With the old bootstrap approach you have to 
maintain N frontends with their glue code indefinitely. It doesn't scale.
Dec 19 2023
next sibling parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 02:31:58 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 That isn't going to work long term.

 We already have at least one more release in between that one 
 and current versions.


It's only one frontend, which is frozen at version 2.076 of 
language features. However it's good enough to develop software. 
It could be probably kept alive and updated just enough to keep 
compatible with the current and future GCC backends.


 Using the C++ dump approach is significantly better, you go 
 immediately to the latest version.


This approach sounds super fragile and restrictive. Compared to a 
full fledged GDC 11 with a complete arsenal of its features and 
Phobos.


 With the old bootstrap approach you have to maintain N 
 frontends with their glue code indefinitely. It doesn't scale.


Only the "edition 2017" frontend. There's no need for N 
frontends. But yes, maintaining even one frontend is not free and 
somebody needs to take care of it.
Dec 19 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 20/12/2023 3:49 PM, Siarhei Siamashka wrote:

 However it's good enough to develop software.


But not good enough to compile current releases of the frontend.

We currently have a chain of compilers if you want to bootstrap latest 
compiler from C++.

That chain can only get longer.
Dec 19 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 02:53:12 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 20/12/2023 3:49 PM, Siarhei Siamashka wrote:

 However it's good enough to develop software.


 But not good enough to compile current releases of the frontend.


Oh, indeed. I can confirm a clash of the `_d_allocmemory' symbol 
at the linking stage between 
"gcc-11.3.0/libphobos/libdruntime/rt/lifetime.d:57" and 
"dmd-2.106.0/compiler/src/dmd/root/rmem.d:215".

But isn't this a fault of the current frontend? Why did it pick 
the same function name, especially with a leading underscore?


 We currently have a chain of compilers if you want to bootstrap 
 latest compiler from C++.


This doesn't look good.
Dec 19 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 20/12/2023 4:21 PM, Siarhei Siamashka wrote:

     We currently have a chain of compilers if you want to bootstrap
     latest compiler from C++.
 
 This doesn't look good.


This is why its N compilers.

Every link in that chain of compilers has to be maintained.

Its not just a matter of maintaining the frontend, but also the glue 
code per version of the backend you target.

Plus druntime and phobos for good measure.

Oh and GCC has rules around what compilers may be used to compile GCC 
for distribution. So if D isn't already on a given target... have fun 
with that.



On the other hand our frontend is already marked up with 
``extern(C++)``, and has manually maintained C++ headers for it.

If only we could take advantage of that.
Dec 19 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 03:49:30 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 20/12/2023 4:21 PM, Siarhei Siamashka wrote:

     We currently have a chain of compilers if you want to 
 bootstrap
     latest compiler from C++.
 
 This doesn't look good.


 This is why its N compilers.


 From where I stand, it looks like someone tried to tweak the GC 
and memory allocation in a non-portable ubeRc0ol way inside of 
the DMD source code. Which made it incompatible with GDC 11, but 
who cares? Supposedly this is intended to make the compiler 
faster. Yet the DMD compiler falls flat on its face due to 
mundane reasons in a simple compilation speed dependent 
benchmark: 
https://forum.dlang.org/thread/fqziujkpdbivsqxsgszu forum.dlang.org


 Every link in that chain of compilers has to be maintained.


My alternative mundane suggestion would be to just fix the DMD 
code on github, so that it can be compiled with GDC 11 again. And 
then add GDC 11 to the CI in order to prevent it from breaking 
again in the future.


 Its not just a matter of maintaining the frontend, but also the 
 glue code per version of the backend you target.

 Plus druntime and phobos for good measure.


GDC 11 includes both druntime and phobos. There's no need to have 
the glue code per version of the backend as long as GDC is 
maintained as a part of GCC.

Again, my suggestion is to take the C++ implementation of the D 
frontend from GDC 11. Rebrand it into "D language 2017 edition" 
and add it back to the mainline GCC. Treat this frontend as a 
separate programming language and maintain it independently from 
the "modern D" frontend. But if the community is not interested 
in a properly maintained "2017 edition" of D language, then this 
idea is naturally dead.


 Oh and GCC has rules around what compilers may be used to 
 compile GCC for distribution. So if D isn't already on a given 
 target... have fun with that.


Could you please clarify this statement?


 On the other hand our frontend is already marked up with 
 ``extern(C++)``, and has manually maintained C++ headers for it.

 If only we could take advantage of that.


So now some sort of an ubeRc0ol transpiler from D to C++ is a 
magic solution?
Dec 20 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 21/12/2023 2:38 AM, Siarhei Siamashka wrote:

     Oh and GCC has rules around what compilers may be used to compile
     GCC for distribution. So if D isn't already on a given target...
     have fun with that.
 
 Could you please clarify this statement?


 From what Iain has said that I remember, you can only use the last 3 
major versions in binary form to compile the next version. They are 
pretty strict.

That is all I know on the subject.


     On the other hand our frontend is already marked up with
     |extern(C++)|, and has manually maintained C++ headers for it.
 
     If only we could take advantage of that.
 
 So now some sort of an ubeRc0ol transpiler from D to C++ is a magic 
 solution?


We already have it for generating headers.

```
   -HCd=<directory>  write C++ 'header' file to directory
   -HCf=<filename>   write C++ 'header' file to filename
```

It is incomplete, but there is enough there to see that it is in fact 
possible to do what I am suggesting and has quite desirable use cases 
outside of compilers.

This isn't a far fetched idea. It already exists.
Dec 20 2023
parent reply Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 14:01:00 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 From what Iain has said that I remember, you can only use the 
 last 3 major versions in binary form to compile the next 
 version. They are pretty strict.


Yes, if somebody is contributing a patch for GCC 14, then they 
can't immediately rely on a newly added fancy GCC 13 feature, but 
have to ensure that the code still can be successfully compiled 
by GCC 11, GCC 12 and GCC 13. Even older versions may or may not 
work, but this is not guaranteed.

GDC 15 won't have an obligation to be compilable by GDC 11. But 
this doesn't mean that GDC 15 (or DMD) suddenly needs to 
intentionally break compatibility with GDC 11.


 So now some sort of an ubeRc0ol transpiler from D to C++ is a 
 magic solution?


 We already have it for generating headers.

 ```
   -HCd=<directory>  write C++ 'header' file to directory
   -HCf=<filename>   write C++ 'header' file to filename
 ```

 It is incomplete, but there is enough there to see that it is 
 in fact possible to do what I am suggesting and has quite 
 desirable use cases outside of compilers.

 This isn't a far fetched idea. It already exists.


GDC 11 can successfully compile the following code:

```D
import std.stdio, std.string, std.range, std.algorithm, std.conv;
void main()  safe {
   "1, 2, 3, 4, 5".splitter(',').map!(x => 
x.strip.to!int).sum.writeln;
}
```

Can a hypothetical D to C++ transpiler do the same?

I don't suggest to rewrite the DMD compiler code in this style, 
but introducing a transpiler would force DMD developers to be 
limited to some sort of a "worseD" subset of the D language. Also 
the transpiler itself is an extra weak link and a potential 
source of bugs.
Dec 20 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 21/12/2023 4:12 AM, Siarhei Siamashka wrote:

 I don't suggest to rewrite the DMD compiler code in this style, but 
 introducing a transpiler would force DMD developers to be limited to 
 some sort of a "worseD" subset of the D language. Also the transpiler 
 itself is an extra weak link and a potential source of bugs.


The development of dmd is already limited!

It has to communicate with C++ for ldc and gdc to work today.

It was ported mechanically from C++.

It works without druntime being linked in (with optional support for GC 
clean up -lowmem switch).

The barriers you think exist don't, due to historical reasons.
Dec 20 2023
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/20/2023 7:17 AM, Richard (Rikki) Andrew Cattermole wrote:

 It was ported mechanically from C++.


The front end was ported mechanically by Daniel Murphy.

The backend was ported manually by myself. It turned out to be much less work 
than I anticipated.
Dec 20 2023
prev sibling parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 15:17:46 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 On 21/12/2023 4:12 AM, Siarhei Siamashka wrote:

 I don't suggest to rewrite the DMD compiler code in this 
 style, but introducing a transpiler would force DMD developers 
 to be limited to some sort of a "worseD" subset of the D 
 language. Also the transpiler itself is an extra weak link and 
 a potential source of bugs.


 The development of dmd is already limited!


Yes, of course it's limited! That's precisely what we are 
discussing here. See 
https://forum.dlang.org/post/htrjpzxubkbujxbcjnfd forum.dlang.org 
where it started ("seriously, figure out a way to dogfood Phobos, 
it's insane that the premier project in the language refuses to 
use its stdlib"). And this is a practical problem. Here's how 
DMD's backend code looks today: 
https://github.com/dlang/dmd/blob/v2.106.0/compiler/src/dmd/backend/elfobj.d

Let's suppose that I want to work on fixing 
https://issues.dlang.org/show_bug.cgi?id=24286
I would like to add a bunch of debugging prints at the right 
places to get a better picture about what's going on there. What 
do I have at my disposal? Yeah, only "printf" from the standard C 
library. Why? Because reasons.

```D
import std.stdio, core.stdc.stdio;

alias Elf64_Addr   = ulong;
alias Elf64_Xword  = ulong;
alias Elf64_Word   = uint;
alias Elf64_Half   = ushort;

struct Elf64_Sym
{
     Elf64_Word  st_name;
     ubyte       st_info;
     ubyte       st_other;
     Elf64_Half  st_shndx;
     Elf64_Addr  st_value;
     Elf64_Xword st_size;
}

void some_function(Elf64_Sym *s) {
     // Nah, we can't do this for debugging prints in the DMD 
backend code
     writefln("some_function: s = %s", *s);

     // The true way! Isn't this beautiful? Don't even dare to 
complain.
     printf("some_function: s = Elf64_Sym(%d, %d, %d, %d, %ld, 
%ld)\n",
         s.st_name, s.st_info, s.st_other, s.st_shndx, s.st_value, 
s.st_size);
}

void main() {
     auto s = Elf64_Sym(1, 2, 3, 4, 5, 6);
     some_function(&s);
}
```

The reliance on a restricted subset of D is annoying and inhibits 
productivity. And apparently you even want to cement this 
unfortunate status quo by introducing a transpiler from this 
"worseD" to C++. I see only troubles and no benefits at all.


 It has to communicate with C++ for ldc and gdc to work today.


Are you saying that using Phobos would prohibit interoperability 
with C++?


 It was ported mechanically from C++.

 It works without druntime being linked in (with optional 
 support for GC clean up -lowmem switch).


Is this really desired? Should it really work this way?


 The barriers you think exist don't, due to historical reasons.


?
Dec 21 2023
prev sibling parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Wednesday, 20 December 2023 at 15:12:37 UTC, Siarhei Siamashka 
wrote:

 On Wednesday, 20 December 2023 at 14:01:00 UTC, Richard (Rikki) 
 Andrew Cattermole wrote:

 From what Iain has said that I remember, you can only use the 
 last 3 major versions in binary form to compile the next 
 version. They are pretty strict.


 Yes, if somebody is contributing a patch for GCC 14, then they 
 can't immediately rely on a newly added fancy GCC 13 feature, 
 but have to ensure that the code still can be successfully 
 compiled by GCC 11, GCC 12 and GCC 13. Even older versions may 
 or may not work, but this is not guaranteed.

 GDC 15 won't have an obligation to be compilable by GDC 11. But 
 this doesn't mean that GDC 15 (or DMD) suddenly needs to 
 intentionally break compatibility with GDC 11.


Actually I double checked 
https://gcc.gnu.org/install/prerequisites.html and can't find 
anything to support such claim. I just vaguely remember that I 
had seen something like this somewhere, but maybe it was not an 
authoritative source. Or my memory is failing me.

But there are just 3 major releases of GCC maintained 
simultaneously. Once GCC/GDC 14 is out, GCC/GDC 11 will become 
unsupported and no bugs in it will be fixed from that moment on. 
The upcoming EOL is probably the main concern for GDC 11 and it's 
valid.
Dec 20 2023
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 20 December 2023 at 02:31:58 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

 That isn't going to work long term.

 We already have at least one more release in between that one 
 and current versions.

 Using the C++ dump approach is significantly better, you go 
 immediately to the latest version. With the old bootstrap 
 approach you have to maintain N frontends with their glue code 
 indefinitely. It doesn't scale.


Just a kind request, Rikki, can you partially quote the text you 
are replying? Reading the messages in 'basic' view mode in the 
forum is a little messy otherwise.
Dec 20 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 20/12/2023 10:37 PM, Paolo Invernizzi wrote:

 Just a kind request, Rikki, can you partially quote the text you are 
 replying? Reading the messages in 'basic' view mode in the forum is a 
 little messy otherwise.


Yeah sure.

I've been erring on the side of removing too much due to the possibility 
of quotes getting a bit unwieldy.

It is a balancing act and it seems I've gone too extreme :)
Dec 20 2023
prev sibling next sibling parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Dec 19, 2023 at 08:07:23PM +0000, FeepingCreature via Digitalmars-d
wrote:
[...]

 (seriously, figure out a way to dogfood Phobos, it's insane that the
 premier project in the language refuses to use its stdlib),


[...]

AIUI, this has much more to do with historical baggage than reluctance
to dogfood Phobos. DMD was originally written in C++, and accordingly
written in a way that's idiomatic to C++. Moreover, D has changed quite
a bit over time; modern D today is quite different from the "alternative
C++" that it resembled in its earlier days. A lot of modern idioms
didn't even exist back then.  When the desire to bootstrap D came
around, the DMD codebase was already firmly entrenched in C++ style.
Thanks to the monumental efforts of a few dedicated DMD devs, an
automatic translation scheme was worked out that translated, or to be
more precise *transliterated* the DMD C++ code into D.  If you've done
any kind of similar work before, you'd realize that this kind of process
can at most give you syntactically-correct D code written in C++ style,
a far cry from idiomatic D.  Which is what we have today: DMD is mostly
still written in a C++-like style, with bits and pieces here and there
gradually replaced by more idiomatic D.  But progress is slow -- DMD is
a large, complex codebase, and you can't just rewrite it overnight.

Moreover, DMD has a long history of being fine-tuned for maximum
performance. This kind of optimization cannot simply be translated
overnight into idiomatic D without performance consequences. It does not
mean that idiomatic D is not performant; what it means is that if you're
going to rewrite a piece of C++-style optimized code in idiomatic D,
you're gonna have to repeat those decades of fine-tuning and tweaking on
the new Phobos-style code before you'll get on par with current
performance.  It isn't as if there's a magic switch you flip to change
all C++-style array/list code into Phobos ranges and you'll magically
get on-par performance right out of the box. It takes time and effort to
go through the code and reengineer it in the new idiom. There are
different tradeoffs that you need to make decisions on, due to the
different idioms employed.  And obviously, being one of the big selling
points of D, fast compilation isn't something we can compromise on, even
temporarily, so any such effort can't be done piecemeal, you either have
to do it completely, or not do it at all.  But there's little incentive
to pour in the time and effort to achieve the same performance just so
we can pat ourselves on the back that yes, we did it with Phobos-using
code, when the current codebase already has the performance we want.
There are far too many higher-priority things to take care of than this
kind of self-congratulary time and energy sink.

(Caveat: I don't speak for the dmd devs, I'm just a bystander who's fed
up of people assuming and asserting things that aren't necessarily true,
even from my casual POV. So take this with an appropriately-sized grain
of salt.)


T

-- 
They say that "guns don't kill people, people kill people." Well I think the
gun helps. If you just stood there and yelled BANG, I don't think you'd kill
too many people. -- Eddie Izzard, Dressed to Kill
Dec 19 2023
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 19 December 2023 at 20:07:23 UTC, FeepingCreature 
wrote:

 On Tuesday, 19 December 2023 at 19:46:07 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 19:24:49 UTC, Konstantin wrote:

 [...]


 Theres several "I HATE THIS CODE BASE IM MAKING MY OWN 
 LANGUGE"; "neat" for example


 Neat is not a fork! While I do think the DMDFE code base has 
 problems (seriously, figure out a way to dogfood Phobos, it's 
 insane that the premier project in the language refuses to use 
 its stdlib), Neat is more trying to pull D into directions that 
 it's reluctant to go at the moment, ie. good refcounting, 
 better caching, macros, proper package system. See my DConf23 
 talk! At any rate, it's not a fork though, it's a straight-up 
 different language. I steal D syntax wherever I can, but that's 
 just imitation, there's no lineage from DMD to the Neat 
 compiler.


right, forks dont exist because allot of poeple dislike the 
codebase so why keep it?

But its a fork in the sense your starting to leave or making the 
politics change.
Dec 19 2023
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 December 2023 at 20:52:06 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 20:07:23 UTC, FeepingCreature 
 wrote:

 On Tuesday, 19 December 2023 at 19:46:07 UTC, monkyyy wrote:

 On Tuesday, 19 December 2023 at 19:24:49 UTC, Konstantin 
 wrote:

 [...]


 Theres several "I HATE THIS CODE BASE IM MAKING MY OWN 
 LANGUGE"; "neat" for example


 Neat is not a fork! While I do think the DMDFE code base has 
 problems (seriously, figure out a way to dogfood Phobos, it's 
 insane that the premier project in the language refuses to use 
 its stdlib), Neat is more trying to pull D into directions 
 that it's reluctant to go at the moment, ie. good refcounting, 
 better caching, macros, proper package system. See my DConf23 
 talk! At any rate, it's not a fork though, it's a straight-up 
 different language. I steal D syntax wherever I can, but 
 that's just imitation, there's no lineage from DMD to the Neat 
 compiler.


 right, forks dont exist because allot of poeple dislike the 
 codebase so why keep it?

 But its a fork in the sense your starting to leave or making 
 the politics change.


Well, ehh. I see what you're saying, sure. But for the last few 
years, most of my D usage has been at work anyways, and that's 
not going to change.

That said, sure, if D was a more open language, Neat would not 
exist. But half the point of Neat is to act as a demo to the D 
community of what's possible with certain features. So I don't 
really see it as "abandoning D" so much as, hopefully, running 
ahead a bit.
Dec 19 2023
prev sibling parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Tuesday, 19 December 2023 at 19:24:49 UTC, Konstantin wrote:

 * So why is there no language forks? Maybe they are existed, 
 but I have never heard about them.


Personally speaking, I did not fork the language for the sole 
reasoning of "If I am about to singlehandedly support an entire 
language, I might as well just start from scratch and do 
everything to my liking". After all, starting anew is always 
easier than trying to understand someone else's code.

And, about singlehandedly part, I could never get enough people 
to be interested in getting an actual fork going. With how things 
are in D community, when the top library contributors basically 
have their own standard libraries and even runtimes, it's clearly 
not a collaborative environment. But I can't even really blame 
anyone for that, because contributing to D directly (dmd, phobos) 
is usually a very painful experience. So it is easier to just 
write stuff in your own lib anyway.

You can pretty much say that Adam, Hip, Luna, and others already 
have their mini-forks of D. It's probably a matter of time when 
they just fork the compiler too. And I heard rumors that Adam is 
about to do just that.


 * What features should be added to a derived language, in your 
 opinion?


In my opinion, we should actually strip D of features and instead 
focus on getting a decent standard library out so nobody has to 
write their own anymore.
Dec 19 2023
next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Dec 19, 2023 at 11:48:48PM +0000, GrimMaple via Digitalmars-d wrote:
[...]

 In my opinion, we should actually strip D of features and instead
 focus on getting a decent standard library out so nobody has to write
 their own anymore.


What's your idea of a decent standard library?

I'm afraid that all of us here each have our own idea of what the
standard library should be, and they are incompatible with each other.

Cf.: https://xkcd.com/927/


T

-- 
Engineering almost by definition should break guidelines. -- Ali Çehreli
Dec 19 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Wednesday, 20 December 2023 at 00:09:57 UTC, H. S. Teoh wrote:

 What's your idea of a decent standard library?

 I'm afraid that all of us here each have our own idea of what 
 the standard library should be, and they are incompatible with 
 each other.


I don't have this pathological hatred towards phobos that some 
other Devs have and my code does rely on it heavily. That being 
said, phobos is really lacking in features. Also, it is a mess of 

that gets you 99% of what you want from the get go. Phobos, 
unfortunately, provides about 10% at best.

I don't really care for speed in a standard library, for me it 
should allow me to get stuff done quickly. I can swap out for an 
optimized solution later if needed.
Dec 19 2023
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 20 December 2023 at 00:20:38 UTC, GrimMaple wrote:

 That being said, phobos is really lacking in features.


Yeah, my biggest problem with it is just it doesn't do the things 
I want it to do.

The secondary problem is that the stuff it does do, it mostly 
just does mediocre, but that's good enough a lot of the time. The 
missing functionality is a lot bigger of a problem than the 
mediocre functionality.
Dec 19 2023
prev sibling parent Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 20 December 2023 at 00:20:38 UTC, GrimMaple wrote:

 I don't have this pathological hatred towards phobos that some 
 other Devs have and my code does rely on it heavily. That being 
 said, phobos is really lacking in features. Also, it is a mess 

 `System`, that gets you 99% of what you want from the get go. 
 Phobos, unfortunately, provides about 10% at best.


This is exactly what I mean when I say that Phobos should get 
bigger, not smaller. Phobos needs to incorporate more features 
that have broad applicability (Cross-cutting concerns). For 
example, server-apps, desktop/mobile-apps, embedded-apps all may 
have use for a Streams type interface, all for different reasons, 
but providing a standard Stream interface would allow all of 
those apps to interoperate with less friction.


 I don't really care for speed in a standard library, for me it 
 should allow me to get stuff done quickly. I can swap out for 
 an optimized solution later if needed.


If somebody really wants to, they can put an optimized version on 
DUB. But in general, people generally don't know what packages to 
use, and so they don't. By putting the kitchen sink into Phobos 
we're saying "here are known good implementations of the tools 
you need."
Dec 20 2023
prev sibling parent IGotD- <nise nise.com> writes:
On Tuesday, 19 December 2023 at 23:48:48 UTC, GrimMaple wrote:

 You can pretty much say that Adam, Hip, Luna, and others 
 already have their mini-forks of D. It's probably a matter of 
 time when they just fork the compiler too. And I heard rumors 
 that Adam is about to do just that.


There is no point in waiting and just create an official open 
fork. I'm not talking about some individual fork here but an 
entire new project with new management and vision which 
constitute several people. A project that can actually rally 
people to contribute to it.

It's not only about creating a fork but also officially declaring 
that this is a project and also try to get people to move from 
the old D project to the new.
Dec 20 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 8:59 AM, IGotD- wrote:

 My opinion has now for several years been that D must be forked because there 
 are a lot of people that wants D to progress and catch up. Walter is a no
sayer 
 that puts Linus Torvalds to shame which makes D just sitting without any 
 progress.


On the other hand, there was a looooong recent thread about how D should stop 
introducing new features and work on existing ones.
Dec 19 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Tuesday, 19 December 2023 at 12:58:16 UTC, Dukc wrote:


 Exaggregating the failings of the language serves only to make 
 people annoyed and hence defensive.


It's more than that though. There's a history of trolls coming on 
here to post rubbish any time someone makes a good post about the 
language. They wanted to be sure that if Google sent anyone here 
they'd only see negatives, which for the most part were made up. 
In this case, they're writing that the language is dead, and it 
means something when that's posted on the official website of the 
language.

If it were me, I'd just delete those posts and forget about 
defending the right to free expression. The folks that make these 
decisions don't agree with me that this vandalism does serious 
damage.
Dec 19 2023
parent Hors <q q.com> writes:
On Tuesday, 19 December 2023 at 14:14:13 UTC, bachmeier wrote:

 On Tuesday, 19 December 2023 at 12:58:16 UTC, Dukc wrote:


 Exaggregating the failings of the language serves only to make 
 people annoyed and hence defensive.


 It's more than that though. There's a history of trolls coming 
 on here to post rubbish any time someone makes a good post 
 about the language. They wanted to be sure that if Google sent 
 anyone here they'd only see negatives, which for the most part 
 were made up. In this case, they're writing that the language 
 is dead, and it means something when that's posted on the 
 official website of the language.

 If it were me, I'd just delete those posts and forget about 
 defending the right to free expression. The folks that make 
 these decisions don't agree with me that this vandalism does 
 serious damage.


Just deleting posts because you don't like them is not a valid 
option. You can't see advantages and disadvantages of language 
without discussing about it. And of course one of current 
disadvantage of D is lack of libraries/good projects.


 [...] to post rubbish [...]


a post you don't agree with doesn't mean it's rubbish. Take that, 
others can have opinions too, and sometimes these opinions are 
negative.
Dec 19 2023
prev sibling parent reply Luna <cli-luna protonmail.com> writes:
On Monday, 18 December 2023 at 15:48:02 UTC, GrimMaple wrote:

 On Monday, 18 December 2023 at 14:08:19 UTC, bachmeier wrote:

 Also telling they get the job done "quietly", are you trying 
 to hide the fact dlang is nearly dead


 It doesn't add anything to the conversation to make ridiculous 
 claims like this with no evidence. Calling D "nearly dead" 
 indicates you're not making a good faith effort to participate 
 in a discussion.


 I find it very funny how every time I ask anybody to show me 
 any "real app" written in D (to prove that D isn't dead), 
 nobody can do it. All I hear is "Symmetry this" and "Symmetry 
 that". Sometimes DPlug comes by. But I still haven't seen any 
 real life useful app being developed in D. Never. So it's 
 always either Symmetry, either some rumors about some company 
 allegedly using D back in 2015 to do something with no real 
 proof that D is still there or it was used in the first place.

 What is the point of a programming language? For me, it's to 
 make software. If the software isn't being made - the language 
 is dead.


 They didn't post complaints, they wrote code. Then once they 
 wrote all those libraries, other people used them.


 For real? People complain about Python all the time. And 
 because of those complaints something is being done about it. 
 People complain because they care. When people stop complaining 
 it's a telltale sign that they stopped caring (or left). Which 
 is probably why you don't see a lot of complaints about D - 
 because nobody is really writing D anyway. Every single person 
 has left already.


 What will help this language at this point is working on 
 libraries, documentation, tutorials, etc.


 I have been saying the same thing for a logn time now. But 
 now-now, I say nobody will write libraries for a language that 
 actively prevents you from writing libraries in the first 
 place. Like, why do you expect someone to do their job when 
 they **dare** to complain about stuff? The amount of times I've 
 been told to "shut up and do it yourself" is seriously 
 unacceptable. To a degree of being told "just fork the lang if 
 you don't like it". This is no way to drive in contributors.

 On Monday, 18 December 2023 at 15:14:51 UTC, Hors wrote:

 From me: all languages haves something to offer, like python 
 is beginner friendly, C was the master of it's time, Rust 
 allows you to write good performant and safe code. But I can't 
 really see whats D has to offer, D has many features of 
 course, but when you using libraries, you may need to throw 
 away half of the D.


 Actually, over time, D became significantly lacking in features 
 compared to other languages. The world has changed, and at this 
 point in time, with Native AOT being a thing and producing 

 for me. And guess where I'm going to :)


All the software my company (Kitsunebi Games) and my main 
project, Inochi2D, is written in D.

I am currently also speccing out a new UI toolkit for use in the 
Inochi2D project with a more modern look, working on a 
[library](https://github.com/Inochi2D/numem) to make DLang usable 
without a GC while still maintaining support for classes and such 
to make D libraries more usable outside of D, and such.

Inochi2D is also by extension bringing new blood in to the D 
community through people interested in contributing to the 
project, as well as people getting interested in D by extension 
of Inochi2D being written in D. And as it stands unless Walter 
does something really stupid with the language I do not intend 
switching away from D.

That being said I do sometimes feel like I need to maintain my 
own corner of the D ecosystem due to the lack of well maintained 
libraries, but hopefully the new blood joining through the 
Inochi2D community will help maintain all the libraries and apps 
I'm creating, heh.

Additionally, I now collaborate with the Dplug maintainers to 
make libraries more usable across the language ecosystem besides 
just Inochi2D.

One thing to hope is that the NLnet grant I applied for goes 
through, would mean I could work another year on Inochi2D and 
surrounding libraries instead of taking on contract work, thereby 
expanding the part of the D ecosystem made for desktop apps.
Dec 19 2023
next sibling parent reply Luna <cli-luna protonmail.com> writes:
Additionally, I feel all these discussions about "D is dead, what 
should we do" is a waste of air. If you want D to be more active, 
contribute to the ecosystem, make PRs to projects so that we 
don't have so many one-man-operations going on. Not to mention an 
increase in financial support to D developers working on the 
ecosystem, such as WebFreak making code-d, dub developers, etc, 
would also increase activity within the D ecosystem.
Dec 19 2023
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 20/12/2023 3:28 AM, Luna wrote:

 Additionally, I feel all these discussions about "D is dead, what should 
 we do" is a waste of air. If you want D to be more active, contribute to 
 the ecosystem, make PRs to projects so that we don't have so many 
 one-man-operations going on. Not to mention an increase in financial 
 support to D developers working on the ecosystem, such as WebFreak 
 making code-d, dub developers, etc, would also increase activity within 
 the D ecosystem.


Here here.

Positive contributions including the work that you do are very valuable 
and appreciated!
Dec 19 2023
prev sibling parent reply Hors <q q.com> writes:
On Tuesday, 19 December 2023 at 14:28:15 UTC, Luna wrote:

 Additionally, I feel all these discussions about "D is dead, 
 what should we do" is a waste of air. If you want D to be more 
 active, contribute to the ecosystem, make PRs to projects so 
 that we don't have so many one-man-operations going on. Not to 
 mention an increase in financial support to D developers 
 working on the ecosystem, such as WebFreak making code-d, dub 
 developers, etc, would also increase activity within the D 
 ecosystem.


"contribute to the ecosystem" is really unclear. What we can 
actually contribute, new libraries? Changes to language? If it's 
changes to language, then what we can add (or rework) to the 
language?
Dec 19 2023
next sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 19 December 2023 at 14:57:00 UTC, Hors wrote:

 On Tuesday, 19 December 2023 at 14:28:15 UTC, Luna wrote:

 Additionally, I feel all these discussions about "D is dead, 
 what should we do" is a waste of air. If you want D to be more 
 active, contribute to the ecosystem, make PRs to projects so 
 that we don't have so many one-man-operations going on. Not to 
 mention an increase in financial support to D developers 
 working on the ecosystem, such as WebFreak making code-d, dub 
 developers, etc, would also increase activity within the D 
 ecosystem.


 "contribute to the ecosystem" is really unclear. What we can 
 actually contribute, new libraries? Changes to language? If 
 it's changes to language, then what we can add (or rework) to 
 the language?


New libraries, ports from other langs, bindings, tutorials, posts 
in social network about your projects, open source your projects 
(if possible), YouTube/Twitch videos/streams about the language, 
use the language on your job/hackathon/hobby project, create bug 
reports/issues, review DIPs, create/review PRs, PRs to 
Phobos/SDC/DMD/LDC/3rd party library that you know well and know 
how to improve, support abandoned libraries, become a maintainer 
of current projects (like Tilix is looking for maintainer), 
donate $ to D devs, improve documentation, etc
Dec 19 2023
prev sibling next sibling parent reply Guillaume Piolat <first.name gmail.com> writes:
On Tuesday, 19 December 2023 at 14:57:00 UTC, Hors wrote:

 On Tuesday, 19 December 2023 at 14:28:15 UTC, Luna wrote:

 Additionally, I feel all these discussions about "D is dead, 
 what should we do" is a waste of air. If you want D to be more 
 active, contribute to the ecosystem, make PRs to projects so 
 that we don't have so many one-man-operations going on. Not to 
 mention an increase in financial support to D developers 
 working on the ecosystem, such as WebFreak making code-d, dub 
 developers, etc, would also increase activity within the D 
 ecosystem.


 "contribute to the ecosystem" is really unclear. What we can 
 actually contribute, new libraries? Changes to language? If 
 it's changes to language, then what we can add (or rework) to 
 the language?


I feel tempted to repost this:
https://dl.acm.org/doi/10.1145/2509136.2509515

In absence of new evidence, we should assume nothing makes as 
much difference as open-source libraries. The same paper says 
that the language features matter less so. So it's not very 
moving when people talk about languages or stdlib features on 
these forums, understandably the focus as a language community, 
but still.

So this library-first strategy is exactly what Grim is/was going 
on about with DlangUI, as it's a library packed with features 
that can make a large difference for D. The examples are very 
impressive!

How do we leave the state where it's a ton of work for a few 
people?
I think I may have a solution there for large frameworks:
https://dplug.org/tutorials/Dplug%20Tutorials%2016%20-%20Dplug%20architecture%20and%20D%20ecosystem.pdf

People that like to build :) can design more of their 
sub-libraries to be reusable for others, hence sharing a 
maintenance load more. It's a bit hindered by the various 
fragmentation factors ("is there a runtime? a GC? a libc?").

The problem is that traditionally library design in D follows the 
STL bottom-up STL Stepanov-style, but we should really make 
domain-specific libraries that follows the good practices of 
popular C libraries. That also, would be evidence-based.
Dec 19 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 8:28 AM, Guillaume Piolat wrote:

 In absence of new evidence, we should assume nothing makes as much difference
as 
 open-source libraries. The same paper says that the language features matter 
 less so. So it's not very moving when people talk about languages or stdlib 
 features on these forums, understandably the focus as a language community,
but 
 still.


This is the motivation behind ImportC - be able to use existing C libraries.
Dec 20 2023
parent reply Guillaume Piolat <first.name gmail.com> writes:
On Wednesday, 20 December 2023 at 19:51:07 UTC, Walter Bright 
wrote:

 This is the motivation behind ImportC - be able to use existing 
 C libraries.


Yes it's a great development. https://postimg.cc/CnxQ7Mq5

My point is that we spend so much time using and translating C 
libraries because they have desirable characteristics that the 
STL-style D (and C++) libraries lacks.
Dec 21 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/21/2023 6:35 AM, Guillaume Piolat wrote:

 My point is that we spend so much time using and translating C libraries
because 
 they have desirable characteristics that the STL-style D (and C++) libraries
lacks.


I understand. I also know that C libraries are always going to be a couple of 
order of magnitudes more plentiful.
Dec 21 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 6:57 AM, Hors wrote:

 "contribute to the ecosystem" is really unclear. What we can actually 
 contribute, new libraries? Changes to language? If it's changes to language, 
 then what we can add (or rework) to the language?


Anywhere you want to.

People often ask me what they can do to help. I give them 10 options. They 
inevitably choose option 11, the one that they really want to do.

It's all about what itch you want to scratch.
Dec 19 2023
parent reply Konstantin <kostya.hm2 gmail.com> writes:
On Tuesday, 19 December 2023 at 19:23:57 UTC, Walter Bright wrote:

 On 12/19/2023 6:57 AM, Hors wrote:

 "contribute to the ecosystem" is really unclear. What we can 
 actually contribute, new libraries? Changes to language? If 
 it's changes to language, then what we can add (or rework) to 
 the language?


 Anywhere you want to.

 People often ask me what they can do to help. I give them 10 
 options. They inevitably choose option 11, the one that they 
 really want to do.

 It's all about what itch you want to scratch.


Is there a public list of problems/improvements in phobos/dmd 
that a beginner can deal with?
Dec 19 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 11:32 AM, Konstantin wrote:

 Is there a public list of problems/improvements in phobos/dmd that a beginner 
 can deal with?


https://issues.dlang.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&cmdtype=doit&order=Bug%20Number&remtype=asdefault&list_id=246527
Dec 19 2023
parent reply Konstantin <kostya.hm2 gmail.com> writes:
On Tuesday, 19 December 2023 at 20:25:04 UTC, Walter Bright wrote:

 On 12/19/2023 11:32 AM, Konstantin wrote:

 Is there a public list of problems/improvements in phobos/dmd 
 that a beginner can deal with?


 https://issues.dlang.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&cmdtype=doit&order=Bug%20Number&remtype=asdefault&list_id=246527


Thanks!
Dec 19 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 12:38 PM, Konstantin wrote:

 Thanks!


Hope you find something you'll enjoy working on!
Dec 19 2023
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 19 December 2023 at 14:17:41 UTC, Luna wrote:

 All the software my company (Kitsunebi Games) and my main 
 project, Inochi2D, is written in D.

 I am currently also speccing out a new UI toolkit for use in 
 the Inochi2D project with a more modern look, working on a 
 [library](https://github.com/Inochi2D/numem) to make DLang 
 usable without a GC while still maintaining support for classes 
 and such to make D libraries more usable outside of D, and such.

 Inochi2D is also by extension bringing new blood in to the D 
 community through people interested in contributing to the 
 project, as well as people getting interested in D by extension 
 of Inochi2D being written in D. And as it stands unless Walter 
 does something really stupid with the language I do not intend 
 switching away from D.


This is the way. When you write useful stuff for yourself, other 
people find it useful. D is probably one of the only languages 
where a small team (even a team of 1) can produce insanely good 
and useful libraries.

I personally wish I could do more, but have not too much time to 
spend on my open-source projects. I'm sure they seem dead, but 
I'm always thinking about them...


 That being said I do sometimes feel like I need to maintain my 
 own corner of the D ecosystem due to the lack of well 
 maintained libraries, but hopefully the new blood joining 
 through the Inochi2D community will help maintain all the 
 libraries and apps I'm creating, heh.


I hope so. I think what might happen at some point is we get a 
set of "blessed" libraries that everyone uses, such that we have 
a robust ecosystem. I'd rather have this grow organically than be 
anointed by some important people.

One interesting study would be to look at the various libraries 
out there, and see which replace or supersede phobos. For 
example, you don't see a lot of std.algorithm replacements. This 
is probably a good indication that it's a solid piece. But we 
have like 15 json libraries...

I don't think I'll ever give up on D either. Just the power you 
can wield with so little effort is going to keep me here.

Anyway, back to lurking, everyone keep getting your whining out 
on D, and I can blissfully ignore.

-Steve
Dec 19 2023
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Tue, Dec 19, 2023 at 05:36:51PM +0000, Steven Schveighoffer via
Digitalmars-d wrote:

 On Tuesday, 19 December 2023 at 14:17:41 UTC, Luna wrote:

 
 All the software my company (Kitsunebi Games) and my main project,
 Inochi2D, is written in D.




Awesome!



 I am currently also speccing out a new UI toolkit for use in the
 Inochi2D project with a more modern look, working on a
 [library](https://github.com/Inochi2D/numem) to make DLang usable
 without a GC while still maintaining support for classes and such to
 make D libraries more usable outside of D, and such.
 
 Inochi2D is also by extension bringing new blood in to the D
 community through people interested in contributing to the project,
 as well as people getting interested in D by extension of Inochi2D
 being written in D. And as it stands unless Walter does something
 really stupid with the language I do not intend switching away from
 D.


 
 This is the way. When you write useful stuff for yourself, other
 people find it useful. D is probably one of the only languages where a
 small team (even a team of 1) can produce insanely good and useful
 libraries.


I heard Lisp can do that too. Whether that's a good thing or not, is up
for debate. :-D



 I personally wish I could do more, but have not too much time to spend
 on my open-source projects. I'm sure they seem dead, but I'm always
 thinking about them...


I'm also still using D, and don't plan to switch away in the foreseeable
future.  In spite of its flaws, it's still the least painful language
for me to use right now.



 That being said I do sometimes feel like I need to maintain my own
 corner of the D ecosystem due to the lack of well maintained
 libraries, but hopefully the new blood joining through the Inochi2D
 community will help maintain all the libraries and apps I'm
 creating, heh.


 
 I hope so. I think what might happen at some point is we get a set of
 "blessed" libraries that everyone uses, such that we have a robust
 ecosystem. I'd rather have this grow organically than be anointed by
 some important people.


Yeah that's what we need.



 One interesting study would be to look at the various libraries out
 there, and see which replace or supersede phobos. For example, you
 don't see a lot of std.algorithm replacements. This is probably a good
 indication that it's a solid piece. But we have like 15 json
 libraries...


I'm a heavy Phobos user, and std.algorithm / std.range are among the
best parts of Phobos.  Among the better modules are std.datetime,
std.path, std.bigint, std.regex (I'm a regex addict). std.process is
awesomely convenient for dealing with processes; one of the
better-designed APIs in Phobos IMO.  std.math / std.numeric are pretty
standard, with a few nice things in there, though there's that
strangeness with real vs. double. std.stdio is also pretty standard, but
could be improved (replace with I/O pipes?). I'm addicted to std.format
for its convenience but the implementation really could use some
improvement, same goes for std.conv. std.uni's implementation could also
use some improvement, but what's there is pretty serviceable for dealing
with Unicode (main missing features: Unicode line-breaking algorithm and
grapheme width -- I have an incomplete implementation of the latter but
never got around to finishing it).

std.meta / std.traits / std.typecons are good for metaprogramming,
though there are some weird bits.

Other parts of Phobos are meh, like std.container (I use it from time to
time but the API is klunky and rough around the edges), std.digest
(never used it, kinda random why it's in Phobos), std.encoding (hardly
ever use it), std.experimental (when it is coming out of deep freeze?),
std.json (meh), std.xml (bleh).  std.getopt gets the job done, but has
weird differences with standard Posix getopt() for no good reason, which
made me write my own getopt on at least 3 separate occasions.
std.signals - never used it, std.socket (meh), std.bitmanip (sometimes
useful), std.base64 (kinda random, used it once or twice but that's
about it -- honestly could just go in a dub library), std.csv (meh - my
fastcsv alternative runs way faster, though with no validation).
std.net.curl - weird API, std.net.isemail - seems like a totally random
thing to put in Phobos.  A lot of this stuff honestly could do better as
dub packages / external repos.



 I don't think I'll ever give up on D either. Just the power you can
 wield with so little effort is going to keep me here.


[...]

D has completely ruined me. After tasting its metaprogramming power (I
wrote my own boilerplate-less serialization in a couple o' weeks, where
in C++ I would've taken months with LOTS of nasty boilerplate), I just
can't go back to any other language anymore.  Every time I'm forced to
code in another language I find myself wishing for this or that D
feature that isn't in that language. And the more I have to write non-D
code the more I chafe inside and feel like I wanna just throw out what I
wrote and rewrite it better in D.  I've been wrecked. (And I love it!
:-D)


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making
time go faster!
Dec 19 2023
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 19 December 2023 at 18:37:47 UTC, H. S. Teoh wrote:

 I'm a heavy Phobos user, and std.algorithm / std.range are 
 among the best parts of Phobos.  Among the better modules are 
 std.datetime, std.path, std.bigint, std.regex (I'm a regex 
 addict). std.process is awesomely convenient for dealing with 
 processes; one of the better-designed APIs in Phobos IMO.  
 std.math / std.numeric are pretty standard, with a few nice 
 things in there, though there's that strangeness with real vs. 
 double. std.stdio is also pretty standard, but could be 
 improved (replace with I/O pipes?). I'm addicted to std.format 
 for its convenience but the implementation really could use 
 some improvement, same goes for std.conv. std.uni's 
 implementation could also use some improvement, but what's 
 there is pretty serviceable for dealing with Unicode (main 
 missing features: Unicode line-breaking algorithm and grapheme 
 width -- I have an incomplete implementation of the latter but 
 never got around to finishing it).

 std.meta / std.traits / std.typecons are good for 
 metaprogramming, though there are some weird bits.

 Other parts of Phobos are meh, like std.container (I use it 
 from time to
 time but the API is klunky and rough around the edges), 
 std.digest
 (never used it, kinda random why it's in Phobos), std.encoding 
 (hardly
 ever use it), std.experimental (when it is coming out of deep 
 freeze?),
 std.json (meh), std.xml (bleh).  std.getopt gets the job done, 
 but has
 weird differences with standard Posix getopt() for no good 
 reason, which
 made me write my own getopt on at least 3 separate occasions.
 std.signals - never used it, std.socket (meh), std.bitmanip 
 (sometimes
 useful), std.base64 (kinda random, used it once or twice but 
 that's
 about it -- honestly could just go in a dub library), std.csv 
 (meh - my
 fastcsv alternative runs way faster, though with no validation).
 std.net.curl - weird API, std.net.isemail - seems like a 
 totally random
 thing to put in Phobos.  A lot of this stuff honestly could do 
 better as
 dub packages / external repos.


A great list and analysis!

-Steve
Dec 19 2023
parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 6:15 PM, Steven Schveighoffer wrote:

 On Tuesday, 19 December 2023 at 18:37:47 UTC, H. S. Teoh wrote:

 I'm a heavy Phobos user, and std.algorithm / std.range are among the best 
 parts of Phobos.  Among the better modules are std.datetime, std.path, 
 std.bigint, std.regex (I'm a regex addict). std.process is awesomely 
 convenient for dealing with processes; one of the better-designed APIs in 
 Phobos IMO. std.math / std.numeric are pretty standard, with a few nice things 
 in there, though there's that strangeness with real vs. double. std.stdio is 
 also pretty standard, but could be improved (replace with I/O pipes?). I'm 
 addicted to std.format for its convenience but the implementation really could 
 use some improvement, same goes for std.conv. std.uni's implementation could 
 also use some improvement, but what's there is pretty serviceable for dealing 
 with Unicode (main missing features: Unicode line-breaking algorithm and 
 grapheme width -- I have an incomplete implementation of the latter but never 
 got around to finishing it).

 std.meta / std.traits / std.typecons are good for metaprogramming, though 
 there are some weird bits.

 Other parts of Phobos are meh, like std.container (I use it from time to
 time but the API is klunky and rough around the edges), std.digest
 (never used it, kinda random why it's in Phobos), std.encoding (hardly
 ever use it), std.experimental (when it is coming out of deep freeze?),
 std.json (meh), std.xml (bleh).  std.getopt gets the job done, but has
 weird differences with standard Posix getopt() for no good reason, which
 made me write my own getopt on at least 3 separate occasions.
 std.signals - never used it, std.socket (meh), std.bitmanip (sometimes
 useful), std.base64 (kinda random, used it once or twice but that's
 about it -- honestly could just go in a dub library), std.csv (meh - my
 fastcsv alternative runs way faster, though with no validation).
 std.net.curl - weird API, std.net.isemail - seems like a totally random
 thing to put in Phobos.  A lot of this stuff honestly could do better as
 dub packages / external repos.


 
 A great list and analysis!


Yes, I agree. It sounds like some of the work you've done would be candidates 
for Phobos3. Check with Adam Wilson!
Dec 20 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/19/2023 6:17 AM, Luna wrote:

 All the software my company (Kitsunebi Games) and my main project, Inochi2D,
is 
 written in D.
 
 I am currently also speccing out a new UI toolkit for use in the Inochi2D 
 project with a more modern look, working on a 
 [library](https://github.com/Inochi2D/numem) to make DLang usable without a GC 
 while still maintaining support for classes and such to make D libraries more 
 usable outside of D, and such.
 
 Inochi2D is also by extension bringing new blood in to the D community through 
 people interested in contributing to the project, as well as people getting 
 interested in D by extension of Inochi2D being written in D. And as it stands 
 unless Walter does something really stupid with the language I do not intend 
 switching away from D.
 
 That being said I do sometimes feel like I need to maintain my own corner of
the 
 D ecosystem due to the lack of well maintained libraries, but hopefully the
new 
 blood joining through the Inochi2D community will help maintain all the 
 libraries and apps I'm creating, heh.
 
 Additionally, I now collaborate with the Dplug maintainers to make libraries 
 more usable across the language ecosystem besides just Inochi2D.
 
 One thing to hope is that the NLnet grant I applied for goes through, would
mean 
 I could work another year on Inochi2D and surrounding libraries instead of 
 taking on contract work, thereby expanding the part of the D ecosystem made
for 
 desktop apps.


Wow! Some great work here!
Dec 19 2023
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 16 December 2023 at 21:11:42 UTC, aberba wrote:

 On Thursday, 14 December 2023 at 14:02:26 UTC, bachmeier wrote:

 On Thursday, 14 December 2023 at 05:40:04 UTC, Hors wrote:

 On Tuesday, 12 December 2023 at 15:02:11 UTC, bachmeier wrote:

 [...]


 D is not the best when it comes to interop with other 
 languages


 It's not terribly helpful to post something like that without 
 elaborating. I've been doing that for ten years and it works 
 great.


 Sometimes I wonder how many of the D criticisms come from those 
 who have been using the language for yrs in this community or 
 have experience enough to make an informed critique.


 From my limited understanding, D allows nogc code, GC code, 
 safe code, interop with many langs, etc. yet it's always not 
 enough for some reason.

 I wonder how many of those folks are really serious about using 
 the language cus it *seems* to me that a lot of experienced D 
 devs are quietly getting things done.


 Is there something I'm missing?


Only that unfortunely D lacks a big pusher like Apple, Google or 
Microsoft, where those naysayers would either be dragged into 
using D regardless of their opinion on automatic memory 
management if they wanted to make money in their platforms, or 
would leave to farming or something else.
Dec 17 2023
parent Hors <q q.com> writes:
On Sunday, 17 December 2023 at 18:50:53 UTC, Paulo Pinto wrote:

 On Saturday, 16 December 2023 at 21:11:42 UTC, aberba wrote:

 [...]


 Only that unfortunely D lacks a big pusher like Apple, Google 
 or Microsoft, where those naysayers would either be dragged 
 into using D regardless of their opinion on automatic memory 
 management if they wanted to make money in their platforms, or 
 would leave to farming or something else.


The lack of big companies sponsors is not the only problem. The 
other problems usually being the reasons why dont these compaines 
use D.
Dec 17 2023
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
ImportC was created to make interfacing with existing C libraries a *lot*
easier.
Dec 17 2023
prev sibling parent Kagamin <spam here.lot> writes:
On Monday, 11 December 2023 at 20:29:36 UTC, Hipreme wrote:

 Right now, I'll list projects that I'm maintaining that was 
 supposed to be unrelated to my project:

 - GLES Binding
 - Metal Binding
 - DirectX binding
 - A custom runtime for being able to use real D on WASM
 - OpenSL ES binding
 - AVAudioEngine binding
 - A custom build tool because `dub` is far from being enough to 
 my purpose
 - Windowing libraries because when I started it, I didn't knew 
 about adam's simpledisplay
 - Even JSON I had to reimplement, since the implementations I 
 tested bring features which I don't have in my custom runtime, 
 D code just seem to depend on everything, always.


I did that too, but it's difficult to call it maintenance. IME it 
takes a small fraction of effort needed to make the final 
product. Bindings have no logic and are immutable for all 
practical purposes. JSON is a straightforward and immutable 
specification and can be implemented unconsciously if you don't 
overengineer too much. I wrote xml and json parsers for no 
specific reason, just to test the myth that it's difficult to 
parse xml and see if parsers can be reasonably implemented 
without overengineering. The build tool looks like the biggest in 
your list, that can use design stage and subsequent improvements.
Dec 12 2023
prev sibling next sibling parent reply DLearner <bmqazwsx123 gmail.com> writes:
On Friday, 8 December 2023 at 09:06:34 UTC, Hors wrote:

 On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:


[...]

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, being 
 both safe and unsafe system language...), it backfired because 
 as you said, you always need to exclude some people or features.


[...]

FWIW, IMO, apart from the development and maintenance effort, 
there is nothing wrong in 'trying to be everything'.  Indeed it's 
a laudable effort.

There (was) a specific problem with the GC debate, in that there 
appeared to be a real effort to 'force' developers into the GC 
camp, rather than simply presenting it as an option (and I 
personally think that for business application programming it is 
a very good idea).
Trying to force people to do anything, even if you sincerely 
believe in what you are advocating, is simply a bad idea.
Dec 10 2023
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Sunday, 10 December 2023 at 17:47:52 UTC, DLearner wrote:

 On Friday, 8 December 2023 at 09:06:34 UTC, Hors wrote:

 On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:


 [...]

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, 
 being both safe and unsafe system language...), it backfired 
 because as you said, you always need to exclude some people or 
 features.


 [...]

 FWIW, IMO, apart from the development and maintenance effort, 
 there is nothing wrong in 'trying to be everything'.  Indeed 
 it's a laudable effort.


Everything here means being a c/zig replacement, c++ replacement, 
python replacement and for the hell of it rust replacement

and no, there is just no way to do that; the rust replacement 
plan of making a """"borrow checker"""" went nowhere, importC 
isn't going to implement a 1 to 1 preprecosser so it won't ever 
be useful and zig must be an ok c compiler given what people say 
is done.

D should focus on being a c++ replacement; we have better 
templates they just aren't well used by the std and it's not 
being communicated.
Dec 10 2023
parent IGotD- <nise nise.com> writes:
On Sunday, 10 December 2023 at 18:07:35 UTC, monkyyy wrote:

 D should focus on being a c++ replacement; we have better 
 templates they just aren't well used by the std and it's not 
 being communicated.


I agree 100% and that is why it was named D to begin. The world 
has since then moved on and C++ as well (but you can argue it 
became Frankenstein monster). D should remain a competitor to C++ 
but it needs to move on as well in order to remain competitive.
Dec 10 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/8/2023 1:06 AM, Hors wrote:

 This is one of biggest mistakes in dlang's design. They tried to be
"everything" 
 (being both garbage collected and not, being both safe and unsafe system 
 language...), it backfired because as you said, you always need to exclude
some 
 people or features.


I often use a mix of gc and malloc in a program - they each have their uses. 
It's sort of like using a struct or using a class - they coexist fine, and you 
can mix and match as you please.

Rust also has both safe and unsafe code.
Dec 17 2023
next sibling parent Hors <q q.com> writes:
On Monday, 18 December 2023 at 05:46:20 UTC, Walter Bright wrote:

 On 12/8/2023 1:06 AM, Hors wrote:

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, 
 being both safe and unsafe system language...), it backfired 
 because as you said, you always need to exclude some people or 
 features.


 I often use a mix of gc and malloc in a program - they each 
 have their uses. It's sort of like using a struct or using a 
 class - they coexist fine, and you can mix and match as you 
 please.

 Rust also has both safe and unsafe code.


Rust has both safe and unsafe, but it's still focus on safety. 
While dlang doesn't have any focus
Dec 17 2023
prev sibling next sibling parent reply Mike Shah <mshah.475 gmail.com> writes:
On Monday, 18 December 2023 at 05:46:20 UTC, Walter Bright wrote:

 On 12/8/2023 1:06 AM, Hors wrote:

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, 
 being both safe and unsafe system language...), it backfired 
 because as you said, you always need to exclude some people or 
 features.


 I often use a mix of gc and malloc in a program - they each 
 have their uses. It's sort of like using a struct or using a 
 class - they coexist fine, and you can mix and match as you 
 please.

 Rust also has both safe and unsafe code.


It would be interesting to hear from AAA game devs on this thread 
regarding their thoughts on garbage collection.

Unreal Engine implemented a garbage collector for their UObject 
(https://unrealcommunity.wiki/garbage-collection-36d1da) and the 
collector runs every 30-60 seconds.

Many game studios implement their own STL (Or rather standard 
library, avoiding templates) in C++ for debuggability and 
creating special cases for data structures (See EASTL as an 
example).

I think the major factor with D not being adopted more by AAA 
studios is legacy C and C++ codebases. Some game studios live 
title to title, so it's hard to start from scratch. Otherwise 
there may also exist other approval issues of getting LDC 
available on consoles with the Developer Kits (Again, need 
advocates to do this effectively volunteering after work to sell 
the idea).

Worth also listening to Ethan Watson's talk: 
https://www.youtube.com/watch?v=7YjLW7anNfc

Anyway, just a few quick thoughts.
Dec 18 2023
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 18 December 2023 at 10:37:20 UTC, Mike Shah wrote:

 On Monday, 18 December 2023 at 05:46:20 UTC, Walter Bright 
 wrote:

 On 12/8/2023 1:06 AM, Hors wrote:

 This is one of biggest mistakes in dlang's design. They tried 
 to be "everything" (being both garbage collected and not, 
 being both safe and unsafe system language...), it backfired 
 because as you said, you always need to exclude some people 
 or features.


 I often use a mix of gc and malloc in a program - they each 
 have their uses. It's sort of like using a struct or using a 
 class - they coexist fine, and you can mix and match as you 
 please.

 Rust also has both safe and unsafe code.


 It would be interesting to hear from AAA game devs on this 
 thread regarding their thoughts on garbage collection.

 Unreal Engine implemented a garbage collector for their UObject 
 (https://unrealcommunity.wiki/garbage-collection-36d1da) and 
 the collector runs every 30-60 seconds.

 Many game studios implement their own STL (Or rather standard 
 library, avoiding templates) in C++ for debuggability and 
 creating special cases for data structures (See EASTL as an 
 example).

 I think the major factor with D not being adopted more by AAA 
 studios is legacy C and C++ codebases. Some game studios live 
 title to title, so it's hard to start from scratch. Otherwise 
 there may also exist other approval issues of getting LDC 
 available on consoles with the Developer Kits (Again, need 
 advocates to do this effectively volunteering after work to 
 sell the idea).

 Worth also listening to Ethan Watson's talk: 
 https://www.youtube.com/watch?v=7YjLW7anNfc

 Anyway, just a few quick thoughts.



adopting Windows Forms/WPF alongside C++/CLI for their tooling.

Capcom shipped Devil May Cry for Playstation 5 using their own 

in-house engine to .NET 8.

D had an opportunity with Remedy, sadly it wasn't picked up by 
other studios.
Dec 18 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 18 December 2023 at 05:46:20 UTC, Walter Bright wrote:

 I often use a mix of gc and malloc in a program - they each 
 have their uses. It's sort of like using a struct or using a 
 class - they coexist fine, and you can mix and match as you 
 please.

 Rust also has both safe and unsafe code.


Have you ever thought about keeping the raw pointers as they are. 
Classes are references types that are allocated using GC. Structs 
are value types that cannot directly be allocated using GC. If 
you want to allocate a struct using GC they need to be 
encapsulated in a GC object. Manual heap allocation are entirely 
done with raw pointers as before.

This is essentially what Swift does, classes are references types 
that are allocated using GC and structs are value types that you 
cannot directly allocate on the heap or GC on its own.

This change is breaking change but can be done. A few standard 
library types must be rewritten though but that is under the hood 
not so exposed to the programmer.
Dec 18 2023
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/18/2023 3:12 AM, IGotD- wrote:

 Have you ever thought about keeping the raw pointers as they are. Classes are 
 references types that are allocated using GC. Structs are value types that 
 cannot directly be allocated using GC. If you want to allocate a struct using
GC 
 they need to be encapsulated in a GC object. Manual heap allocation are
entirely 
 done with raw pointers as before.
 
 This is essentially what Swift does, classes are references types that are 
 allocated using GC and structs are value types that you cannot directly
allocate 
 on the heap or GC on its own.
 
 This change is breaking change but can be done. A few standard library types 
 must be rewritten though but that is under the hood not so exposed to the 
 programmer.


I don't see the advantage of this.
Dec 18 2023
parent IGotD- <nise nise.com> writes:
On Monday, 18 December 2023 at 20:14:55 UTC, Walter Bright wrote:

 On 12/18/2023 3:12 AM, IGotD- wrote:

 Have you ever thought about keeping the raw pointers as they 
 are. Classes are references types that are allocated using GC. 
 Structs are value types that cannot directly be allocated 
 using GC. If you want to allocate a struct using GC they need 
 to be encapsulated in a GC object. Manual heap allocation are 
 entirely done with raw pointers as before.
 
 This is essentially what Swift does, classes are references 
 types that are allocated using GC and structs are value types 
 that you cannot directly allocate on the heap or GC on its own.
 
 This change is breaking change but can be done. A few standard 
 library types must be rewritten though but that is under the 
 hood not so exposed to the programmer.


 I don't see the advantage of this.


The advantage is by forcing GC objects to be an actual object 
(class), you can modify the GC algorithm to whatever you want. 
Unlike today we're stuck with a rudimentary GC type that might 
deter a lot of potential users and use cases.
Dec 18 2023
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/5/2023 1:26 PM, GrimMaple wrote:

 If you design a ` nogc` library, then GC people are left out.


GC code can call  nogc code, so I'm not sure how they are left out.

You can also design code so that it simply doesn't use the GC.
Dec 19 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 20/12/2023 9:32 AM, Walter Bright wrote:

 On 12/5/2023 1:26 PM, GrimMaple wrote:

 If you design a ` nogc` library, then GC people are left out.


 
 GC code can call  nogc code, so I'm not sure how they are left out.


One reason would be callbacks.

I.e.

```d
void func(scope void function()  nogc del)  nogc {
	del();
}

void callback() {

}

func(&callback);
```

The easiest solution to make that work that I've come up with is to 
invalidate both `` nogc`` attributes when the argument to func hasn't 
got it.
Dec 19 2023
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 4 December 2023 at 09:31:16 UTC, GrimMaple wrote:

 On Tuesday, 28 November 2023 at 15:19:25 UTC, DrDread wrote:

 why don't you start giving it the attention then?


 And it's not like building tools/3rd party for D is a good idea 
 anyway. Since the language can't decide what it wants to be, 
 and you end up having to either overengineer your code, either 
 listen to a lot of complaints how your code is unsupported in 
 certain cases.


D isn't tripping you here, rather the other languages sweep the 
dust under the rug. For instance, if you implement a library in 
Java, you're automatically failing to support GC-less 
programming. You don't have to support ` nogc`/`-betterC` 
scenarios in D either (and probably are best off not supporting 
them in most cases, at least for initial versions), it's just 
that the language gives you the choice.
Dec 10 2023
prev sibling next sibling parent Hors <ho rs.com> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


If you want alternatives to D, just use any high-level with C 
interop. Still it's not nice as D, I hope DLang gets more 
attention it needs in future.
Dec 01 2023
prev sibling next sibling parent reply Andrew <andrewlalisofficial gmail.com> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


Java is my first and forever love in the world of programming 
languages. I don't mind the hate it gets. ☕
Dec 06 2023
next sibling parent Djentile <derdjentile example.tld> writes:
On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:

 Java is my first and forever love in the world of programming 
 languages. I don't mind the hate it gets. ☕


And it's only getting better too, though I still prefer Scala. By 
the way, thanks for your work on handy-http.
Dec 06 2023
prev sibling next sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


 Java is my first and forever love in the world of programming 
 languages. I don't mind the hate it gets. ☕


Reminded me of my early days with VB6 and Turbo C (and Turbo 
Pascal)

I hated Java when I first tried it. Forced into this "everything 
is an object" mindset, and the books I was reading were 900 
pages... half of which were understanding OOP in general, not 
specifically aimed at Java.

Then you have the C programming language book, which is barely 
300 pages.

The late 90's was making me question the direction we were going 
and whether this was the career for me. OOP went through some 
transitions over the years but I will always remember watching 
Mike Acton data-oriented design to make me realise that I am not 
alone with my views.

Each to their own... and sorry for diverting the OP question.

#BackToTheQuestion.
Dec 07 2023
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 7 December 2023 at 10:42:45 UTC, Martyn wrote:

 On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:

 [...]


 Reminded me of my early days with VB6 and Turbo C (and Turbo 
 Pascal)

 I hated Java when I first tried it. Forced into this 
 "everything is an object" mindset, and the books I was reading 
 were 900 pages... half of which were understanding OOP in 
 general, not specifically aimed at Java.

 Then you have the C programming language book, which is barely 
 300 pages.

 The late 90's was making me question the direction we were 
 going and whether this was the career for me. OOP went through 
 some transitions over the years but I will always remember 
 watching Mike Acton data-oriented design to make me realise 
 that I am not alone with my views.

 Each to their own... and sorry for diverting the OP question.

 #BackToTheQuestion.


The Mike Acton that ended up working for Unity, as part of the
Dec 07 2023
parent reply Martyn <martyn.developer googlemail.com> writes:
On Thursday, 7 December 2023 at 11:50:44 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 10:42:45 UTC, Martyn wrote:

 On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:



 The Mike Acton that ended up working for Unity, as part of the 




Yes (I didn't know he had left unity, tho)
Dec 07 2023
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 7 December 2023 at 14:08:03 UTC, Martyn wrote:

 On Thursday, 7 December 2023 at 11:50:44 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 10:42:45 UTC, Martyn wrote:

 On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:



 The Mike Acton that ended up working for Unity, as part of the 




 Yes (I didn't know he had left unity, tho)


My remark was to made the point that regardless of his opinion on 
data-oriented design, he nowadays uses a programming language 
that is pretty much as OOP as Java is, even including the latest 
influences from FP that permeate both languages, as features are 
part of the OOP type system of both languages, e.g. lambdas are 
represented by specific classes/interfaces.
Dec 07 2023
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 7 December 2023 at 14:21:51 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 14:08:03 UTC, Martyn wrote:

 On Thursday, 7 December 2023 at 11:50:44 UTC, Paulo Pinto 
 wrote:

 On Thursday, 7 December 2023 at 10:42:45 UTC, Martyn wrote:

 On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:



 The Mike Acton that ended up working for Unity, as part of 




 Yes (I didn't know he had left unity, tho)


 My remark was to made the point that regardless of his opinion 
 on data-oriented design, he nowadays uses a programming 
 language that is pretty much as OOP as Java is, even including 
 the latest influences from FP that permeate both languages, as 
 features are part of the OOP type system of both languages, 
 e.g. lambdas are represented by specific classes/interfaces.


That's exactly why Unity went to shit and he left as a result, 
they picked the wrong language, so they wasted many years working 
on working around the language

That's what happen when you work with GC/OOP people, nothing good 
comes out of it, you get replaced by what ever is new and trendy

And then the people will exclude the people who care (Mike Acton) 
to empower the developprs who need assistance (GC/OOP) because 
these people can promote idiocracy, as opposed to meritocracy 
backed by tangible resulsts (how fast code run, and how efficient 
it is)
Dec 07 2023
next sibling parent reply Dom DiSc <dominikus scherkl.de> writes:
On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 And then the people will exclude the people who care (Mike 
 Acton) to empower the developprs who need assistance (GC/OOP) 
 because these people can promote idiocracy, as opposed to 
 meritocracy backed by tangible resulsts (how fast code run, and 
 how efficient it is)


And as always, the people who call themselfes "efficient" don't 
care for memory safety.
Everybody should use GC - not for assistence because of 
idiocracy, but as a fallback, because even the very best and most 
efficient developers can make mistakes. This is why all modern 
computer systems are full of loopholes. We should finally trash 
manual memory magagement - or at least put huge red warning 
lables on such products that they may be a little faster but can 
be very dangerous.
Dec 07 2023
parent Martyn <martyn.developer googlemail.com> writes:
On Thursday, 7 December 2023 at 15:51:43 UTC, Dom DiSc wrote:

 On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 And then the people will exclude the people who care (Mike 
 Acton) to empower the developprs who need assistance (GC/OOP) 
 because these people can promote idiocracy, as opposed to 
 meritocracy backed by tangible resulsts (how fast code run, 
 and how efficient it is)


 And as always, the people who call themselfes "efficient" don't 
 care for memory safety.
 Everybody should use GC - not for assistence because of 
 idiocracy, but as a fallback, because even the very best and 
 most efficient developers can make mistakes. This is why all 
 modern computer systems are full of loopholes. We should 
 finally trash manual memory magagement - or at least put huge 
 red warning lables on such products that they may be a little 
 faster but can be very dangerous.


"Everybody should use GC"

Yes -- to a degree, you are correct in this statement. However, 
there is a difference to just using the default bundled in a 
programming language, or building your own -- when you have 
complete control of how the memory is laid out. It puts you in 
control.

You can even argue that DOOM, a game from the early-to-mid-90s, 
has some kind of GC.

I think it is a stretch to assume that (AAA engine programmers 
specifically) "dont care for memory safety" as you put it. I 
think they care very much and do heavy testing. The average web 
developer, on the other hand, don't even think about it at all.


I have nothing further to say on this, as we are moving away from 
the original OP query.
Dec 07 2023
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 On Thursday, 7 December 2023 at 14:21:51 UTC, Paulo Pinto wrote:

 [...]


 That's exactly why Unity went to shit and he left as a result, 
 they picked the wrong language, so they wasted many years 
 working on working around the language

 That's what happen when you work with GC/OOP people, nothing 
 good comes out of it, you get replaced by what ever is new and 
 trendy

 And then the people will exclude the people who care (Mike 
 Acton) to empower the developprs who need assistance (GC/OOP) 
 because these people can promote idiocracy, as opposed to 
 meritocracy backed by tangible resulsts (how fast code run, and 
 how efficient it is)


Unreal is also full of OOP, and Unreal C++ alongside Blueprints 
uses a GC.

Their business is doing quite well.
Dec 07 2023
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 On Thursday, 7 December 2023 at 14:21:51 UTC, Paulo Pinto 
 wrote:

 [...]


 That's exactly why Unity went to shit and he left as a result, 
 they picked the wrong language, so they wasted many years 
 working on working around the language

 That's what happen when you work with GC/OOP people, nothing 
 good comes out of it, you get replaced by what ever is new and 
 trendy

 And then the people will exclude the people who care (Mike 
 Acton) to empower the developprs who need assistance (GC/OOP) 
 because these people can promote idiocracy, as opposed to 
 meritocracy backed by tangible resulsts (how fast code run, 
 and how efficient it is)


 Unreal is also full of OOP, and Unreal C++ alongside Blueprints 
 uses a GC.

 Their business is doing quite well.


Not if you want to write fast and efficient code

Look at what studios are doing with these engines, they all work 
around these mistakes

In fact, Unreal is internally planning a ECS/data-driven stack, 
Unreal isn't a new project, it's multiple decades old, with that 
comes tech debt and poor design that are hard to correct

https://www.youtube.com/watch?v=f9q8A-9DvPo

The value of Unreal isn't OOP, it's its graphics stack, editor 
and platforms it can reach
Dec 07 2023
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 7 December 2023 at 20:37:17 UTC, ryuukk_ wrote:

 On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 [...]


 Unreal is also full of OOP, and Unreal C++ alongside 
 Blueprints uses a GC.

 Their business is doing quite well.


 Not if you want to write fast and efficient code

 Look at what studios are doing with these engines, they all 
 work around these mistakes

 In fact, Unreal is internally planning a ECS/data-driven stack, 
 Unreal isn't a new project, it's multiple decades old, with 
 that comes tech debt and poor design that are hard to correct

 https://www.youtube.com/watch?v=f9q8A-9DvPo

 The value of Unreal isn't OOP, it's its graphics stack, editor 
 and platforms it can reach


As long as C++ classes, data members, function members, 
inheritance and method dispatch are used to implement an ECS 
system, like on that linked video, it is OOP.
Dec 07 2023
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 8 December 2023 at 07:04:29 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 20:37:17 UTC, ryuukk_ wrote:

 On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto 
 wrote:

 On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 [...]


 Unreal is also full of OOP, and Unreal C++ alongside 
 Blueprints uses a GC.

 Their business is doing quite well.


 Not if you want to write fast and efficient code

 Look at what studios are doing with these engines, they all 
 work around these mistakes

 In fact, Unreal is internally planning a ECS/data-driven 
 stack, Unreal isn't a new project, it's multiple decades old, 
 with that comes tech debt and poor design that are hard to 
 correct

 https://www.youtube.com/watch?v=f9q8A-9DvPo

 The value of Unreal isn't OOP, it's its graphics stack, editor 
 and platforms it can reach


 As long as C++ classes, data members, function members, 
 inheritance and method dispatch are used to implement an ECS 
 system, like on that linked video, it is OOP.


You miss the whole point, hence why it's not available today, 
because they are busy working around these mistakes

This is why people like Acton end up leaving, they get sabotaged 
by these people

"Me must use hammer on this porcelain, me no care, me like this 
hammer"
Dec 08 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
And seems like Carmack was mentioned

He also left because of this "software" industry, that doesn't 
understand what the hell they are supposed to be doing, the 
industry where managers love to promote and reward idiocracy

https://www.theverge.com/2022/12/16/23513622/john-carmack-leaving-meta-virtual-reality-oculus-cto
Dec 08 2023
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
D would annihilate the game industry thanks to its type 
introspection capabilities


```D
     auto view(Includes)()
     {
         return view!(Includes, Excludes!());
     }

     auto view(Includes, Excludes)()
     {
         static if (Includes.args.length == 1 && 
Excludes.args.length == 0)
         {
             auto storage = assure!(Includes.args[0]);
             return BasicView!(Includes.args[0]).create( storage );
         }
         else
         {

             size_t[Includes.args.length] includes_arr;
             static foreach (i, T; Includes.args)
             {
                 assure!(T)();
                 includes_arr[i] = type_id!(T);
             }
             size_t[Excludes.args.length] excludes_arr;
             static foreach (i, T; Excludes.args)
             {
                 assure!(T)();
                 excludes_arr[i] = type_id!(T);
             }
             return MultiView!(Includes.args.length, 
Excludes.args.length).create(&this, includes_arr, excludes_arr);
         }
     }
```


How sweeet!


```D
     foreach(view, e; registry.view!(Includes!(CTransform, 
CVelocity, CNetworked)))
     {
         auto trs = registry.get!(CTransform)(e);
         auto vel = registry.get!(CVelocity)(e);
         auto net = registry.get!(CNetworked)(e);
     }
```


0 OOP, few lines, only data, maximum performance


Let's promote this, not ``final public abstract class ECSSystem : 
Updatable, Syncrhonicable`` BS OOP propaganda
Dec 08 2023
next sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
Tagged Union, Tuples, Pattern Matching and D will reign as 
greatest modern non-OOP system language, the best better C and 
alternative to C++ language
Dec 08 2023
prev sibling parent Martyn <martyn.developer googlemail.com> writes:
On Friday, 8 December 2023 at 11:42:22 UTC, ryuukk_ wrote:

 D would annihilate the game industry thanks to its type 
 introspection capabilities

 - source code snipped...

 0 OOP, few lines, only data, maximum performance


 Let's promote this, not ``final public abstract class ECSSystem 
 : Updatable, Syncrhonicable`` BS OOP propaganda



10000% Agree! Dlang has potential in the gaming industry.
Still dominated by C++ but it will be interesting to see if Odin 
or Jai rise in popularity in the coming years.

Is there any lessons they are doing that could elevate D? Odin, 
for example, seems to have a lot of tools "out of the box" to get 
you start easily.

Back to the point - D has soooo muh potential in this field!
Dec 08 2023
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 8 December 2023 at 11:35:15 UTC, ryuukk_ wrote:

 And seems like Carmack was mentioned

 He also left because of this "software" industry, that doesn't 
 understand what the hell they are supposed to be doing, the 
 industry where managers love to promote and reward idiocracy

 https://www.theverge.com/2022/12/16/23513622/john-carmack-leaving-meta-virtual-reality-oculus-cto


Nowadays using Python, a deeply OOP based language, and the king 
of AI research.

```
Python 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC 
v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more 
information.

 type(int)






<class 'type'>

 int.__bases__






(<class 'object'>,)

 dir(int)






['__abs__', '__add__', '__and__', '__bool__', '__ceil__', 
'__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', 
'__eq__', '__float__', '__floor__', '__floordiv__', '__format__', 
'__ge__', '__getattribute__', '__getnewargs__', '__gt__', 
'__hash__', '__index__', '__init__', '__init_subclass__', 
'__int__', '__invert__', '__le__', '__lshift__', '__lt__', 
'__mod__', '__mul__', '__ne__', '__neg__', '__new__', '__or__', 
'__pos__', '__pow__', '__radd__', '__rand__', '__rdivmod__', 
'__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', 
'__rlshift__', '__rmod__', '__rmul__', '__ror__', '__round__', 
'__rpow__', '__rrshift__', '__rshift__', '__rsub__', 
'__rtruediv__', '__rxor__', '__setattr__', '__sizeof__', 
'__str__', '__sub__', '__subclasshook__', '__truediv__', 
'__trunc__', '__xor__', 'as_integer_ratio', 'bit_length', 
'conjugate', 'denominator', 'from_bytes', 'imag', 'numerator', 
'real', 'to_bytes']
```
Dec 08 2023
prev sibling parent Martyn <martyn.developer googlemail.com> writes:
On Friday, 8 December 2023 at 07:04:29 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 20:37:17 UTC, ryuukk_ wrote:

 On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto 
 wrote:

 On Thursday, 7 December 2023 at 14:32:26 UTC, ryuukk_ wrote:

 [...]


 Unreal is also full of OOP, and Unreal C++ alongside 
 Blueprints uses a GC.

 Their business is doing quite well.


 Not if you want to write fast and efficient code

 Look at what studios are doing with these engines, they all 
 work around these mistakes

 In fact, Unreal is internally planning a ECS/data-driven 
 stack, Unreal isn't a new project, it's multiple decades old, 
 with that comes tech debt and poor design that are hard to 
 correct

 https://www.youtube.com/watch?v=f9q8A-9DvPo

 The value of Unreal isn't OOP, it's its graphics stack, editor 
 and platforms it can reach


 As long as C++ classes, data members, function members, 
 inheritance and method dispatch are used to implement an ECS 
 system, like on that linked video, it is OOP.



There are so many things to unpack.


etc.

I am not an expert C++ programmer. I dont think there are many 
people in C++ land that can really be considered 'an expert' 
except for those that dive in heavy to figure out what the 
compiler really does to your code and the C++ tricks needed to 
bring out the best outcome.

(I am happy sticking with languages like C, not forgetting D and 
open to Odin or Jai.. and I would say this 1000 times over if I 
was creating a game)

If I entertain the idea that I HAD to write a game in C++, it 
will mostly be C-like code, except for some handy features C++ 
has (over C) as long as it does not come at a cost!

Now could there be reasons to create a class? Sure. However, if I 
do, I would have to truly understand what the compiler is doing 
to that code. Could I be adding method overrides or inheritence? 
Possibly, but I very doubt this code would be part of in-game 
logic. It is likely part of some editing tools that 'compiles' to 
raw data for in-game, generally speaking.

As I say - whatever. So you have Unreal engine using OOP. I can 
assure you they are being vary careful with the usage of classes, 
inheritence, overloading, etc, based on their C++ knowledge. They 
likely have extremely skilled C++ guys over there. This is not me 
blowing their trumpet but they wouldn't be getting average 
developers in for a tightly skill area. Again, we are talking 
about C++ that still gives you control compared to other 
languages.

You also have to remember that the Unreal Engine/Editor are tools 
for the masses. Unreal engine is avaiable for school kids, small 
game companies, to large AAA ones. Blimey, even a retired OAP 
could dabble in Unreal if they wanted to! Different people with 
different skill levels - so it has to cater to the majority so 
why not OOP-like? I mean, if they don't provide some sense of 
familarity, their competitors will.

To me, this could be the driving factor why there is OOP. It may 
also be because it keeps a level of similarity right back to 
Unreal Engine 1 days (which, from memory, the scripting language 
was OOP)  - Scripting languages are not been the appeal in gaming 
for a while, replaced by hot reloading or, as Unreal uses, their 
visual 'language' named blueprints.

While OOP is used, I don't find this to be a good reason to prove 
anything against my original post that (kinda) mocks using Java 
back in 1998.. to having shared views with someone I found on 
youtube that is respected in his field. (Mike Acton)

Any further reply, as far as I am concerned, it just trolling.
Dec 08 2023
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto wrote:

 Unreal is also full of OOP, and Unreal C++ alongside Blueprints 
 uses a GC.

 Their business is doing quite well.


Computer games and GC is really a good match if you have room for 
certain performance hit (regardless of type of GC). Many computer 
games have a lot of objects, these objects also often have some 
kind of relationship to each other. The lifetime and 
relationships are usually totally unpredictable. If the 
developers can do away with lifetime tracking and all associated 
bugs that's a big win, especially when investors today seem to 
have unrealistic deadlines. There are usually enough bugs as it 
is anyway.

GC in computer games today is probably standard I would presume. 
GC in the D language is a great thing and I don't want it to go 
away, just make it better.
Dec 08 2023
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Friday, 8 December 2023 at 13:29:54 UTC, IGotD- wrote:

 On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto wrote:

 Unreal is also full of OOP, and Unreal C++ alongside 
 Blueprints uses a GC.

 Their business is doing quite well.


 Computer games and GC is really a good match if you have room 
 for certain performance hit (regardless of type of GC). Many 
 computer games have a lot of objects, these objects also often 
 have some kind of relationship to each other. The lifetime and 
 relationships are usually totally unpredictable. If the 
 developers can do away with lifetime tracking and all 
 associated bugs that's a big win, especially when investors 
 today seem to have unrealistic deadlines. There are usually 
 enough bugs as it is anyway.

 GC in computer games today is probably standard I would 
 presume. GC in the D language is a great thing and I don't want 
 it to go away, just make it better.





 Computer games and GC is really a good match


No, this is misinformation

Contact any game studio and tell me how they feel about the GC in 
Unreal/Unity

Tell me why do they have to work around it, specially on mobile 
and consoles

This is why game devs don't take D seriously, there is too much 
non-serious people pushing bad takes like this
Dec 11 2023
parent reply IGotD- <nise nise.com> writes:
On Monday, 11 December 2023 at 17:54:52 UTC, ryuukk_ wrote:

 No, this is misinformation

 Contact any game studio and tell me how they feel about the GC 
 in Unreal/Unity

 Tell me why do they have to work around it, specially on mobile 
 and consoles

 This is why game devs don't take D seriously, there is too much 
 non-serious people pushing bad takes like this


They might have work around it like pausing the GC at times. 
However GC isn't going away and the benefits of it is not 
releasing a game that leaks.

GC the isn't going anywhere and if you look at new emerging 
languages, a majority of them has GC.

Disabling the MMU on CPU will make it faster but nobody does that 
for obvious reasons. Features has a cost.

Future games will have GC whenever you like it or not. Games are 
becoming more and more complex the benefit of having GC is 
obvious.
Dec 11 2023
parent reply Martyn <martyn.developer googlemail.com> writes:
On Monday, 11 December 2023 at 18:39:22 UTC, IGotD- wrote:

 ...

 Future games will have GC whenever you like it or not. Games 
 are becoming more and more complex the benefit of having GC is 
 obvious.


It is a misconception that having no Garbage Collector is bad or 
dangerous or silly. It is also misleading that (games programming 
specifically) will "benefit using a Garbage Collector as games 
get more complex."

Game programmers NEED CONTROL OF MEMORY. The only time I can see 
this ever changing is if hardware evolves at a faster rate than 
software. The reality is the opposite. game programmers have to 
squeeze every inch out of the hardware. Of course, I am referring 
to the AAA titles.

If you are making a 2D platformer, you could probably write it in 
Unity (and do a fairly poor job) and it will still run at 60fps 
on your PC. Of course, we are not talking about those games.

Performance is key and they are writing their own memory system. 
They also write it to suit the type of game they are making. They 
won't just use the default GC that comes bundled with a 
programming language.

Also, if there ever is going to be a C++ replacement in the 
gaming industry, I think Odin or Jai are going to win. They are 
not "GC languages"


On Monday, 11 December 2023 at 17:54:52 UTC, ryuukk_ wrote:

 On Friday, 8 December 2023 at 13:29:54 UTC, IGotD- wrote:

 On Thursday, 7 December 2023 at 19:21:10 UTC, Paulo Pinto 
 wrote:

 Unreal is also full of OOP, and Unreal C++ alongside 
 Blueprints uses a GC.

 Their business is doing quite well.


 ..
 ..
 Computer games and GC is really a good match


 No, this is misinformation

 Contact any game studio and tell me how they feel about the GC 
 in Unreal/Unity

 Tell me why do they have to work around it, specially on mobile 
 and consoles

 This is why game devs don't take D seriously, there is too much 
 non-serious people pushing bad takes like this



https://twitter.com/cmuratori/status/1167230252797480960
Dec 12 2023
next sibling parent reply DrDread <DrDread cheese.com> writes:
On Tuesday, 12 December 2023 at 11:05:30 UTC, Martyn wrote:

 Game programmers NEED CONTROL OF MEMORY.


while this is true, it's not true for the whole application. 
there's a lot of things in games that _do_ benefit from having a 
GC (or any other form of automatic memory management).

what you don't do is use the GC to track particles or game 
entities. but you can easily use it to allocate the arrays in 
which you manually manage those.
Dec 12 2023
parent reply Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 12 December 2023 at 12:40:15 UTC, DrDread wrote:

 On Tuesday, 12 December 2023 at 11:05:30 UTC, Martyn wrote:

 Game programmers NEED CONTROL OF MEMORY.


 while this is true, it's not true for the whole application. 
 there's a lot of things in games that _do_ benefit from having 
 a GC (or any other form of automatic memory management).

 what you don't do is use the GC to track particles or game 
 entities. but you can easily use it to allocate the arrays in 
 which you manually manage those.


I have (tried to) address this in previous comments. I am not 
100% against GC. I am just making a point that for high-level 
games, you need to be careful when using it (if you really need 
it at all.. and I wouldn't!)

Some game programmers make it clear they dont want to use it at 
all.

All this discussion on games, OOP, and GC all started just 
because I replied about using Java in the late-90's and how much 
I hated it. LOL.
Dec 12 2023
parent Hors <ho rs.com> writes:
On Tuesday, 12 December 2023 at 14:10:18 UTC, Martyn wrote:

 On Tuesday, 12 December 2023 at 12:40:15 UTC, DrDread wrote:

 [...]


 I have (tried to) address this in previous comments. I am not 
 100% against GC. I am just making a point that for high-level 
 games, you need to be careful when using it (if you really need 
 it at all.. and I wouldn't!)

 Some game programmers make it clear they dont want to use it at 
 all.

 All this discussion on games, OOP, and GC all started just 
 because I replied about using Java in the late-90's and how 
 much I hated it. LOL.



is this even a discussion? Or do people just defend their own 
opinions and ignores others'
Dec 12 2023
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 12 December 2023 at 11:05:30 UTC, Martyn wrote:

 gaming industry, I think Odin or Jai are going to win. They are 
 not "GC languages"


Jai isn't even released to the public, if it ever will be so 
claiming Jai is winning is a bit premature.
Dec 12 2023
parent Martyn <martyn.developer googlemail.com> writes:
On Tuesday, 12 December 2023 at 13:21:21 UTC, IGotD- wrote:

 On Tuesday, 12 December 2023 at 11:05:30 UTC, Martyn wrote:

 gaming industry, I think Odin or Jai are going to win. They 
 are not "GC languages"


 Jai isn't even released to the public, if it ever will be so 
 claiming Jai is winning is a bit premature.


I didn't say Jai is winning. I wrote "I think Odin or Jai are 
going to win" -- Its just a prediction. I don't mean tomorrow or 
next year, either. C++ will dominate for a number of years (and 
maybe some more) but IF any language starts to gain momentum in 


Jai and Odin are targeting the games industry (primarily) and 
they make it very clear what the language will and will not do 
out of the box.

We shall see...

However,
  - Jai is being developed for a moderately sized game (I believe 
it was called sokoban)
  - Odin is also used for a particle effects generator named 
EmberGen (might I add, is being used in production)
Dec 12 2023
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 12 December 2023 at 11:05:30 UTC, Martyn wrote:

 On Monday, 11 December 2023 at 18:39:22 UTC, IGotD- wrote:

 ...

 Future games will have GC whenever you like it or not. Games 
 are becoming more and more complex the benefit of having GC is 
 obvious.


 It is a misconception that having no Garbage Collector is bad 
 or dangerous or silly. It is also misleading that (games 
 programming specifically) will "benefit using a Garbage 
 Collector as games get more complex."

 Game programmers NEED CONTROL OF MEMORY. The only time I can 
 see this ever changing is if hardware evolves at a faster rate 
 than software. The reality is the opposite. game programmers 
 have to squeeze every inch out of the hardware. Of course, I am 
 referring to the AAA titles.


Isn't everyone writing AAA games using some form of game engine? 
Which AAA is written from scratch code?
Dec 16 2023
prev sibling parent reply Martyn <martyn.developer googlemail.com> writes:
On Thursday, 7 December 2023 at 14:21:51 UTC, Paulo Pinto wrote:

 On Thursday, 7 December 2023 at 14:08:03 UTC, Martyn wrote:

 On Thursday, 7 December 2023 at 11:50:44 UTC, Paulo Pinto 
 wrote:

 On Thursday, 7 December 2023 at 10:42:45 UTC, Martyn wrote:

 On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:



 The Mike Acton that ended up working for Unity, as part of 




 Yes (I didn't know he had left unity, tho)


 My remark was to made the point that regardless of his opinion 
 on data-oriented design, he nowadays uses a programming 
 language that is pretty much as OOP as Java is, even including 
 the latest influences from FP that permeate both languages, as 
 features are part of the OOP type system of both languages, 
 e.g. lambdas are represented by specific classes/interfaces.


I know it was. I originally chose to ignore it, but hey... you 
got me.

I cannot speak for Mike Acton. I cannot comment why he joined 
Unity, either. On top of this - I am not a "Unity developer"

My guess is, after years at Isomniac Games, he saw a new 
opportunity and a challenge.. and accepted it. I dont think he 

about OOP... it is far deeper than that! He is an Games Engine 
Developer/Lead.



have been used for certain in-house editing tools.. perhaps even 
HTML/javascript in places.

This does not mean his views are no longer valid, especially his 
2014 talk.

But I get it. The point of your reply is to put me in my place. 
That "Gotchya!" moment where everybody laughs.

You win... I mean.. whatever.

I prefer to leave that crap at the door. If Mike has changed 
views on certain things then I'm interested in hearing about 
them. Even John Carmack has spoken about using Python in recent 
years. It all depends what they are doing with them, I suppose.


good for him. Sounds like he put a lot of effort into that 
project and does not want to walk away from it. Again.. point?
Dec 07 2023
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 7 December 2023 at 15:53:35 UTC, Martyn wrote:



 Even John Carmack has spoken about using Python in recent 
 years. It all depends what they are doing with them, I suppose.


 then good for him. Sounds like he put a lot of effort into that 
 project and does not want to walk away from it. Again.. point?



John Carmack, three days ago:

"I was helping with some C code yesterday and got a bunch of 
errors — I hadn’t put a semicolon on any of the lines. I’m 
writing too much python code!" [1]

:-P

[1] https://twitter.com/ID_AA_Carmack/status/1731689997688832052
Dec 07 2023
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 7 December 2023 at 17:23:28 UTC, Paolo Invernizzi 
wrote:

 On Thursday, 7 December 2023 at 15:53:35 UTC, Martyn wrote:



 Even John Carmack has spoken about using Python in recent 
 years. It all depends what they are doing with them, I suppose.


 then good for him. Sounds like he put a lot of effort into 
 that project and does not want to walk away from it. Again.. 
 point?



 John Carmack, three days ago:

 "I was helping with some C code yesterday and got a bunch of 
 errors — I hadn’t put a semicolon on any of the lines. I’m 
 writing too much python code!" [1]

 :-P

 [1] https://twitter.com/ID_AA_Carmack/status/1731689997688832052


Because Carmack moved into AI research business.. and there is 
Python is the only real player.
Dec 07 2023
parent reply bachmeier <no spam.net> writes:
On Thursday, 7 December 2023 at 18:41:04 UTC, Sergey wrote:


 Because Carmack moved into AI research business.. and there is 
 Python is the only real player.


Depends which part. You could probably get rid of Python easier 
than C++. If you're analyzing data, you're probably using Python. 
Tensorflow, on the other hand, is mostly written in C++.
Dec 07 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 7 December 2023 at 20:21:30 UTC, bachmeier wrote:

 On Thursday, 7 December 2023 at 18:41:04 UTC, Sergey wrote:


 Because Carmack moved into AI research business.. and there is 
 Python is the only real player.


 Depends which part. You could probably get rid of Python easier 
 than C++. If you're analyzing data, you're probably using 
 Python. Tensorflow, on the other hand, is mostly written in C++.


"If you're analyzing data, you're probably using Python." - which 
in turn is probably calling some C/Fortran code.
Dec 07 2023
prev sibling parent Nick Treleaven <nick geany.org> writes:
On Thursday, 7 December 2023 at 20:21:30 UTC, bachmeier wrote:

 On Thursday, 7 December 2023 at 18:41:04 UTC, Sergey wrote:


 Because Carmack moved into AI research business.. and there is 
 Python is the only real player.


 Depends which part. You could probably get rid of Python easier 
 than C++. If you're analyzing data, you're probably using 
 Python. Tensorflow, on the other hand, is mostly written in C++.


Mojo seems to be another potential competitor to D that will get 
a head-start by (aiming at) being a superset of Python with 
systems programming features.

"Our overall mission is to unify AI software and we can’t do that 
without a unified language that can scale across the AI 
infrastructure stack. That said, we don’t plan to stop at AI—the 
north star is for Mojo to support the whole gamut of 
general-purpose programming over time."
Dec 07 2023
prev sibling parent Martyn <martyn.developer googlemail.com> writes:
On Thursday, 7 December 2023 at 17:23:28 UTC, Paolo Invernizzi 
wrote:

 On Thursday, 7 December 2023 at 15:53:35 UTC, Martyn wrote:



 Even John Carmack has spoken about using Python in recent 
 years. It all depends what they are doing with them, I suppose.


 then good for him. Sounds like he put a lot of effort into 
 that project and does not want to walk away from it. Again.. 
 point?



 John Carmack, three days ago:

 "I was helping with some C code yesterday and got a bunch of 
 errors — I hadn’t put a semicolon on any of the lines. I’m 
 writing too much python code!" [1]

 :-P

 [1] https://twitter.com/ID_AA_Carmack/status/1731689997688832052


Gave me a chuckle.. needed that.
Dec 08 2023
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace C++ 
 and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


 Java is my first and forever love in the world of programming 
 languages. I don't mind the hate it gets. ☕


To be honest I'm not up to date on Java, maybe its better now 
than it was 10-15 years ago when I wrote in it
Dec 15 2023
parent Hors <q q.com> writes:
On Friday, 15 December 2023 at 15:59:59 UTC, Imperatorn wrote:

 On Wednesday, 6 December 2023 at 21:58:41 UTC, Andrew wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:

 Is there really any other language than D that can replace 
 C++ and Rust?

 Go is good, but very tedious to write.
 Zig, Odin, Beef, V and Jai are not production ready 
 (according to the creators themselves).


 alternative. Forget about Java, Kotlin or whatever.



 I don't think Rust is the answer, for many reasons.

 Well, maybe Nim would actually be a serious alternative, 
 however, I'm kinda used to the C-style.

 Any feedback?


 Java is my first and forever love in the world of programming 
 languages. I don't mind the hate it gets. ☕


 To be honest I'm not up to date on Java, maybe its better now 
 than it was 10-15 years ago when I wrote in it


It's better of course, but  their website still recommends java 
8, and the big download button downloads java 8. If you develop 
with newer java and older java users tries to run it, theyll just 
get virtual machine error without any other detail They literally 
killed their own slogan 'write once run everywhere'
Dec 15 2023
prev sibling next sibling parent reply Gary Chike <chikega gmail.com> writes:
On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:


 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


Interesting since it's my understanding that 
[Odin](https://odin-lang.org/showcase/embergen/) was used to 
write the commercial product 
[EmberGen](https://jangafx.com/software/embergen/).
Dec 16 2023
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 16 December 2023 at 18:31:23 UTC, Gary Chike wrote:

 On Sunday, 26 November 2023 at 17:52:24 UTC, Imperatorn wrote:


 Zig, Odin, Beef, V and Jai are not production ready (according 
 to the creators themselves).


 Interesting since it's my understanding that 
 [Odin](https://odin-lang.org/showcase/embergen/) was used to 
 write the commercial product 
 [EmberGen](https://jangafx.com/software/embergen/).


Ok, what I did was I joined the communities and asked "Is x 
production ready", and all of them basically said no. But I guess 
it's a matter of perspective.
Dec 20 2023
prev sibling parent Mike Parker <aldacron gmail.com> writes:
This thread long ago veered off topic and rant fest. It's past 
time to close it. Any further posts will be deleted. Thanks.
Dec 23 2023