www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D programming language popularity

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
First some background
---------------------

Languages to learn 2020:
https://www.edureka.co/blog/top-10-programming-languages/0
https://morioh.com/p/f39596f1028e
https://towardsdatascience.com/top-10-in-demand-programming-languages-to-learn-in-2020-4462eb7d8d3e
https://www.guru99.com/best-programming-language.html
https://www.simplilearn.com/best-programming-languages-start-learning-today-article
https://scand.com/company/blog/top-programming-languages-to-use-in-2020/
https://www.fullstackacademy.com/blog/nine-best-programming-languages-to-learn
https://hackr.io/blog/best-programming-languages-to-learn-2020-jobs-future
https://www.ignite.digital/10-best-programming-languages-to-learn-in-2020/

General:
http://pypl.github.io/PYPL.html
https://www.tiobe.com/tiobe-index/
https://redmonk.com/sogrady/2020/07/27/language-rankings-6-20/
https://githut.info/
https://github.com/oprogramador/github-languages
https://www.cleveroad.com/blog/programming-languages-ranking

Summary
-------

D is not present anywhere in languages to learn... Why?
(I get that it can be a chicken and egg problem)

When looking for languages to learn, you have to start 
"somewhere".

How do we make D part of this "somewhere"?

Thanks
Oct 11 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 https://www.simplilearn.com/best-programming-languages-start-learning-today-article


Just something strange about one or two articles.

Level:
	
C – Intermediate to Advanced
C++ – Beginner to Intermediate

Shouldn't it be the other way around. C - Beginner to 
Intermediate, C++ - Intermediate to Advanced. In my mind C++ is a 
more difficult language than plain C simply because C is a 
simpler and smaller language. You might need to write more code 
and less library support out of the box but that is not the same 
as more difficult to learn.
Oct 11 2020
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 11 October 2020 at 11:40:46 UTC, IGotD- wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 https://www.simplilearn.com/best-programming-languages-start-learning-today-article


 Just something strange about one or two articles.

 Level:
 	
 C – Intermediate to Advanced
 C++ – Beginner to Intermediate

 Shouldn't it be the other way around. C - Beginner to 
 Intermediate, C++ - Intermediate to Advanced. In my mind C++ is 
 a more difficult language than plain C simply because C is a 
 simpler and smaller language. You might need to write more code 
 and less library support out of the box but that is not the 
 same as more difficult to learn.


Yeah, C++ is harder to learn than C. Can that be a reason that D 
isn't more popular than C? It's also a bit complex/plastic? 
wondering.bmp 16 colors
Oct 11 2020
parent IGotD- <nise nise.com> writes:
On Sunday, 11 October 2020 at 12:34:45 UTC, Imperatorn wrote:

 Yeah, C++ is harder to learn than C. Can that be a reason that 
 D isn't more popular than C? It's also a bit complex/plastic? 
 wondering.bmp 16 colors


C is more popular because of historical reasons and that it is 
the lowest common denominator when it comes to system support and 
interoperability.

The low traction compared to the big languages is not unique for 
just D. There are other good languages out there that don't have 
the same big marketing like Nim, Zig, Julia, Crystal just to 
mention a few.
Oct 11 2020
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 11 October 2020 at 11:40:46 UTC, IGotD- wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 https://www.simplilearn.com/best-programming-languages-start-learning-today-article


 Just something strange about one or two articles.

 Level:
 	
 C – Intermediate to Advanced
 C++ – Beginner to Intermediate

 Shouldn't it be the other way around. C - Beginner to 
 Intermediate, C++ - Intermediate to Advanced. In my mind C++ is 
 a more difficult language than plain C simply because C is a 
 simpler and smaller language. You might need to write more code 
 and less library support out of the box but that is not the 
 same as more difficult to learn.


I fail to see why.

My Portuguese university had Pascal (3 semester) and C++ (4 
semester) as introduction to programming classes already back in 
1993 (1 year doesn't have programming and is common to all 
engineering degrees).

Everyone did quite alright on the few lectures that actually 
required C, while the teachers made a good job of teaching proper 
C++, with their own type safe data structures, not C with Classes.

Which was great, because none of the students was tainted with C 
style unsafe code patterns.

I also worked as TA doing those classes.
Oct 11 2020
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?


Why would someone use D? If the best you can do is come up with a 
list of technical features of the language, you have your answer 
as to why it's not on those lists. Not many people go looking for 
a programming language. They're looking for a solution to a 
problem.

If you want to increase popularity, write some libraries, turn 
them into a good user experience, document them well, promote 
them to people working in that area, and there's a small chance 
you'll capture some of that niche.

The programming languages space is extremely competitive. There 
will never be a "next C++" because there are way too many 
alternatives these days. Something that has come up over and over 
again in these discussions is making D a player for web 
development. That space is beyond crowded. It's better IMO to 
focus on incremental improvements rather than popularity.
Oct 11 2020
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 11 October 2020 at 13:32:19 UTC, bachmeier wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 [...]


 Why would someone use D? If the best you can do is come up with 
 a list of technical features of the language, you have your 
 answer as to why it's not on those lists. Not many people go 
 looking for a programming language. They're looking for a 
 solution to a problem.

 [...]


You're making several assumptions here. I don't really see how 
any of them answers the question?
Oct 11 2020
parent reply IGotD- <nise nise.com> writes:
On Sunday, 11 October 2020 at 14:21:04 UTC, Imperatorn wrote:

 You're making several assumptions here. I don't really see how 
 any of them answers the question?


To answer your original question. In order to increase the 
popularity of D, it must have a palette of good libraries. Also, 
we need to show people how they can get from A to B with D and 
why it is simpler with the D language. Most people when they 
choose a language is because it offers the best productivity for 
the task, so we need to show the programmers why D is the best 
language for a particular task.
Oct 11 2020
next sibling parent reply bachmeier <no spam.net> writes:
On Sunday, 11 October 2020 at 14:28:34 UTC, IGotD- wrote:

 Most people when they choose a language is because it offers 
 the best productivity for the task, so we need to show the 
 programmers why D is the best language for a particular task.


And as much as I might like D versus other languages, before you 
ask whether D really is the best choice.
Oct 11 2020
next sibling parent bachmeier <no spam.net> writes:
On Monday, 12 October 2020 at 00:08:59 UTC, bachmeier wrote:

 On Sunday, 11 October 2020 at 14:28:34 UTC, IGotD- wrote:

 Most people when they choose a language is because it offers 
 the best productivity for the task, so we need to show the 
 programmers why D is the best language for a particular task.


 And as much as I might like D versus other languages, before 
 you ask whether D really is the best choice.


Should say


 And as much as I might like D versus other languages, before 
 that you should ask whether D really is the best choice.
Oct 11 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 12 October 2020 at 00:08:59 UTC, bachmeier wrote:

 And as much as I might like D versus other languages, before 
 you ask whether D really is the best choice.


Of course D might not be the best choice for a particular task. 
Many times Python or Java is the obvious choice however D has a 
special niche with compiled language performance and memory 
footprint. Right now D often isn't considered at all where C++ 
would be a contender.

Despite the popularity, the way I think is that with D I'm able 
to out compete people who would otherwise use C++ or similar. I 
can produce a solution faster which is also more stable.
Oct 12 2020
parent data pulverizer <data.pulverizer gmail.com> writes:
On Monday, 12 October 2020 at 10:34:17 UTC, IGotD- wrote:

 Despite the popularity, the way I think is that with D I'm able 
 to out compete people who would otherwise use C++ or similar. I 
 can produce a solution faster which is also more stable.


+1

This is such an obviously transparent point and it's not made 
enough. I sometimes sit and think, I'm going to write library X 
in C++. A couple of days later I'm thinking, why am I wasting my 
time writing C++, when D is obviously the much better and more 
productive option, and much more pleasureable to write!? I park 
the C++ code and continue in D. I did this a few of times some 
time ago and now I don't bother with C++.

If D didn't exist, I'd be writing Nim, and if Nim didn't exist, 
I'd be writing Chapel or Rust before C++. I'm not even sure it's 
responsible to write C++ code anymore.
Nov 05 2020
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 11 October 2020 at 14:28:34 UTC, IGotD- wrote:

 On Sunday, 11 October 2020 at 14:21:04 UTC, Imperatorn wrote:

 You're making several assumptions here. I don't really see how 
 any of them answers the question?


 To answer your original question. In order to increase the 
 popularity of D, it must have a palette of good libraries. 
 Also, we need to show people how they can get from A to B with 
 D and why it is simpler with the D language. Most people when 
 they choose a language is because it offers the best 
 productivity for the task, so we need to show the programmers 
 why D is the best language for a particular task.


Thanks for your answer. Yes, ecosystem is very important. I guess 
I have to make some libs then 🐣
Oct 11 2020
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Sunday, 11 October 2020 at 13:32:19 UTC, bachmeier wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?


 Why would someone use D? If the best you can do is come up with 
 a list of technical features of the language, you have your 
 answer as to why it's not on those lists. Not many people go 
 looking for a programming language. They're looking for a 
 solution to a problem.


I think this answers it. Rarely am I looking at the language 
itself (for the job). So I think it's flawed to focus solely on 
the language itself. If the ecosystem (of packages and 
development tools) doesn't provide me with an easy way of getting 
things done, then what's the point?

So this is a primary reason why I'll choose one language over 
another. Most coders I know are not capable nor willing to build 
their own stuff when it's available out of the box in other 
languages.
Oct 13 2020
parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Tuesday, 13 October 2020 at 07:24:23 UTC, aberba wrote:

 On Sunday, 11 October 2020 at 13:32:19 UTC, bachmeier wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?


 Why would someone use D? If the best you can do is come up 
 with a list of technical features of the language, you have 
 your answer as to why it's not on those lists. Not many people 
 go looking for a programming language. They're looking for a 
 solution to a problem.


 I think this answers it. Rarely am I looking at the language 
 itself (for the job). So I think it's flawed to focus solely on 
 the language itself. If the ecosystem (of packages and 
 development tools) doesn't provide me with an easy way of 
 getting things done, then what's the point?

 So this is a primary reason why I'll choose one language over 
 another. Most coders I know are not capable nor willing to 
 build their own stuff when it's available out of the box in 
 other languages.


Depends on what kind of programming it is and the kind of people 
you have.  If most of the code is specific to your use and 
wrapping another library is a small cost versus everything else 
involved in solving your problem then you are going to arrive at 
a different answer from someone who is in a different situation.

The breadth of D comes in surprisingly useful.  For example a 
little language for writing reports - you certainly aren't going 
to need low level features for that.  Well, what if you want to 
allow users to configure reports with a lambda but want some 
restrictions on remote code execution by design.  Well maybe you 
could just build Linux containers into the little language by 
dropping down to syscall level.  First draft of that took a very 
long evening.  Then longer for others to fix some weird GC 
problems.  But now we have ephemeral containers built in to the 
language.

Our little language written in D can call good chunks of C++ too 
thanks to cling.  I'm not proud of it,  but it can compile C++ at 
runtime and call it.  So that opens up quite a few libraries.

Then plasticity and absence of boilerplate are also quite 
valuable.

I think it's a mistake to focus mostly on making D more 
accessible; a little doesn't hurt.  D will gain adoption from 
people like Weka.io - absolutely nobody would advise building a 
new storage startup using an emerging language that nobody at 
your startup knows.  But almost nobody would succeed in building 
the world's fastest parallel storage system (and not by a little) 
in a few years.  So D is like a secret weapon for disruptive 
innovation that's only available to people who are already quite 
unusual sorts of people.

We are hiring at least forty people to write D, and I don't think 
we have been the only ones hiring in the past couple of years.

But there's also no shortage of people who could write D; C++ 
programmers seem to pick it up quite quickly.
Oct 25 2020
parent aberba <karabutaworld gmail.com> writes:
On Monday, 26 October 2020 at 02:14:07 UTC, Laeeth Isharc wrote:

 On Tuesday, 13 October 2020 at 07:24:23 UTC, aberba wrote:

 On Sunday, 11 October 2020 at 13:32:19 UTC, bachmeier wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?


 Why would someone use D? If the best you can do is come up 
 with a list of technical features of the language, you have 
 your answer as to why it's not on those lists. Not many 
 people go looking for a programming language. They're looking 
 for a solution to a problem.


 I think this answers it. Rarely am I looking at the language 
 itself (for the job). So I think it's flawed to focus solely 
 on the language itself. If the ecosystem (of packages and 
 development tools) doesn't provide me with an easy way of 
 getting things done, then what's the point?

 So this is a primary reason why I'll choose one language over 
 another. Most coders I know are not capable nor willing to 
 build their own stuff when it's available out of the box in 
 other languages.


 Depends on what kind of programming it is and the kind of 
 people you have. ...
 I think it's a mistake to focus mostly on making D more 
 accessible; a little doesn't hurt.  D will gain adoption from 
 people like Weka.io - absolutely nobody would advise building a 
 new storage startup using an emerging language that nobody at 
 your startup knows.  But almost nobody would succeed in 
 building the world's fastest parallel storage system (and not 
 by a little) in a few years.  So D is like a secret weapon for 
 disruptive innovation that's only available to people who are 
 already quite unusual sorts of people.


That's assuming that the dev population is all Weka.io...which is 
quite the opposite. Only a few people are going to build the 
fastest file system, etc, ...and C++ is already matured enough 
for such (for those already with C++ workforce).

Cooperates might use D if they are sure to have enough devs to 
hire...and that comes after it's popularly used among regular 
devs. And regular devs start from somewhere.

Someone built vibe.d...and it's the most popular on dub
Someone built arsd and it's popular
etc. etc.

The majority of devs are consumers (and some might build 
something for the ecosystem)...but it starts from somewhere.

BTW...there was a lot of nitpicking of vibe.d and dub but it 
seems?? most of those people have gotten used to it. We need more 
of such stuff in the package repository.
Nov 04 2020
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 When looking for languages to learn, you have to start 
 "somewhere".


If we are talking professional developers then you need language 
stability, excellent debugging experience and long term 
maintained bindings to key libraries/frameworks for some specific 
use area.

If we are talking hobby, then I don't know. Lots of tutorials, 
examples with visual output (graphics), maintained baseline 
startingpoints, lots of answers and snippets on stack overflow 
helps.

People new to programming should stay with languages like Python 
and Swift, IMO.
Oct 11 2020
prev sibling next sibling parent =?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KTQsNC0?= =?UTF-8?B?0LXQtdCy?= writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 First some background
 ---------------------

 How do we make D part of this "somewhere"?


D - is best language.
A little time will pass, and a native gui will be born. The 
development environment will be born. And D will be higher than 
C, then Java, then higher than Python.
Oct 11 2020
prev sibling next sibling parent reply user1234 <user1234 12.de> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 D is not present anywhere in languages to learn... Why?


Because of jobs availability.

I dont think it would be reponsible to recommend to invest time 
if at the end there's only 10 free sits in the train. I'll gently 
assume that people are influenced by these kind of articles so 
you could easily have 1000 new users.

It would be nicer to see D mentioned in an article that 
recommends a selection of languages but that rather targets 
people who start their own business, i.e "decision makers".
Oct 11 2020
parent bachmeier <no spam.net> writes:
On Sunday, 11 October 2020 at 15:25:33 UTC, user1234 wrote:


 I dont think it would be reponsible to recommend to invest time 
 if at the end there's only 10 free sits in the train. I'll 
 gently assume that people are influenced by these kind of 
 articles so you could easily have 1000 new users.


I'm not sure I'm on board with that. You're assuming the only 
reason for someone to learn a language is to get a job directly 
applying that language. There are large benefits to learning 
Ocaml or Haskell or Scala even if you never get paid to write 
code in those languages.
Oct 11 2020
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 First some background
 ---------------------

 [...]


Btw, this is interesting:
http://erdani.com/d/downloads.daily.png
Oct 11 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 12 October 2020 at 06:47:13 UTC, Imperatorn wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 First some background
 ---------------------

 [...]


 Btw, this is interesting:
 http://erdani.com/d/downloads.daily.png


I looked at the logs it was full of noise, very hard to 
interpret. I wonder why the robot.txt does not prevent downloads 
from bots. Why index archives?
Oct 12 2020
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/12/20 2:47 AM, Imperatorn wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 First some background
 ---------------------

 [...]


 
 Btw, this is interesting:
 http://erdani.com/d/downloads.daily.png


As the legend suggests I recently filtered the data to eliminate 
duplicate IPs and failed downloads. The numbers on the Y axis are 
therefore smaller than before but the shape of the plot has not changed 
much.
Oct 12 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 12 October 2020 at 13:28:38 UTC, Andrei Alexandrescu 
wrote:

 On 10/12/20 2:47 AM, Imperatorn wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 First some background
 ---------------------

 [...]


 
 Btw, this is interesting:
 http://erdani.com/d/downloads.daily.png


 As the legend suggests I recently filtered the data to 
 eliminate duplicate IPs and failed downloads. The numbers on 
 the Y axis are therefore smaller than before but the shape of 
 the plot has not changed much.


Cool. So it seems that it's at least *possible* that interest in 
D is growing?

But all things considered, D is actually not that small. I mean 
checking search trends for Nim and Julia for example, D actually 
has more searches. But you don't always get that impression.
Oct 12 2020
prev sibling next sibling parent Laeeth Isharc <laeeth laeeth.com> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 D is not present anywhere in languages to learn... Why?
 (I get that it can be a chicken and egg problem)

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?

 Thanks


This answer may not be welcome, but the answer is : it's open 
source.  Write a tutorial yourself and persuade somehow others to 
join you.

If you are good at writing tutorials, maybe you will get a job 
from it if you want one. We are hiring people to write 
documentation and tutorials for internal projects.
Oct 25 2020
prev sibling next sibling parent reply J. V. <jv jv.com> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 First some background
 ---------------------

 Languages to learn 2020:
 https://www.edureka.co/blog/top-10-programming-languages/0
 https://morioh.com/p/f39596f1028e
 https://towardsdatascience.com/top-10-in-demand-programming-languages-to-learn-in-2020-4462eb7d8d3e
 https://www.guru99.com/best-programming-language.html
 https://www.simplilearn.com/best-programming-languages-start-learning-today-article
 https://scand.com/company/blog/top-programming-languages-to-use-in-2020/
 https://www.fullstackacademy.com/blog/nine-best-programming-languages-to-learn
 https://hackr.io/blog/best-programming-languages-to-learn-2020-jobs-future
 https://www.ignite.digital/10-best-programming-languages-to-learn-in-2020/

 General:
 http://pypl.github.io/PYPL.html
 https://www.tiobe.com/tiobe-index/
 https://redmonk.com/sogrady/2020/07/27/language-rankings-6-20/
 https://githut.info/
 https://github.com/oprogramador/github-languages
 https://www.cleveroad.com/blog/programming-languages-ranking

 Summary
 -------

 D is not present anywhere in languages to learn... Why?
 (I get that it can be a chicken and egg problem)

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?

 Thanks


Hi, i'm new in here,

Personally, D atrracted me because of:

- Introspection
- Native binary
- Low memory usage
- It is familiar to someone that have used C++ and Java before

I think that introspection should be the main marketing focus for 
D. And, of course, we need more companies adopting the language.
Nov 01 2020
parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Sunday, 1 November 2020 at 21:15:25 UTC, J. V. wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 [...]


 Hi, i'm new in here,

 Personally, D atrracted me because of:

 - Introspection
 - Native binary
 - Low memory usage
 - It is familiar to someone that have used C++ and Java before

 I think that introspection should be the main marketing focus 
 for D. And, of course, we need more companies adopting the 
 language.


For me the language should focus on scientific library such as do
- python with numpy, scipy, scikit-learn and so on
Indeed data to analyze becomes bigger and bigger years after 
years. Python can not anymore handle such big data.

Moreover, lots of numerical companies depends of such solutions, 
economy, marketing, science. To me the market is here
Nov 02 2020
parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Monday, 2 November 2020 at 22:40:05 UTC, bioinfornatics wrote:

 For me the language should focus on scientific library ...


Yes. I think D has left many potential acolytes on the table by 
not going after this user base more vigorously, but there's still 
plenty of opportunity for success.


 Moreover, lots of numerical companies depends of such 
 solutions, economy, marketing, science. To me the market is here


+1
Nov 04 2020
parent reply random <random spaml.de> writes:
This kind of thread seems to pop up once in a while in this 
forum. I read threads in this forum a lot more than i participate 
in the discussion but now I'll give my 2 cents. Don't take it too 
seriously.

Disclaimer: While I will write only negative aspects below, D is 
actually the language I like most from all I have tried (C, C++, 

also far from perfect.

1. Librarys:
- There are not a lot libraries and if you find one it will most 
probably not compile.

- If you find a working library the documentation is likely bad. 
You always hear the argument: "It's open source, you can help out 
writing documentation".
This is hilarious because if I want to write documentation for 
your library, I have to read and understand your code first. I 
will need 10-100x more time than the one who wrote the library.
The whole point of abstraction is that you abstract away the 
implementation. If i have to read your source to use your library 
it's just pointless.

2. It's too close to C++ to be worth the drawback:
- If you plan writing a serious long living project C++ is just a 
much safer choice.
Yes C++ looks ugly and D corrected a lot of bad design decisions, 
but both languages are still very similar. If you hold your nose 
and write C++ you will benefit from all the tooling and ecosystem.

3. Garbage Collector:
- If you can live with GC there are nice alternatives. Kotlin 
looks promising.

platform with .net 5).
A language compiling to native code with system level features 
and a GC is just a strange niche. You can turn of the GC but then 
you can't use all of the language anymore. I can't imagine a 
situation in which i really have to use a native language but 
want a GC...
Nov 04 2020
next sibling parent reply CraigDillabaugh <craig.dillabaugh gmail.com> writes:
On Wednesday, 4 November 2020 at 23:44:04 UTC, random wrote:
clip

 3. Garbage Collector:
 - If you can live with GC there are nice alternatives. Kotlin 
 looks promising.

 platform with .net 5).
 A language compiling to native code with system level features 
 and a GC is just a strange niche. You can turn of the GC but 
 then you can't use all of the language anymore. I can't imagine 
 a situation in which i really have to use a native language but 
 want a GC...


Can you imagine a situation where you need to use a native 
language but don't want to use the GC?
Nov 04 2020
parent random <random spaml.de> writes:
On Wednesday, 4 November 2020 at 23:54:13 UTC, CraigDillabaugh 
wrote:

 Can you imagine a situation where you need to use a native 
 language but don't want to use the GC?


Easy: Embedded, Realtime, HPC, some AAA Games

Yeah i know you can run Java or Python on uC, but 99% of embedded 
is native and no GC.
Nov 04 2020
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 4 November 2020 at 23:44:04 UTC, random wrote:

 3. Garbage Collector:
 - If you can live with GC there are nice alternatives. Kotlin 
 looks promising.

 platform with .net 5).
 A language compiling to native code with system level features 
 and a GC is just a strange niche. You can turn of the GC but 
 then you can't use all of the language anymore. I can't imagine 
 a situation in which i really have to use a native language but 
 want a GC...


Maybe you specifically don't, but the US navy seem to be quite at 
home with it.

https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-technology-at-the-of-aegis-the-shield-of-the-fleet

"Given the need for predictable and reliable compliance with 
sub-millisecond timing constraints, Lockheed Martin evaluated a 
number of alternative approaches to real-time Java.&nbsp; 
Ultimately, they chose to use the PTC Perc Ultra virtual machine 
(formerly called Aonix Perc Ultra), both in single-core and 
multi-core configurations. This technology adds real-time 
determinism to Standard Edition Java APIs by incorporating 
real-time garbage collection, fixed-priority real-time 
scheduling, prioritized queues and priority inheritance locks 
within the implementation of the virtual machine."

Just one example among others that I can point out for PTC and 
Aicas, which despite being JVMs, also support bare metal 
deployments for this kind of targets, thus as native as anything 
else that AOT compiles to native code with a language runtime.

Then there are these products:

Astrobe selling Oberon devkits for ARM, Cortex-M3, Cortex-M4, 
Cortex-M7 and now RISC-V, in business for about 20 years.

https://www.astrobe.com/Oberon.htm

F-Secure using their own Go port for secure firmware, among them 
their own computer on an USB key, USB Armory

https://www.f-secure.com/en/consulting/foundry/usb-armory

So there is a market, even if you personally don't care about it.
Nov 04 2020
parent reply random <random spaml.de> writes:
On Thursday, 5 November 2020 at 06:58:31 UTC, Paulo Pinto wrote:

 Just one example among others that I can point out for PTC and 
 Aicas, which despite being JVMs, also support bare metal 
 deployments for this kind of targets, thus as native as 
 anything else that AOT compiles to native code with a language 
 runtime.


Ok, there are ways to AOT JVM languages. My point was, if you can 
afford to use JVM you have nice alternatives to D. Also D's GC 
will by design never be as powerful as JVM GC. In D you can have 
pointers to manual memory, etc. This restricts the GC.


 Then there are these products:

 Astrobe selling Oberon devkits for ARM, Cortex-M3, Cortex-M4, 
 Cortex-M7 and now RISC-V, in business for about 20 years.


I never even heard of someone programming in Oberon.


 https://www.astrobe.com/Oberon.htm

 F-Secure using their own Go port for secure firmware, among 
 them their own computer on an USB key, USB Armory

 https://www.f-secure.com/en/consulting/foundry/usb-armory

 So there is a market, even if you personally don't care about 
 it.


This is a imputation. I never said I don't care. All the things 
you mentioned are really niche. Because you somehow misunderstood 
my argument i will simplify it for you:
- When you can live with GC you can most of the time live with 
JVM or CLR. Then you have a lot good languages to choose from.
- If you can't live with JVM/CLR then you either have a very 
resource limited system or you really need every bit of 
performance. In this case you want a native language without GC.

Most of the time native language and GC is not the right 
combination.
Nov 05 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 5 November 2020 at 08:36:51 UTC, random wrote:

 On Thursday, 5 November 2020 at 06:58:31 UTC, Paulo Pinto wrote:

 [...]


 Ok, there are ways to AOT JVM languages. My point was, if you 
 can afford to use JVM you have nice alternatives to D. Also D's 
 GC will by design never be as powerful as JVM GC. In D you can 
 have pointers to manual memory, etc. This restricts the GC.


 [...]


 I never even heard of someone programming in Oberon.


 [...]


 This is a imputation. I never said I don't care. All the things 
 you mentioned are really niche. Because you somehow 
 misunderstood my argument i will simplify it for you:
 - When you can live with GC you can most of the time live with 
 JVM or CLR. Then you have a lot good languages to choose from.


D is the only system language with GC I can deal with. I love the 
GC personally though. There's a significant difference between D 
with GC and Java with GC. The VM.


 - If you can't live with JVM/CLR then you either have a very 
 resource limited system or you really need every bit of 
 performance. In this case you want a native language without GC.


I don't think D is EVER going to be without a GC though. 8ts very 
necessary for app development... productivity and safe.


 Most of the time native language and GC is not the right 
 combination.


Maybe you should look into not mixing up GC and nogc code.
Nov 06 2020
parent reply IGotD- <nise nise.com> writes:
On Friday, 6 November 2020 at 23:04:44 UTC, aberba wrote:

 I don't think D is EVER going to be without a GC though. 8ts 
 very necessary for app development... productivity and safe.


D should take the same route as Nim. Nim has several garbage 
collection algorithms and can swap them out as they see fit. 
Latest reference counting algorithm has been a success for Nim 
and the language just keep on improving because they have 
invested in good GC as well an architecture where they can 
continue to play with different approaches.

GC is not bad but the language must support changing GC 
algorithms.

D is in a corner here a can go nowhere.
Nov 06 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 6 November 2020 at 23:16:53 UTC, IGotD- wrote:

 D should take the same route as Nim. Nim has several garbage 
 collection algorithms and can swap them out as they see fit. 
 Latest reference counting algorithm has been a success for Nim 
 and the language just keep on improving because they have 
 invested in good GC as well an architecture where they can 
 continue to play with different approaches.

 GC is not bad but the language must support changing GC 
 algorithms.


D already supports changing GC algorithms. [1] Currently, there 
are only two algorithms to choose from (conservative and 
precise), but there's nothing stopping anyone from adding more.

[1] https://dlang.org/spec/garbage.html#gc_config
Nov 07 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:

 D already supports changing GC algorithms. [1] Currently, there 
 are only two algorithms to choose from (conservative and 
 precise), but there's nothing stopping anyone from adding more.

 [1] https://dlang.org/spec/garbage.html#gc_config


D only supports tracing GC.
Nov 07 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 8 November 2020 at 01:36:09 UTC, IGotD- wrote:

 On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:

 D already supports changing GC algorithms. [1] Currently, 
 there are only two algorithms to choose from (conservative and 
 precise), but there's nothing stopping anyone from adding more.

 [1] https://dlang.org/spec/garbage.html#gc_config


 D only supports tracing GC.


So?

There are plenty tracing GC algorithms to choose from:

- mark and sweep
- concurrent
- fully parallel
- pauseless
- colouring
- with nursery
- with several generations
- thread local
- real time
- soft real time
- how far interior pointers are supported
- with or without safe points
- copy on write for mutations

http://gchandbook.org/contents.html provides a good overview, 
although it has been somehow superseded by research published in 
ACM SIGPLAN and IEEE papers as well.

Plenty of opportunities for alternative implementations to plug 
into D's runtime.
Nov 08 2020
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 8 November 2020 at 09:27:08 UTC, Paulo Pinto wrote:

 On Sunday, 8 November 2020 at 01:36:09 UTC, IGotD- wrote:

 On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:

 D already supports changing GC algorithms. [1] Currently, 
 there are only two algorithms to choose from (conservative 
 and precise), but there's nothing stopping anyone from adding 
 more.

 [1] https://dlang.org/spec/garbage.html#gc_config


 D only supports tracing GC.


 So?

 There are plenty tracing GC algorithms to choose from:

 - mark and sweep
 - concurrent
 - fully parallel
 - pauseless
 - colouring
 - with nursery
 - with several generations
 - thread local
 - real time
 - soft real time
 - how far interior pointers are supported
 - with or without safe points
 - copy on write for mutations

 http://gchandbook.org/contents.html provides a good overview, 
 although it has been somehow superseded by research published 
 in ACM SIGPLAN and IEEE papers as well.

 Plenty of opportunities for alternative implementations to plug 
 into D's runtime.


Would it be possible to tune the existing GC to control how much 
garbage is collected? I mean, for instance, to tell the GC to 
label objects as garbage as normal, but only to collect so much 
at a time. The others would be saved to be collected later.
Nov 08 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 14:21:25 UTC, jmh530 wrote:

 Would it be possible to tune the existing GC to control how 
 much garbage is collected? I mean, for instance, to tell the GC 
 to label objects as garbage as normal, but only to collect so 
 much at a time. The others would be saved to be collected later.


Drop destructors and then you dont have to do much explicit 
collection.

But the tracing is still expensive. You can try to do separation 
at the type level and use ideas from generational, but it will 
only work sometimes and you need global analysis.

Thread local collection + global refcounting is a better fit for 
D.

Or just ARC, which I would prefer if done with global static 
analysis.
Nov 08 2020
parent random <frederick.muller existiert.net> writes:
On Sunday, 8 November 2020 at 15:04:33 UTC, Ola Fosheim Grøstad 
wrote:

 Or just ARC, which I would prefer if done with global static 
 analysis.


+1 I learned Swift a while ago, mostly because I like the idea of 
ARC. (I came to the conclusion that I don't like Swift btw^^).

People often dismiss it because it's slower than tracing GC, but 
there is more to it.
Obviously lower memory usage and deterministic destruction.

The real killer feature of ARC is imho that you can use it to 
implement value semantics with copy on write.
Swift does it for arrays. Semantically you pass by value, but it 
will only duplicate the array if you write to it and the refcount 
is greater one.
You can also use this to implement classes with value semantics 
(with a little bit boilerplate).
Nov 08 2020
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 01:22:15 UTC, Paul Backus wrote:

 On Friday, 6 November 2020 at 23:16:53 UTC, IGotD- wrote:

 D should take the same route as Nim. Nim has several garbage 
 collection algorithms and can swap them out as they see fit. 
 Latest reference counting algorithm has been a success for Nim 
 and the language just keep on improving because they have 
 invested in good GC as well an architecture where they can 
 continue to play with different approaches.

 GC is not bad but the language must support changing GC 
 algorithms.


 D already supports changing GC algorithms. [1] Currently, there 
 are only two algorithms to choose from (conservative and 
 precise), but there's nothing stopping anyone from adding more.


Language semantics stops it. D cannot do precise GC with the 
current semantics, you need to locate all actual pointers, 
including those in unions. The default is essentially a boehm 
collector and the other one is semi-conservative, not precise...
Nov 08 2020
parent reply random <frederick.muller existiert.net> writes:
On Sunday, 8 November 2020 at 09:28:05 UTC, Ola Fosheim Grøstad 
wrote:

 Language semantics stops it. D cannot do precise GC with the 
 current semantics, you need to locate all actual pointers, 
 including those in unions. The default is essentially a boehm 
 collector and the other one is semi-conservative, not precise...


If I understand it right you also can't have a GC with heap 
compaction in D, because this would invalidate pointers. Most 
high performance GCs use heap compaction...

The language relies on GC (you can't use all features without 
it), but at the same time it is designed in a way you can't have 
a competitive GC (compared to JVM/CLR).
Nov 08 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 13:28:02 UTC, random wrote:

 If I understand it right you also can't have a GC with heap 
 compaction in D, because this would invalidate pointers. Most 
 high performance GCs use heap compaction...


It is possible, but expensive..


 The language relies on GC (you can't use all features without 
 it), but at the same time it is designed in a way you can't 
 have a competitive GC (compared to JVM/CLR).


The problem is that raw C pointers can be owning pointers. So it 
would be a breaking change.
Nov 08 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 8 November 2020 at 13:39:17 UTC, Ola Fosheim Grøstad 
wrote:

 The problem is that raw C pointers can be owning pointers. So 
 it would be a breaking change.


We need to break this change because if we don't D will not 
progress. The alternative is some pointer container as if we 
would litter C++ std::shared_ptr all over the place, not too 
happy about that though. This will of course be a library change 
but I think we should have a language classifier for it. This 
doesn't really need to be a breaking change but an additional 
"fat pointer".
Nov 08 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YXg=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 14:04:31 UTC, IGotD- wrote:

 On Sunday, 8 November 2020 at 13:39:17 UTC, Ola Fosheim Grøstad 
 wrote:

 The problem is that raw C pointers can be owning pointers. So 
 it would be a breaking change.


 We need to break this change because if we don't D will not 
 progress. The alternative is some pointer container as if we 
 would litter C++ std::shared_ptr all over the place, not too 
 happy about that though. This will of course be a library 
 change but I think we should have a language classifier for it. 
 This doesn't really need to be a breaking change but an 
 additional "fat pointer".


Make all raw pointers borrowing, then add owning pointer types. 
Make all  class pointers work like shared_ptr.

Simple solution: unique_ptr for structs and embedded shared_ptr 
for classes and dynamic arrays. Owning slices will need a new 
pointer to the refcount head.
Nov 08 2020
parent reply IGotD- <nise nise.com> writes:
On Sunday, 8 November 2020 at 15:09:55 UTC, Ola Fosheim Grøstax 
wrote:

 Make all raw pointers borrowing, then add owning pointer types. 
 Make all  class pointers work like shared_ptr.

 Simple solution: unique_ptr for structs and embedded shared_ptr 
 for classes and dynamic arrays. Owning slices will need a new 
 pointer to the refcount head.


No, then you put restrictions on raw pointers which is something 
we don't need. Forced single ownership is something that does not 
belong in D. Let's just keep the raw pointers as they are and add 
other pointer types instead.

This is something not many languages has thought of which is 
generic pointer types, the ability to mix pointer types in a 
program that are not pre-determined. C++ has its unique_ptr and 
shared_ptr but I was think more in line with A_ptr or B_ptr and 
what those pointers are supposed to use is configurable. This is 
of course possible as library additions but I've never seen 
languages to offer this out of the box and it would be nice to 
have a language framework for this. Nim offers to replace its 
"ref" types with any type of GC. However, why not go a step 
further and allow several types of "ref" types.
Nov 08 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 17:00:07 UTC, IGotD- wrote:

 No, then you put restrictions on raw pointers which is 
 something we don't need. Forced single ownership is something 
 that does not belong in D. Let's just keep the raw pointers as 
 they are and add other pointer types instead.


That is what I would do too, but then you can use a library. And 
it breaks all existing GC based libraries with no help from the 
type checker when porting.

You cannot convert GC code this way, to do that you have to make 
current pointer types owning and introduce a new nonowning type.


 This is something not many languages has thought of which is 
 generic pointer types, the ability to mix pointer types in a 
 program that are not pre-determined. C++ has its unique_ptr and 
 shared_ptr but I was think more in line with A_ptr or B_ptr and 
 what those pointers are supposed to use is configurable. This 
 is of course possible as library additions but I've never seen 
 languages to offer this out of the box and it would be nice to 
 have a language framework for this.


I have suggested it before in the forums. In C++ you can template 
the smart pointer type, I think. Although manual borrowing is the 
common way...
Nov 08 2020
prev sibling parent reply Araq <rumpf_a web.de> writes:
On Sunday, 8 November 2020 at 17:00:07 UTC, IGotD- wrote:

 This is something not many languages has thought of which is 
 generic pointer types, the ability to mix pointer types in a 
 program that are not pre-determined. C++ has its unique_ptr and 
 shared_ptr but I was think more in line with A_ptr or B_ptr and 
 what those pointers are supposed to use is configurable. This 
 is of course possible as library additions but I've never seen 
 languages to offer this out of the box and it would be nice to 
 have a language framework for this. Nim offers to replace its 
 "ref" types with any type of GC. However, why not go a step 
 further and allow several types of "ref" types.


Nim does go this step further and allows for custom pointer 
types. Not that good of an idea, interop between libraries 
doesn't improve when they cannot even agree on the used pointer 
type, but it is supported in Nim.
Nov 11 2020
parent IGotD- <nise nise.com> writes:
On Wednesday, 11 November 2020 at 13:30:32 UTC, Araq wrote:

 Nim does go this step further and allows for custom pointer 
 types. Not that good of an idea, interop between libraries 
 doesn't improve when they cannot even agree on the used pointer 
 type, but it is supported in Nim.


Isn't that the case as well when you change the GC algorithm? 
Sure shared libraries that are compiled with one type GC and 
another with a different one will cause problems. Is there a 
possibility to detect this, with name mangling for example?
Nov 11 2020
prev sibling parent reply random <frederick.muller existiert.net> writes:
On Sunday, 8 November 2020 at 13:39:17 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 8 November 2020 at 13:28:02 UTC, random wrote:

 If I understand it right you also can't have a GC with heap 
 compaction in D, because this would invalidate pointers. Most 
 high performance GCs use heap compaction...


 It is possible, but expensive..


How would you do this? Track all pointers (type system knows 
them) and if you move the object update all pointers to that 
object. What is with something evil like C++ iterator::end(), 
which is often a pointer one past the last valid element in the 
buffer? I think you would have to track for all pointers to which 
GC allocated object they belong...


 The language relies on GC (you can't use all features without 
 it), but at the same time it is designed in a way you can't 
 have a competitive GC (compared to JVM/CLR).


 The problem is that raw C pointers can be owning pointers. So 
 it would be a breaking change.


This is not completely clear to me. Do you mean (like you said 
previously) that an other pointer type is needed so GC can 
differentiate between them? Is there something else I'm missing 
about ownership?
Nov 08 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 17:38:01 UTC, random wrote:

 On Sunday, 8 November 2020 at 13:39:17 UTC, Ola Fosheim Grøstad 
 wrote:

 On Sunday, 8 November 2020 at 13:28:02 UTC, random wrote:

 If I understand it right you also can't have a GC with heap 
 compaction in D, because this would invalidate pointers. Most 
 high performance GCs use heap compaction...


 It is possible, but expensive..


 How would you do this? Track all pointers (type system knows 
 them) and if you move the object update all pointers to that 
 object. What is with something evil like C++ iterator::end(), 
 which is often a pointer one past the last valid element in the 
 buffer? I think you would have to track for all pointers to 
 which GC allocated object they belong...


I wouldnt... But yes you could have many generation buckets and 
move 2 old near empty buckets to a new one if the static analysis 
tells you it is safe... I wouldnt compact all buckets every 
collection cycle.

I would probably change the semantics so that you need to hold 
array ownership through a slice, then you can compact arrays. 
Keep only elements reachable from active slices.
  it would be a breaking change.


 This is not completely clear to me. Do you mean (like you said 
 previously) that an other pointer type is needed so GC can 
 differentiate between them?


Yes, basically.
Nov 08 2020
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 8 November 2020 at 17:38:01 UTC, random wrote:

 On Sunday, 8 November 2020 at 13:39:17 UTC, Ola Fosheim Grøstad 
 wrote:

 On Sunday, 8 November 2020 at 13:28:02 UTC, random wrote:

 [...]


 It is possible, but expensive..


 How would you do this? Track all pointers (type system knows 
 them) and if you move the object update all pointers to that 
 object. What is with something evil like C++ iterator::end(), 
 which is often a pointer one past the last valid element in the 
 buffer? I think you would have to track for all pointers to 
 which GC allocated object they belong...


 [...]


 The problem is that raw C pointers can be owning pointers. So 
 it would be a breaking change.


 This is not completely clear to me. Do you mean (like you said 
 previously) that an other pointer type is needed so GC can 
 differentiate between them? Is there something else I'm missing 
 about ownership?


Yes, in systems languages like Modula-3, Active Oberon, or if you 
prefer something more modern, .NET Native, Swift or Go, the 
pointers are safe by default and you have an explicit unsafe 
pointer for "do any kind of tricks pointer".
Nov 08 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 8 November 2020 at 19:12:06 UTC, Paulo Pinto wrote:

 pointers are safe by default and you have an explicit unsafe 
 pointer for "do any kind of tricks pointer".


By having borrowing pointers for GC you could also potentially 
reduce the graph that has to be scanned, when following a 
borrowing pointer can never reach an owning pointer. Requires 
global analysis.
Nov 08 2020
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 4 November 2020 at 23:44:04 UTC, random wrote:

 A language compiling to native code with system level features 
 and a GC is just a strange niche. You can turn of the GC but 
 then you can't use all of the language anymore. I can't imagine 
 a situation in which i really have to use a native language but 
 want a GC...


A GC is useful for prototyping, but the problem with D is that 
there is no adequate model for ownership in the type system. It 
is not difficult to fix, you just need people to understand that 
multiple pointer types are needed and has to be agreed upon.

Until this happens the GC will continue to be problematic as you 
have to rely on ad hoc solutions with no real help from the type 
system. How do you gracefully transition code from GC managed to 
some other scheme?

Or you could add sanitizer mechanism and catch typing issues at 
runtime during testing.

But D needs something more than what is on the map. That is 
obvious.
Nov 04 2020
prev sibling next sibling parent reply frame <frame86 live.com> writes:
On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 D is not present anywhere in languages to learn... Why?
 (I get that it can be a chicken and egg problem)

 When looking for languages to learn, you have to start 
 "somewhere".

 How do we make D part of this "somewhere"?

 Thanks


I want to add my 2 cent as newbie:


is less popular. It this a benefit?

- It's likely that users need a library. This library may exists 
as D code but even the search for that library is not intuitive. 
You have to try multiple terms or browse manually for the 
library, this is bad. Also the library seems to be outdated while 
the C library developers just did a new release and you could 
assume the D-lib is just dead. This makes D look more like an 
experiment than a living standard.

- The offical library reference is visually "unfriendly". For 
example, devdocs.io do a better job. On the D-site, it looks not 
well formatted. I am loosing focus while reading on some 
locations. The search engine is unsatisfying. Even that I can't 
format code in forums bothers me, because that are standard 
features and they just not there. This appears as "unfinished", 
we are not in year 1998.

- D also needs a new modern, _just working_ IDE with syntax 
highlighting, formatting, autocomplete hints, quick 
documentation. I've tried the Dlang IDE, VisualD, WebFreak-D or 
other Plugins for Visual Studio and IDEA. Plugins either do not 
work well, get broken with never versions (eg. MonoDevelop) but 
also true for VS Code. You see quickly that event VisualD is just 
a plugin which is buggy, crashes and does not really integrate 
well (sepearate build options, passing arguments ignored, etc). 
Also realtime debugging is a pain, eg with VisualD: If you are 
lucky it will display the stack correctly - but it has problems 
with template functions and it show your structs in initial state 
rather actual value. I could not run the debugger in VS Code, it 
runs/breaks but shows nothing and it's not my job to report bugs 
to plugin-devs that just don't have the time to fix them. I could 
also only run partial debugging on IntelliJ IDEA since variables 
are not updated on change - there is always such an issue and the 
list goes on...

Of course this is offtopic by the language itself but it has a 
heavy influence if I would try a new language which tools are 
only working on the command line out of the box. You may get the 
point, if you want to attract new users, you need a supported, 
working welcome packet just as an IDE with friendly features so 
the users can just start making experiences.
Nov 03 2020
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 3 November 2020 at 16:49:16 UTC, frame wrote:

 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 [...]


 I want to add my 2 cent as newbie:


 is less popular. It this a benefit?

 [...]


+1 on IDE 🚨
Nov 04 2020
prev sibling next sibling parent data pulverizer <data.pulverizer gmail.com> writes:
On Tuesday, 3 November 2020 at 16:49:16 UTC, frame wrote:

 I want to add my 2 cent as newbie:

 - D also needs a new modern, _just working_ IDE with syntax 
 highlighting, formatting, autocomplete hints, quick 
 documentation. I've tried the Dlang IDE, VisualD, WebFreak-D or 
 other Plugins for Visual Studio and IDEA. Plugins either do not 
 work well, get broken with never versions (eg. MonoDevelop) but 
 also true for VS Code.


+1

I wonder how many new users are turned off by the IDE issues in 
D. I use VS Code and only ever use it as a glorified syntax 
highlighter - I don't use any other features. Even I had to 
uninstall the D plugins and write code using C++ highlighting. I 
have literally just finished configuring my Kate installation for 
highlighting D code as a temporary solution. Just one well 
provisioned IDE would be significant for the community.
Nov 04 2020
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, 4 Nov 2020, 2:50 am frame via Digitalmars-d, <
digitalmars-d puremagic.com> wrote:


 On Sunday, 11 October 2020 at 11:24:42 UTC, Imperatorn wrote:

 D is not present anywhere in languages to learn... Why?
 (I get that it can be a chicken and egg problem)

 When looking for languages to learn, you have to start
 "somewhere".

 How do we make D part of this "somewhere"?

 Thanks


 I want to add my 2 cent as newbie:


 is less popular. It this a benefit?

 - It's likely that users need a library. This library may exists
 as D code but even the search for that library is not intuitive.
 You have to try multiple terms or browse manually for the
 library, this is bad. Also the library seems to be outdated while
 the C library developers just did a new release and you could
 assume the D-lib is just dead. This makes D look more like an
 experiment than a living standard.

 - The offical library reference is visually "unfriendly". For
 example, devdocs.io do a better job. On the D-site, it looks not
 well formatted. I am loosing focus while reading on some
 locations. The search engine is unsatisfying. Even that I can't
 format code in forums bothers me, because that are standard
 features and they just not there. This appears as "unfinished",
 we are not in year 1998.

 - D also needs a new modern, _just working_ IDE with syntax
 highlighting, formatting, autocomplete hints, quick
 documentation. I've tried the Dlang IDE, VisualD, WebFreak-D or
 other Plugins for Visual Studio and IDEA. Plugins either do not
 work well, get broken with never versions (eg. MonoDevelop) but
 also true for VS Code. You see quickly that event VisualD is just
 a plugin which is buggy, crashes and does not really integrate
 well (sepearate build options, passing arguments ignored, etc).


It sounds like you have used VisualD incorrectly.
It sounds to me like you did not use the D/VC++ project template, which is
msbuild native, and works extremely well. Maybe you used the old project
format from 5 years ago... I think that's still in there, but you shouldn't
use it today.
Look for the D/VC++ project wizard, and try your evaluation again.



Also realtime debugging is a pain, eg with VisualD: If you are

 lucky it will display the stack correctly - but it has problems
 with template functions and it show your structs in initial state
 rather actual value. I could not run the debugger in VS Code, it
 runs/breaks but shows nothing and it's not my job to report bugs
 to plugin-devs that just don't have the time to fix them. I could
 also only run partial debugging on IntelliJ IDEA since variables
 are not updated on change - there is always such an issue and the
 list goes on...

 Of course this is offtopic by the language itself but it has a
 heavy influence if I would try a new language which tools are
 only working on the command line out of the box. You may get the
 point, if you want to attract new users, you need a supported,
 working welcome packet just as an IDE with friendly features so
 the users can just start making experiences.
Nov 05 2020
parent reply frame <frame86 live.com> writes:
On Friday, 6 November 2020 at 04:48:42 UTC, Manu wrote:


 It sounds like you have used VisualD incorrectly.
 It sounds to me like you did not use the D/VC++ project 
 template, which is
 msbuild native, and works extremely well. Maybe you used the 
 old project
 format from 5 years ago... I think that's still in there, but 
 you shouldn't
 use it today.
 Look for the D/VC++ project wizard, and try your evaluation 
 again.


Yes, the integration is better with the D/VC++ template and 
passing arguments work. However, dmdserver.exe is still crashing 
by my code for example and default build action leads to link 
errors while the outside "Compile and Debug" command from the 
plugin menu works as expected.
Nov 06 2020
parent reply Jack <jckj33 gmail.com> writes:
On Saturday, 7 November 2020 at 03:23:06 UTC, frame wrote:

 On Friday, 6 November 2020 at 04:48:42 UTC, Manu wrote:


 It sounds like you have used VisualD incorrectly.
 It sounds to me like you did not use the D/VC++ project 
 template, which is
 msbuild native, and works extremely well. Maybe you used the 
 old project
 format from 5 years ago... I think that's still in there, but 
 you shouldn't
 use it today.
 Look for the D/VC++ project wizard, and try your evaluation 
 again.


 Yes, the integration is better with the D/VC++ template and 
 passing arguments work. However, dmdserver.exe is still 
 crashing by my code for example and default build action leads 
 to link errors while the outside "Compile and Debug" command 
 from the plugin menu works as expected.


what's dmdserver.exe? is this visual studio's stuff?
Nov 11 2020
parent frame <frame86 live.com> writes:
On Wednesday, 11 November 2020 at 16:23:06 UTC, Jack wrote:


 what's dmdserver.exe? is this visual studio's stuff?


It's part of the VisualD package, a bundeld DCD, scanner, 
something. And it seems also to leak memory.
Nov 11 2020
prev sibling parent reply Palak <plksharma481 gmail.com> writes:
Hi this is Palak
Well D has been successfully used for AAA games, language 
interpreters, virtual machines, an operating system kernel, GPU 
programming, web development, numerical analysis, GUI 
applications, a passenger information system, machine learning, 
text processing, web and application servers and research.
Well there are lot of other top programming languages you must 
learn, you can see it by opening below link.
https://www.techgeekbuzz.com/blog/top-programming-languages-to-learn/
Thanks
Jul 17 2022
parent Dukc <ajieskola gmail.com> writes:
On Monday, 18 July 2022 at 06:02:10 UTC, Palak wrote:

 Hi this is Palak
 Well D has been successfully used for AAA games, language 
 interpreters, virtual machines, an operating system kernel, GPU 
 programming, web development, numerical analysis, GUI 
 applications, a passenger information system, machine learning, 
 text processing, web and application servers and research.
 Well there are lot of other top programming languages you must 
 learn, you can see it by opening below link.
 https://www.techgeekbuzz.com/blog/top-programming-languages-to-learn/
 Thanks


Please do not resurrect old threads without an exceptional 
reason, especially not about a subject like this that [tends to 
result in an eternal 
thread](https://forum.dlang.org/post/fipbesowuzwyovdcjoio forum.dlang.org)
Jul 18 2022