www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - About whether D / rust / golang can be popular.

reply zoujiaqing <zoujiaqing gmail.com> writes:
Whether a programming language can be popular depends on what?

I think there are two important points, that is, killing skills 
and availability. At the same time pay attention to shortcomings.

I'll talk about my opinion today.



Must kill skill: Goroutine
Availability: the standard library is powerful. IDE powerful. 
High GC efficiency. friendly debugging tracking tool. It is 
convenient to realize various functions based on standard 
library. Have practical pprof and other tools. But language 
features are too few.



Must kill skill: Memory Security
Availability: The standard library is very general. IDE powerful. 
friendly debugging tracking tool. A variety of language features, 
and will be based on popularity of new features, such as await. 
Have practical pprof and other tools. Development efficiency of 
using rust is relatively low.



Must kill skill: It looks good?
Availability: standard library is poor. Bad IDE. GC efficiency is 
low. Lack of friendly debugging tracking tools. Lack of pprof and 
other practical tools. Although the language features many but 
can not add popular practical features, such as await.



D language must improve usability if it is to become popular!
Nov 25 2020
next sibling parent reply Daniel Kozak <kozzi11 gmail.com> writes:
On Thu, Nov 26, 2020 at 6:50 AM zoujiaqing via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 ...

 Must kill skill: Goroutine
 Availability: the standard library is powerful. IDE powerful.
 High GC efficiency. friendly debugging tracking tool. It is
 convenient to realize various functions based on standard
 library. Have practical pprof and other tools. But language
 features are too few.


I agree. Google uses golang quite a lot, so it makes sense google helped
with tooling for it.
What IDE do you mean? (GoLand?)



 Must kill skill: It looks good?


Maybe metaprograming?



 Availability: standard library is poor. Bad IDE. GC efficiency is
 low. Lack of friendly debugging tracking tools. Lack of pprof and
 other practical tools. Although the language features many but
 can not add popular practical features, such as await.


Standard library is very general and good enought. Bad IDE (thats true). GC
efficiency is
OK in almost all cases so I woud not say low here because it is not true.

Lack of friendly debugging tracking tools. Lack of pprof and other
practical tools.

I do not use these much so can say if thats true or not, but I would think
they are similar with rust

Although the language features many but  can not add popular practical
features, such as await.

There is not need for await as a language feature maybe have it as a library







 D language must improve usability if it is to become popular!
Nov 26 2020
parent IGotD- <nise nise.com> writes:
On Thursday, 26 November 2020 at 08:57:18 UTC, Daniel Kozak wrote:

 Maybe metaprograming?


This definitely. When I program C++ I kind of avoid meta 
programming because I know I will run into trouble or don't 
exactly know how to do it. In D it's more like "hey I can do this 
with meta programming" and then I just do it, this while I'm an 
amateur when it comes to D.
Nov 26 2020
prev sibling next sibling parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:

 Whether a programming language can be popular depends on what?


I think many factors:

1. Timing and luck.
2. Highly innovative new feature - C was portable assembler, Java 
was safe and Java programs could run on multiple platforms, Go 
had goroutines, Rust has static memory analysis, D has easy to 
use templates and CTFE.
3. Backing by commercial organizations that are able to pump 
money and resources at it - JavaScript is an example, but Go 
without Google backing would not have succeeded, C++ has had 
enormous resources put on its development, Python has had 

4. Support that programmers need in the real world - such as 
IDEs, debuggers, libraries etc.


D and Lua are perhaps two successful languages (i.e. sizeable 
users) that do not have proper financial support and resources. 
So development is dependent on few individuals spending unpaid 
time on it.

In my humble opinion, D had got it right as language before Rust 
and Go came along.
Go did GC better. And Rust does systems programming better.
Nov 26 2020
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:

 Whether a programming language can be popular depends on what?

 I think there are two important points, that is, killing skills 
 and availability. At the same time pay attention to 
 shortcomings.

 I'll talk about my opinion today.



 Must kill skill: Goroutine
 Availability: the standard library is powerful. IDE powerful. 
 High GC efficiency. friendly debugging tracking tool. It is 
 convenient to realize various functions based on standard 
 library. Have practical pprof and other tools. But language 
 features are too few.



 Must kill skill: Memory Security
 Availability: The standard library is very general. IDE 
 powerful. friendly debugging tracking tool. A variety of 
 language features, and will be based on popularity of new 
 features, such as await. Have practical pprof and other tools. 
 Development efficiency of using rust is relatively low.



 Must kill skill: It looks good?
 Availability: standard library is poor. Bad IDE. GC efficiency 
 is low. Lack of friendly debugging tracking tools. Lack of 
 pprof and other practical tools. Although the language features 
 many but can not add popular practical features, such as await.



 D language must improve usability if it is to become popular!


I assume every developer has another opinion what is the most 
import thing missing in D.
(I never ever faced any performance issues with GC and I am super 
satisfied with Visual Studio Code. As I also not used async/await 
in other languages a lot, I also do not miss it in D). But I see 
and understand from your view these points are high import.


 From my point of view the most important thing is to get the 
community (all of us) to speak more loud about D. Advertise D, 
create more blogs, try to get D in the company's they are 
working...

(And if I have a wish free, RSA digital signature verification 
natively implemented in phobos would be really great :) ).

Kind regards
Andre
Nov 26 2020
parent ddcovery <antoniocabreraperez gmail.com> writes:
On Thursday, 26 November 2020 at 09:19:48 UTC, Andre Pany wrote:


 I assume every developer has another opinion what is the most 
 import thing missing in D.
 (I never ever faced any performance issues with GC and I am 
 super satisfied with Visual Studio Code.


About GC, I use D as scripting language mainly, and never noticed 
GC problems.  GC is, indeed, a must for scripting (Thanks D for 
GC)

Integration in VSCode :

- "reflection/autocomplete": This is one of the most appreciated 
features in development IDEs and a really good way to learn about 
the language and it's existing libraries (learn on demand :-) ).  
This is a must because the competence with other "similar" 
productive languages that offer a powerful tool chain (Not only 
Rust or Go, I consider Python and Typescript natural D 
competitors).

- Debugging support:  how can I inspect structured data/objects 
friendly? printing to the console or assigning properties to 
temporal vars is not a productive way:  may be a good tutorial 
about how to inspect in D using VSCode will be appreciated from 
experienced D developers (Linux, pls :-) )... in my opinion, this 
is a next DConf must!!! (Like the one in 2014).

I know I'm very reiterative with this features (you can find me 
in other forum posts arguing about the same)... In my very 
personal opinion, D usage will grow as soon as it will integrate 
on VSCode IDE as well as typescript does. I wish I had the time 
and experience to help on this particular point.


 From my point of view the most important thing is to get the 
 community (all of us) to speak more loud about D. Advertise D, 
 create more blogs, try to get D in the company's they are 
 working...


I agree

Personally, I add references to D using any excuse :-) (in 
spanish, sorry)

i.e.:
https://es.quora.com/Por-qu%C3%A9-la-mayor%C3%ADa-de-los-desarrolladores-estudian-solo-lenguajes-muy-simples-como-JavaScript-y-Python-en-lugar-de-aprender-un-lenguaje-verdadero-como-C-2/answer/Antonio-Cabrera-52
Nov 26 2020
prev sibling next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:


 Must kill skill: It looks good?
 Availability: standard library is poor. Bad IDE. GC efficiency 
 is low. Lack of friendly debugging tracking tools. Lack of 
 pprof and other practical tools. Although the language features 
 many but can not add popular practical features, such as await.


Isnt await just syntactic sugar for a promise/future?

If you can provide an example of what await should expand into 
then I might be able to add it to my experimental D compiler and 
you could then write a DIP.
Nov 26 2020
parent reply Jacob Carlborg <doob me.com> writes:
On Thursday, 26 November 2020 at 09:49:51 UTC, Ola Fosheim 
Grostad wrote:


 Isnt await just syntactic sugar for a promise/future?


No, not really, but it's used together with promises or they're 
used under the hood.


 If you can provide an example of what await should expand into 
 then I might be able to add it to my experimental D compiler 
 and you could then write a DIP.


Async/await is basically a coroutine. It allows a function to be 
suspended and resumed. Here's an example of how the code could 
look like in D:

async int foo()
{
     await sleep(1.seconds); // simulate work that takes long time
     writeln("foo");
     return 1;
}

async int bar()
{
     writeln("bar");
     return 2;
}

async void main()
{
     auto a = foo();
     auto b = bar();

     writeln("main");
     writeln(await a + await b);
}

The output of the above would be:

bar
main
foo
3

The control flow is something like this:

1. `foo` is called
2. `foo` is awaiting for `sleep`
3. `sleep` returns a promise which is not fulfilled
4. This causes `foo` to suspend (return) and control comes back 
to `main`
5. `bar` is called
6. `bar` has no suspension points (awaits) so this is more or 
less a synchronous function
7. "bar" is printed
8. `bar` returns a fulfilled promise with the value `2`
9. Control comes back to `main`
10. "main" is printed
11. `main` awaits `a`. If the `a` promise is not fulfilled at 
this point `main` is suspended
12. `foo` is resumed at some point in the future
13. "foo" is printed
14. `foo` returns a fulfilled promise with the value `1`
15. `main` is now resumed since `a` has been fulfilled
16. `main` awaits `b`
17. `b` is already fulfilled, which means `main` doesn't have to 
suspend
18. The addition is performed
19. "3" is printed

I'm not entirely sure on when `foo` will be resumed. Probably 
decided by a scheduler in the runtime.

To have the full experience of async/await, an event loop in the 
runtime is necessary and non-blocking IO.

When a function is suspended, all its state (stack and registers) 
need to be saved. When it's later resumed, the state need to be 
restored. I'm not entirely sure how async/await functions are 
different from fibers, which already exists in the D runtime.

--
/Jacob Carlborg
Nov 26 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 14:18:55 UTC, Jacob Carlborg 
wrote:

 On Thursday, 26 November 2020 at 09:49:51 UTC, Ola Fosheim 
 Grostad wrote:


 Isnt await just syntactic sugar for a promise/future?


 No, not really, but it's used together with promises or they're 
 used under the hood.


 If you can provide an example of what await should expand into 
 then I might be able to add it to my experimental D compiler 
 and you could then write a DIP.


 Async/await is basically a coroutine. It allows a function to 
 be suspended and resumed. Here's an example of how the code 
 could look like in D:


Ok, we need something that respects shared/nonshared. If 
aync/await involves multiple threads then we need something 
principled.

Maybe some runtime level thing that can offload computations but 
is as easy to use as await. Perhaps even offload to the GPU.

But I guess people want it for I/O.

Clearly a case where a library solution has to come first.


 When a function is suspended, all its state (stack and 
 registers) need to be saved. When it's later resumed, the state 
 need to be restored.


This should be possible with LLVM stop points.
Nov 26 2020
parent reply Jacob Carlborg <doob me.com> writes:
On 2020-11-26 15:55, Ola Fosheim Grostad wrote:


 Ok, we need something that respects shared/nonshared. If aync/await 
 involves multiple threads then we need something principled.


That varies between implementations. You can either do single threading. 
Or have multiple threads (as many as the computer has cores) with one 
event loop per thread. Each async function can only be executed on a 
single thread. Or multiple threads with a single event loop and the 
async functions can run on multiple threads. That is, run on one thread, 
be suspended and be resumed on another thread.

For example, Erlang was initially only single threaded. In 2006 it 
started to take advantage of multi-core.

Go will automatically create a new thread if calling a C function or a 
blocking system call.


 Maybe some runtime level thing that can offload computations but is as 
 easy to use as await. Perhaps even offload to the GPU.
 
 But I guess people want it for I/O.


Yes, that's the main reason. If you don't have anything to wait for, 
there's not much point in suspending a function.


 This should be possible with LLVM stop points.


Yes. C++20 got support for coroutines, which also means support in LLVM.

-- 
/Jacob Carlborg
Nov 26 2020
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 18:27:25 UTC, Jacob Carlborg 
wrote:

 Yes. C++20 got support for coroutines, which also means support 
 in LLVM.


Interestingly they chose to not implement a ready-made version of 
coroutines, but the building blocks to do so. At least that is my 
understanding. Looks intriguing. It will be interesting to see 
what kind of libraries people build with it.
Nov 26 2020
parent reply JohnT <hon afadsf.com> writes:
...
I already raised similar sentiments. There are lot of posts where 
community is asking the D maintainers. They might not be 
interested and keep silent. I wonder why
a. why other upcoming langugages like crystal/nim/even zig has 
more contributors.(i meant they are good languages but they are 
more welcoming and have more news)
b. I thought after walter's talk on memory corruption, there will 
be a big buzz on D as a safe and easy alternative to rust. I 
didnt see a single post on HN/reddit.
c. AFAIK the fastest file system in world is written in D. Isnt 
this enought for everyone to convince(am not sure if its a mix of 
c++ and D).
d. I wish andrei/walter/others bring the community together and 
create a goal.
e. There is no other way other than challenging Rust/Go with 
features and benchmarks. Since we dont have corporate funds, we 
have to do haka dance. I wonder why Facebook didnt adopt it more 
when Andrei was there. Not sure what all issues they saw.
There is lot of selflishness here. I cant wait for 15-20m of 
build for every single line of C++ code change I make. I want a 
better language. Hope the maintainers come out of their feature 
parity race, frog in well attitude and make D a big success. 
Without community there is nothing. You can have a dogmatic goal 
like go, but you need one. Hope I dont have to start liking rust.

https://forum.dlang.org/thread/wkzwturzlnnhfpuplyrr forum.dlang.org
Nov 26 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 19:17:25 UTC, JohnT wrote:

 d. I wish andrei/walter/others bring the community together and 
 create a goal.


I think it would be better if the goals come from the community, 
bottom up builds a better social fabric. If it is top down 
everything falls on one person, and that is not as efficient.

Could be ARC, could be async/await, but it has to be something 
that can be completed within 6 months. Too ambitious goals tend 
to fizzle out,



 e. There is no other way other than challenging Rust/Go with 
 features and benchmark


The better way is to find goals that are different from Rust/Go.
Nov 26 2020
parent reply JohnT <hon afadsf.com> writes:
 The better way is to find goals that are different from Rust/Go.


Yes I agree. Atleast they come up with defined goals. Not sure if 
Andrei itself is actively involved. Btw, why cant weka sponsor D. 
They seem to be making money.
Whether D suceeds or not thats not in our hands, but we should do 
everything to make it possible.

https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why?share=1
Nov 26 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 20:21:21 UTC, JohnT wrote:

 Yes I agree. Atleast they come up with defined goals. Not sure 
 if Andrei itself is actively involved. Btw, why cant weka 
 sponsor D. They seem to be making money.
 Whether D suceeds or not thats not in our hands, but we should 
 do everything to make it d .

 https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why?share=1


I don't really think being a replacement language should be a 
goal, people generally just look for the best option for a 
specific use case. But there seems to be some motion towards 
being better for soft realtime. So basically, build consensus 
around that, and identify the missing pieces...
Nov 26 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 21:04:05 UTC, Ola Fosheim 
Grostad wrote:

 I don't really think being a replacement language should be a 
 goal, people generally just look for the best option for a 
 specific use case. But there seems to be some motion towards 
 being better for soft realtime. So basically, build consensus 
 around that, and identify the missing pieces...


Also, remove outdated stuff. Like, don't link to abandonware from 
dlang.org, it gives a graveyard feeling. Are anyone dveloping 
Dash? It is listed as games sofware that use D.
Nov 26 2020
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 18:27:25 UTC, Jacob Carlborg 
wrote:

 That varies between implementations. You can either do single 
 threading. Or have multiple threads (as many as the computer 
 has cores) with one event loop per thread. Each async function 
 can only be executed on a single thread. Or multiple threads 
 with a single event loop and the async functions can run on 
 multiple threads. That is, run on one thread, be suspended and 
 be resumed on another thread.


Ok Jacob, so I got this idea: maybe it would be possible to have 
something like await as a gateway for temporary sharing of 
memory? Basically a multithreaded version of scope?

Just an idle thought, but maybe D could do something interesting 
with it.
Nov 27 2020
prev sibling parent zoujiaqing <zoujiaqing gmail.com> writes:
On Thursday, 26 November 2020 at 14:18:55 UTC, Jacob Carlborg 
wrote:

 On Thursday, 26 November 2020 at 09:49:51 UTC, Ola Fosheim 
 Grostad wrote:


 Isnt await just syntactic sugar for a promise/future?


 No, not really, but it's used together with promises or they're 
 used under the hood.


 If you can provide an example of what await should expand into 
 then I might be able to add it to my experimental D compiler 
 and you could then write a DIP.


 Async/await is basically a coroutine. It allows a function to 
 be suspended and resumed. Here's an example of how the code 
 could look like in D:

 async int foo()
 {
     await sleep(1.seconds); // simulate work that takes long 
 time
     writeln("foo");
     return 1;
 }

 async int bar()
 {
     writeln("bar");
     return 2;
 }

 async void main()
 {
     auto a = foo();
     auto b = bar();

     writeln("main");
     writeln(await a + await b);
 }

 The output of the above would be:

 bar
 main
 foo
 3

 The control flow is something like this:

 1. `foo` is called
 2. `foo` is awaiting for `sleep`
 3. `sleep` returns a promise which is not fulfilled
 4. This causes `foo` to suspend (return) and control comes back 
 to `main`
 5. `bar` is called
 6. `bar` has no suspension points (awaits) so this is more or 
 less a synchronous function
 7. "bar" is printed
 8. `bar` returns a fulfilled promise with the value `2`
 9. Control comes back to `main`
 10. "main" is printed
 11. `main` awaits `a`. If the `a` promise is not fulfilled at 
 this point `main` is suspended
 12. `foo` is resumed at some point in the future
 13. "foo" is printed
 14. `foo` returns a fulfilled promise with the value `1`
 15. `main` is now resumed since `a` has been fulfilled
 16. `main` awaits `b`
 17. `b` is already fulfilled, which means `main` doesn't have 
 to suspend
 18. The addition is performed
 19. "3" is printed

 I'm not entirely sure on when `foo` will be resumed. Probably 
 decided by a scheduler in the runtime.

 To have the full experience of async/await, an event loop in 
 the runtime is necessary and non-blocking IO.

 When a function is suspended, all its state (stack and 
 registers) need to be saved. When it's later resumed, the state 
 need to be restored. I'm not entirely sure how async/await 
 functions are different from fibers, which already exists in 
 the D runtime.

 --
 /Jacob Carlborg


Yes! await is very good.
Dec 06 2020
prev sibling next sibling parent reply Guillaume Piolat <first.name guess.com> writes:
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:

 Whether a programming language can be popular depends on what?

 I think there are two important points, that is, killing skills 
 and availability. At the same time pay attention to 
 shortcomings.



The _one_ factor that made C++ win against its competition - 
despite its shortcomings - is by far that it could already 
compile your C code. So it's an easier sell if you can just 
change the compiler.

You can't convince to change language someone who has already an 
existing codebase, it would just make life worse in most of cases.
Nov 26 2020
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 26 November 2020 at 11:06:11 UTC, Guillaume Piolat 
wrote:

 The _one_ factor that made C++ win against its competition - 
 despite its shortcomings - is by far that it could already 
 compile your C code. So it's an easier sell if you can just 
 change the compiler.

 You can't convince to change language someone who has already 
 an existing codebase, it would just make life worse in most of 
 cases.


This could also be the killer feature for D, as Atila has said. 
While one can't yet automatically generate D headers for an 
arbitrary CPP codebase, I don't think that either Rust or Go are 
as far in C++ interop as D currently is.
Nov 26 2020
parent reply Jacob Carlborg <doob me.com> writes:
On Thursday, 26 November 2020 at 13:01:28 UTC, Dukc wrote:


 This could also be the killer feature for D, as Atila has said. 
 While one can't yet automatically generate D headers for an 
 arbitrary CPP codebase, I don't think that either Rust or Go 
 are as far in C++ interop as D currently is.


Swift is going for C++ interoperability as well [1]. I assume 
they're going to do it the same way as the C interoperability, by 
using the Clang compiler.

[1] 
https://github.com/apple/swift/blob/main/docs/CppInteroperabilityManifesto.md
Nov 26 2020
parent Daniel Kozak <kozzi11 gmail.com> writes:
On Thu, Nov 26, 2020 at 2:15 PM Jacob Carlborg via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On Thursday, 26 November 2020 at 13:01:28 UTC, Dukc wrote:


 This could also be the killer feature for D, as Atila has said.
 While one can't yet automatically generate D headers for an
 arbitrary CPP codebase, I don't think that either Rust or Go
 are as far in C++ interop as D currently is.


 Swift is going for C++ interoperability as well [1]. I assume
 they're going to do it the same way as the C interoperability, by
 using the Clang compiler.

 [1]

 https://github.com/apple/swift/blob/main/docs/CppInteroperabilityManifesto.md



https://wiki.dlang.org/Calypso
Nov 26 2020
prev sibling next sibling parent reply =?UTF-8?B?Um9iZXJ0IE0uIE3DvG5jaA==?= <robert.muench saphirion.com> writes:
On 26 Nov 2020 at 06:46:59 CET, "zoujiaqing" <zoujiaqing gmail.com> wrote:


 Whether a programming language can be popular depends on what?


Mostly non-technical aspects...



 Must kill skill: Goroutine


* Stability with minimum breaking changes over a long time
* Development in the large and long-term maintainability


 Availability: the standard library is powerful. IDE powerful. 
 High GC efficiency. friendly debugging tracking tool. It is 
 convenient to realize various functions based on standard 
 library.


* Big eco-system
* Super simple setup and out-of-the-box experience
* Cross-compilation


  But language  features are too few.


That's a big plus, if not the biggest. There are not X ways to do thing, but
mostly one way. Go code is totally boring and that's good.

We considered D for our next big project but will not use it, even I like many
the technical aspects. We will use Go, because you just get a lot of stuff
done right and straight forward.



 Must kill skill: Memory Security


* Super pedantic compiler
* Super pedantic standard library
* Big eco-system
* Super simple setup and out-of-the-box experience


 Availability: The standard library is very general. IDE powerful. 
 friendly debugging tracking tool. A variety of language features, 
 and will be based on popularity of new features, such as await. 
 Have practical pprof and other tools. Development efficiency of 
 using rust is relatively low.


I wouldn't second that. If you want to go for systems programming, IMO Rust is
the way to go.



 Must kill skill: It looks good?
 Availability: standard library is poor. Bad IDE. GC efficiency is 
 low. Lack of friendly debugging tracking tools. Lack of pprof and 
 other practical tools. Although the language features many but 
 can not add popular practical features, such as await.


With limited resources focus becomes key. Focusing a volunteer group on some
goal is very hard and requires good community management.

D is too fragmented and unpredictable, which is a No-Go if you want to use it
for anything serious. It was a hard way to come to this conclusion, because I
really like many aspects of it.

And, D is a huge language, it's far from simple.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Nov 26 2020
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 11:16:09 UTC, Robert M. Münch


 Must kill skill: Memory Security


 * Super pedantic compiler
 * Super pedantic standard library
 * Big eco-system


Really? My take is that it is too small and makes C++ frameworks 
ou of reach.


 With limited resources focus becomes key. Focusing a volunteer 
 group on some goal is very hard and requires good community 
 management.


It is important to attract developers with a shared focus, then 
you need less management and can build on consensus.

All this talk of attracting more random developers is worrisome, 
more is worse if it prevents formation of consensus...


 And, D is a huge language, it's far from simple.


It is large because it has many overlapping features, the core 
functionality is not so big.
Nov 26 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 26 November 2020 at 11:16:09 UTC, Robert M. Münch 
wrote:

 With limited resources focus becomes key. Focusing a volunteer 
 group on some goal is very hard and requires good community 
 management.

 D is too fragmented and unpredictable, which is a No-Go if you 
 want to use it for anything serious. It was a hard way to come 
 to this conclusion, because I really like many aspects of it.

 And, D is a huge language, it's far from simple.


If I would be a manager and to decide which language and tools to 
use in a project, I would look at D and think it is nice but what 
would scared me off is how the project is managed and many 
uncertainties for the future. The D project is in particular bad 
at communicating to the audience what to expect from the language 
in the near future. This makes D look more like a research 
language than a language that is ready for being used in real 
products.

Without enough feedback from actual commercial applications, the 
D project doesn't really know what programmers are looking for 
and instead it becomes some kind of pseudo scientific project 
which is obvious reading this forum. A lot of talk about 
compilers in general and different technology but little "how do 
I do X in D".
Nov 26 2020
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 26 November 2020 at 11:56:15 UTC, IGotD- wrote:

 Without enough feedback from actual commercial applications, 
 the D project doesn't really know what programmers are looking 
 for and instead it becomes some kind of pseudo scientific 
 project which is obvious reading this forum. A lot of talk 
 about compilers in general and different technology but little 
 "how do I do X in D".


I dont think this is the case. You are just reading the general 
forum and not the learn forum :).
Nov 26 2020
parent reply IGotD- <nise nise.com> writes:
On Thursday, 26 November 2020 at 12:01:57 UTC, Ola Fosheim 
Grostad wrote:

 I dont think this is the case. You are just reading the general 
 forum and not the learn forum :).


I read both but the activity in the learn forum is pretty low.
Nov 26 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/11/2020 3:45 AM, IGotD- wrote:

 On Thursday, 26 November 2020 at 12:01:57 UTC, Ola Fosheim Grostad wrote:

 I dont think this is the case. You are just reading the general forum 
 and not the learn forum :).


 
 I read both but the activity in the learn forum is pretty low.


Of the many places I monitor for questions, Discord is the most active.
Nov 26 2020
parent aberba <karabutaworld gmail.com> writes:
On Thursday, 26 November 2020 at 15:27:22 UTC, rikki cattermole 
wrote:

 On 27/11/2020 3:45 AM, IGotD- wrote:

 On Thursday, 26 November 2020 at 12:01:57 UTC, Ola Fosheim 
 Grostad wrote:

 I dont think this is the case. You are just reading the 
 general forum and not the learn forum :).


 
 I read both but the activity in the learn forum is pretty low.


 Of the many places I monitor for questions, Discord is the most 
 active.


That's due to the kind of people olin the Discord vs the Dlang 
Slack...the discord is like Macau...if you know what I mean 😜
Nov 27 2020
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:

 Whether a programming language can be popular depends on what?

 I think there are two important points, that is, killing skills 
 and availability. At the same time pay attention to 
 shortcomings.

 I'll talk about my opinion today.



 Must kill skill: It looks good?


It has four main advantages:

- Metaprogramming. In C/C++ you're limited to what the 
precompiler can do, but D's metaprogramming capabilities are 
almost other worldly, save for a few small stuff. D currently 
doesn't have metaprogramming support for attributes, which could 
solve the issue of attribute hell, especially with containers.
- Fast compile times with the performance of C/C++. Even with DMD 
and using the GC, it not only outclasses most scripting 
languages, but while compiling faster than C/C++. Once someone 
takes the time to optimize the D code by reducing GC use and 
using some compiler that has better optimization like LDC, it 
becomes nearly indistinguishable from C/C++. This, alongside its 
super-easy interoperability with other languages, makes the 
language a good candidate for a low-level scripting language.
- Interoperability. It's mostly binary compatible with C and C++, 
almost seamlessly can load their libraries, etc. I don't know 
what's the current state of D's DLL support, if anything this is 
a point where it must get better. D's main advantage should be 
either integration into other projects, or integrating 
preexisting ones into a D project.
- Multiple supported paradigms. Single paradigm programming is a 
pitfall, which leads to forcing the same solution to every 
problem, which in turn will lead to over-complicated codes, like 
how "enterprise" devs often do object orientation on everything. 
While functional programming is very promising, in itself can't 
solve all the programming problems, and can lead to performance 
issues from frequent data copying.


 Availability: standard library is poor.


It actually starts to get better, and since the language easily 
interoperates with others, anybody can port C or C++ headers to 
D. My current gripe is the mediocre XML support currently on D. 
The current one in the standard library


 Bad IDE.


It's okayish, but there's a lot of potential to growth.
- For the code-d team: Do something about the lack of refactoring 
support! It's super annoying to rename each thing individually, 
since VSCode's "change all" feature is too overboard and only 
works within a single file.
- For the Visual-D team: Please, add some integrated dub support! 
It's the default package manager of D, and without it you're 
destined to deal with dependency hell.

Due to the sheer power of the metaprogramming feature, any IDE 
plugin must at one point integrate the DMD frontend. That's 
probably the only way to get the whole metaprogramming fully 
cooperating with IDEs.


 GC efficiency is low.


Not anymore, as the GC is now multi-threaded. ` nogc` and 
`nothrow` attributes are must haves at functions that are 
time-critical and where they're applicable. Reducing memory 
allocations is a good practice, no `malloc` will speed up your 
application if you need to allocate memory thousands of times in 
a short time, while you could work on the same preallocated 
memory location.


 Lack of friendly debugging tracking tools.


Visual Studio works well as a debugger, but memory access 
violations are a bit hard to trace down sometimes. Breakpoints do 
work however.


 Lack of pprof and other practical tools.


It is in a dire need of a GUI editing tool, but I've made one for 
my own graphics engine. I'm planning on making another one, might 
be a VSCode plugin, if not it'll be a standalone app. That will 
be a pretty big breakthrough, however I don't know yet what GUI 
framework should I target. Maybe I can even add D export 
functions to a preexisting one.



 D language must improve usability if it is to become popular!


D must become even stronger in fields it's already strong, and 
the community must fix the stuff where it's currently weaker. 
I've outsourced many of the components of my game engine to 
external libraries, both to allow easier unit testing (which 
ultimately killed the integrated collections - it was quite 
difficult) and to allow others to use them. Currently most of D's 
issues can be traced back to a weaker community, but this is 
slowly changing.
Nov 26 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 26 November 2020 at 05:46:59 UTC, zoujiaqing wrote:

 Whether a programming language can be popular depends on what?




 Must kill skill: It looks good?
 Availability: standard library is poor. Bad IDE. GC efficiency 
 is low. Lack of friendly debugging tracking tools. Lack of 
 pprof and other practical tools. Although the language features 
 many but can not add popular practical features, such as await.




 D language must improve usability if it is to become popular!


Its soo funny though 😂. D be like "Why you do me that?"


Personally I think D is great for most stuff... I can't 
personally point anything blocking my use case for D at its 
current state (not to say that things shouldn't be improved)... 
except embedded programming which is being worked on.


You can to look at the community from these three:


1. The C/C++/?? veterans. They know their stuff and tooling. They 
most likely use emacs or vim and are happy with pointing Cli 
tools like gdb at the binary to debug stuff. It so happens that 
most of the core contributors belong in this group. To them, work 
on the compiler, memory safety, nogc, technical correctness, deep 
metaprogramming wizardry, and related areas are more important. 
They're not the type to develop dub packages or ecosystem tools 
(motivation??)...and might not know how even if they want 
to...cus they don't use those tools. They're not the people to 
write D blog posts, articles, videos, or appear in podcasts, etc. 
They are not?? the community "cheer leaders". Remember, they're 
the core contributors and very short of manpower because D is a 
large language with many new ideas. One reason why they might be 
under staffed could be how its not easy to contribute to D due to 
the unpolished and undocumented process, workflow, project 
direction, etc. They're very technical but not enough time (or 
motivation) to do those soft tasks. If you read some of the 
phobos docs, you'll understand they're the folks doing the work.


2. Is the intermediate. They're the folks who can move between 1 
and attend to 3. They answer most of the technical questions cus 
they have come to know where to find what. My guess is there's 
not a lot of such people...or at least enough active in the 
community day by day. And they're probably working so their free 
time isn't enough to do more. They're the contributors of most 
packages on dub... bindings, ports, etc. They may not be core 
contributors but they contribute to the core language too. 
They're generalist. Not enough time means undocumented packages??

3. Is the rest... coming from JavaScript, Java, python, etc where 
the ecosystem is effortlessly polished... mostly. They're used to 
IDEs, packages, tutorials, videos, great docs (those that don't 
read like memory dump of implementation details), example 
projects,... that kind of stuff. They sometimes find it hard to 
settle with the absence certain tools or under-development or 
maybe unique position?? of D ecosystem like they're used to. 
They're hooked by how nice D code feels and can't accept why D 
isn't all hot and popular..HN, reddit and stuff. They may feel 
like D needs more marketing, promotion and stuff. Or that D needs 
needs x&y features which has made T lang popular. Popularity can 
mean more users (including engineers from other companies who 
might fund D or offer developer time), more contributors, more 
packages, improved docs, more tools, etc.


Of course its not a perfect categorization cus the community is 
more diverse than that. But that's some observations I've made. 
Also, there are so many people also using D quietly.
Nov 27 2020