www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D Dead?

reply The Reaper <Reaper Death.org> writes:
It seems like it, after a year or so hiatus there is very little 
activity. Seems like D is gone as I predicted it would be because 
of the lack of passion to push it forward and turn it in to a 
competitive modern project. Boomers killed D ;/
Jun 05 2021
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
ok zoomer
Jun 05 2021
prev sibling next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

 It seems like it, after a year or so hiatus there is very 
 little activity. Seems like D is gone as I predicted it would 
 be because of the lack of passion to push it forward and turn 
 it in to a competitive modern project. Boomers killed D ;/


No
Jun 05 2021
prev sibling next sibling parent reply =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
On Sat, 2021-06-05 at 23:33 +0000, The Reaper via Digitalmars-d wrote:

 It seems like it, after a year or so hiatus there is very little=20
 activity. Seems like D is gone as I predicted it would be because=20
 of the lack of passion to push it forward and turn it in to a=20
 competitive modern project. Boomers killed D ;/


No.

Firstly, you should see the definition of dead:
https://www.merriam-webster.com/dictionary/dead

Secondly, visit https://github.com/dlang/ and see the stats by yourself
;)

--=20
Sincerely,
Lu=C3=ADs Ferreira   lsferreira.net
Jun 05 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 June 2021 at 00:55:51 UTC, Luís Ferreira wrote:

 Secondly, visit https://github.com/dlang/ and see the stats by 
 yourself ;)


If you do a github search on new repos since 1. january you'll 
find that D and Zig has 4-500, Nim has 6-700, Crystal 5-600, Haxe 
7-800.

So D has basically the same activity as Zig, Nim and Crystal.

Other languages:

Pascal: 3K+
Rust: 30K+
Swift: 70K+
Dart: 100K+
C++: 260K+
Jun 06 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 June 2021 at 09:10:50 UTC, Ola Fosheim Grøstad wrote:

 On Sunday, 6 June 2021 at 00:55:51 UTC, Luís Ferreira wrote:

 Secondly, visit https://github.com/dlang/ and see the stats by 
 yourself ;)


 If you do a github search on new repos since 1. january you'll 
 find that D and Zig has 4-500, Nim has 6-700, Crystal 5-600, 
 Haxe 7-800.


Another measure, repos that have been created in the past 5 years 
an which have more than 10 stars:

Zig: 199
D: 236
Crystal: 609
Nim: 665
Pascal: 929
Jun 06 2021
prev sibling parent reply Jack Applegame <japplegame gmail.com> writes:
On Sunday, 6 June 2021 at 09:10:50 UTC, Ola Fosheim Grøstad wrote:

 If you do a github search on new repos since 1. january you'll 
 find that D and Zig has 4-500, Nim has 6-700, Crystal 5-600, 
 Haxe 7-800.

 So D has basically the same activity as Zig, Nim and Crystal.

 Other languages:

 Pascal: 3K+
 Rust: 30K+
 Swift: 70K+
 Dart: 100K+
 C++: 260K+


Does it mean that D is dead?
Jun 06 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 June 2021 at 10:15:42 UTC, Jack Applegame wrote:

 Does it mean that D is dead?


No, I think it means that the small languages are splitting the 
alternative-languages-hobbyist crowd between them?

They are surprisingly even.
Jun 06 2021
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Sunday, 6 June 2021 at 10:15:42 UTC, Jack Applegame wrote:

 Does it mean that D is dead?


I don't think so:

- D Discord users are up +100% in one year

- dlang bot-free download stats: 
http://erdani.com/d/downloads.daily.png, up +25% year on year

It would be interesting to have other metrics, like repo created 
on Github/Gitlab year on year or funding of the D Foundation.
Jun 06 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 June 2021 at 13:36:20 UTC, Guillaume Piolat wrote:

 It would be interesting to have other metrics, like repo 
 created on Github/Gitlab year on year or funding of the D 
 Foundation.


But try to look at repos with high star count for D (and other 
languages) on GitHub.

Most of them are not bread-and-butter (except for some 
web-stuff), I think?

Is that because people tend to use only Phobos, Mir and Vibe?  
Anyway, it suggests that people don't focus on building 
libraries. So maybe people don't find the language easy enough to 
use for that purpose? Dunno.

It could also mean that the more language-oriented programmers 
have moved on to explore newer languages, and that D are 
appealing more to utility oriented programers.

The number of repos with more than 10 stars was lower than I 
would expect.
Jun 06 2021
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 6 June 2021 at 13:59:17 UTC, Ola Fosheim Grøstad wrote:

 But try to look at repos with high star count for D (and other 
 languages) on GitHub.

 Most of them are not bread-and-butter (except for some 
 web-stuff), I think?

 Is that because people tend to use only Phobos, Mir and Vibe?  
 Anyway, it suggests that people don't focus on building 
 libraries. So maybe people don't find the language easy enough 
 to use for that purpose? Dunno.


People don’t write libraries because it is easy, people write 
libraries when they need libraries. People don’t need many 
libraries written when linking existing C libraries is well 
supported.


 It could also mean that the more language-oriented programmers 
 have moved on to explore newer languages, and that D are 
 appealing more to utility oriented programers.


Why would language-oriented programmers produce high star count 
GitHub repositories? Wouldn’t you consider yourself a 
language-oriented programmer?


 The number of repos with more than 10 stars was lower than I 
 would expect.


When I find a dub library that covers my needs I am happy and use 
it. I’m not clicking through to its repository to star it. Maybe 
I should.

I am more concerned with my own productivity than the popularity 
of the tools that I use. I know I am not the only one to think 
like this.

My personal advice to people complaining about progress: spend 
less time on these forums, spend more time coding.

— Bastiaan.
Jun 06 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 June 2021 at 15:50:20 UTC, Bastiaan Veelo wrote:

 People don’t write libraries because it is easy, people write 
 libraries when they need libraries. People don’t need many 
 libraries written when linking existing C libraries is well 
 supported.


Many people write libraries as exercises. Yes, maybe C libraries 
have an impact.


 Why would language-oriented programmers produce high star count 
 GitHub repositories? Wouldn’t you consider yourself a 
 language-oriented programmer?


Well, I just noticed there are not many D libraries that has been 
started in the past 5 years that have a high star count. I would 
assume that if people appreciate a library then they would give 
it a star? So, there were fewer new libs than I would expect.


 When I find a dub library that covers my needs I am happy and 
 use it. I’m not clicking through to its repository to star it.


Yes, understand, but other languages also have package-managers.
Jun 06 2021
prev sibling parent reply JN <666total wp.pl> writes:
On Sunday, 6 June 2021 at 13:59:17 UTC, Ola Fosheim Grøstad wrote:

 Is that because people tend to use only Phobos, Mir and Vibe?  
 Anyway, it suggests that people don't focus on building 
 libraries. So maybe people don't find the language easy enough 
 to use for that purpose? Dunno.


I think D's flexibility makes it a little harder to create 
libraries. As soon as you start the project, you have to make 
some hard choices. GC or nogc, betterC? Use exceptions? Use OOP? 
Every choice you make will alienate some people.
Jun 08 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 8 June 2021 at 20:35:40 UTC, JN wrote:

 I think D's flexibility makes it a little harder to create 
 libraries. As soon as you start the project, you have to make 
 some hard choices. GC or nogc, betterC? Use exceptions? Use 
 OOP? Every choice you make will alienate some people.


Good point. I guess betterC is the lowest common denominator.
Jun 08 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 6 June 2021 at 13:36:20 UTC, Guillaume Piolat wrote:

 It would be interesting to have other metrics, like repo 
 created on Github/Gitlab year on year


Ok, so this is not so easy since people delete repos and the 
github search function gives different results for each search... 
But let us try year by year (June to June):

2020 900
2019 1500 ∆600
2018 1900 ∆400
2017 2700 ∆800
2016 3200 ∆500
2015 4000 ∆800
2014 5200 ∆1200
2013 6400 ∆1200
2012 7700 ∆1300
2011 8300 ∆600

So if these numbers are correct the activity was cut in half 
around 2014. When Rust hit 1.0.
Jun 06 2021
prev sibling next sibling parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

 It seems like it, after a year or so hiatus there is very 
 little activity. Seems like D is gone as I predicted it would 
 be because of the lack of passion to push it forward and turn 
 it in to a competitive modern project. Boomers killed D ;/


A dead man ECG: 
[irc://irc.libera.chat/d-feed](irc://irc.libera.chat/d-feed)
Jun 06 2021
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

 It seems like it, after a year or so hiatus there is very 
 little activity. Seems like D is gone as I predicted it would 
 be because of the lack of passion to push it forward and turn 
 it in to a competitive modern project. Boomers killed D ;/


D is alive and well, but is has no hype
Jun 06 2021
prev sibling next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

 It seems like it, after a year or so hiatus there is very 
 little activity. Seems like D is gone as I predicted it would 
 be because of the lack of passion to push it forward and turn 
 it in to a competitive modern project. Boomers killed D ;/


Any actual details/markers on why D is dead, so we can refute 
your points, or is this just a redditor in disguise being all 
doom and gloomy?
Jun 06 2021
prev sibling next sibling parent Martin <martin.brzenska googlemail.com> writes:
On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

 Is D Dead?


Depends on the definition of "alive"
Jun 08 2021
prev sibling next sibling parent reply lili <lilijreey 126.com> writes:
No, But it's on the way, lack useful library, lack ecosystem.
Jun 09 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 9 June 2021 at 15:25:59 UTC, lili wrote:

 No, But it's on the way, lack useful library, lack ecosystem.


Is this really true tho? What are you missing? 🤔
Jun 09 2021
prev sibling parent reply Kenneth Dallmann <fake 123.con> writes:
On Saturday, 5 June 2021 at 23:33:59 UTC, The Reaper wrote:

 It seems like it, after a year or so hiatus there is very 
 little activity. Seems like D is gone as I predicted it would 
 be because of the lack of passion to push it forward and turn 
 it in to a competitive modern project. Boomers killed D ;/


C has been around for a long time and is the de facto language of 
almost everything. To my understanding, Rust and D are the only 
two languages that can compete.

D is certainly not dead and it's lack of popularity doesn't mean 
it is less valuable either.
I can explain why:

    D is fluent with C, so you can access the libraries made in C.

    D has a full range of OOP features that is unparalleled in the 
systems level paradigm. The only competitor is C++, and that 
language has become syntatically displeasing.



I can highlight some strengths and weaknesses:

     D has a full range of OOP features; clean syntax; garbage 
collection, like some of the most popular languages now, like 
Java and Python; full access to hardware and assembly friendly; 
and OOP in D can be implemented in a very precise way, thanks to 
structs and classes.

     On the flip side: D's garbage collection adds runtime 
overhead.
For bit by bit performance I would probably choose Rust over D, 
however unless you're programming very small embedded devices the 
performance differences are likely trivial.
Sep 13 2021
parent reply IGotD- <nise nise.com> writes:
On Monday, 13 September 2021 at 18:31:59 UTC, Kenneth Dallmann 
wrote:

 C has been around for a long time and is the de facto language 
 of almost everything. To my understanding, Rust and D are the 
 only two languages that can compete.


It's a little bit more than that. Contenders to C are

C++
D
Rust
Nim
Zig

My criteria is that the languages work on bare metal with minimum 
library support. Some made Go work with small embedded systems 
but still requires a runtime so I don't consider Go to be a 
contender. D barely qualifies for this category as there are so 
many library functions that require GC. If betterC didn't exist I 
would have excluded D.
Sep 13 2021
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 13 September 2021 at 20:04:01 UTC, IGotD- wrote:

 On Monday, 13 September 2021 at 18:31:59 UTC, Kenneth Dallmann 
 wrote:

 C has been around for a long time and is the de facto language 
 of almost everything. To my understanding, Rust and D are the 
 only two languages that can compete.


 It's a little bit more than that. Contenders to C are

 C++
 D
 Rust
 Nim
 Zig

 My criteria is that the languages work on bare metal with 
 minimum library support. Some made Go work with small embedded 
 systems but still requires a runtime so I don't consider Go to 
 be a contender. D barely qualifies for this category as there 
 are so many library functions that require GC. If betterC 
 didn't exist I would have excluded D.


You might not consider it a contender, but business that matter 
do,

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

https://gvisor.dev

https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods

https://blog.arduino.cc/2019/08/23/tinygo-on-arduino
Sep 13 2021
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 14 September 2021 at 06:12:37 UTC, Paulo Pinto wrote:

 You might not consider it a contender, but business that matter 
 do,

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

 https://gvisor.dev

 https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods

 https://blog.arduino.cc/2019/08/23/tinygo-on-arduino


Can TinyGo totally drop the runtime and manage memory 
`malloc`/`free` style? If so, that makes it a true systems 
language IMO. And if it can, how much of the language is still 

principle a systems language if compiled to binary code, but it's 
a bad one because it's so crippled in that domain (I mean 

better.).

Whether it can run on a low-power low-memory platform does not 
determine whether the language is a systems language, though that 
ability is still cool and useful. Home computers of the 80s ran 
BASIC but weren't powerful enough for C++ exception handling IIRC 
Walters stories correctly. Still it's C++ and not BASIC that is 
considered the systems language.
Sep 14 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 14 September 2021 at 09:17:40 UTC, Dukc wrote:

 On Tuesday, 14 September 2021 at 06:12:37 UTC, Paulo Pinto 
 wrote:

 [...]


 Can TinyGo totally drop the runtime and manage memory 
 `malloc`/`free` style? If so, that makes it a true systems 
 language IMO. And if it can, how much of the language is still 

 principle a systems language if compiled to binary code, but 
 it's a bad one because it's so crippled in that domain (I mean 

 better.).

 Whether it can run on a low-power low-memory platform does not 
 determine whether the language is a systems language, though 
 that ability is still cool and useful. Home computers of the 
 80s ran BASIC but weren't powerful enough for C++ exception 
 handling IIRC Walters stories correctly. Still it's C++ and not 
 BASIC that is considered the systems language.


A systems programming language is one that can be used to write 
the full stack OS in it, period.

As for being able to drop the runtime to be considered a systems 
programming language, I guess that rules out Ada and C++ then.
Sep 14 2021
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 14 September 2021 at 09:21:07 UTC, Paulo Pinto wrote:

 A systems programming language is one that can be used to write 
 the full stack OS in it, period.


I guess there are as many definitions as there are programmers 
for "systems programming language". But regardless of the 
definition, I'm interested: can you write a Go program without 
it's GC, and how much of the language is usable without it, if?


 As for being able to drop the runtime to be considered a 
 systems programming language, I guess that rules out Ada and 
 C++ then.


I'm pretty sure you can drop the extra parts of C++ runtime with 
the linkers unused symbol stripper, if nothing else. Granted, 
that only works if you don't use the parts of C++ runtime you 
want to drop but it is still reasonable to use it that way.
Sep 14 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 14 September 2021 at 09:37:38 UTC, Dukc wrote:

 On Tuesday, 14 September 2021 at 09:21:07 UTC, Paulo Pinto 
 wrote:

 A systems programming language is one that can be used to 
 write the full stack OS in it, period.


 I guess there are as many definitions as there are programmers 
 for "systems programming language". But regardless of the 
 definition, I'm interested: can you write a Go program without 
 it's GC, and how much of the language is usable without it, if?


Why should I constrain myself, GC has a place in systems 
programming as proven by stuff being shipped in production, more 
so than what D has achieved thus far.

So apparently Go not fitting your definition of systems 
programming language doesn't hinder it having more success in the 
market on that regard.


 As for being able to drop the runtime to be considered a 
 systems programming language, I guess that rules out Ada and 
 C++ then.


 I'm pretty sure you can drop the extra parts of C++ runtime 
 with the linkers unused symbol stripper, if nothing else. 
 Granted, that only works if you don't use the parts of C++ 
 runtime you want to drop but it is still reasonable to use it 
 that way.


Indeed, by making use of language extensions and compiler 
specific implementations not defined by ISO C++.

And I am not defending arguing Go only.

PTC Java, Aicas Java, microEJ, Meadow .NET are also part of what 
I would consider.

Including D, with a minimal runtime instead of stuff like 
DasBetterC.
Sep 14 2021
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 14 September 2021 at 11:36:30 UTC, Paulo Pinto wrote:

 Why should I constrain myself, GC has a place in systems 
 programming as proven by stuff being shipped in production, 
 more so than what D has achieved thus far.


And I didn't say "GC does not belong to systems programming". I 
asked whether Go can do without GC if someone wants to manage 
memory 100% manually anyway?



 So apparently Go not fitting your definition of systems 
 programming language doesn't hinder it having more success in 
 the market on that regard.


Not pushing my definition of systems programming to the 
dictionary. In hindsight it was stupid for me to even bring it 
up, since I don't know it's formal definition if there even is 
one.



 And I am not defending arguing Go only.

 PTC Java, Aicas Java, microEJ, Meadow .NET are also part of 
 what I would consider.

 Including D, with a minimal runtime instead of stuff like 
 DasBetterC.


Hmm, DasBetterC and C have an underlying runtime too. I think 
you're saying that such a minimal runtime C has is an outdated 
approach, that a high-language should have a heavier runtime than 
that even when doing systems programming? And the real-low level 
stuff where you just can't use the GC but could use 
C++/Rust/DasBetterC (like some device drivers and the 
implementation of GC) are so few that it's just better to use C 
or assembly there? That it's not worthwhile for higher-level 
languages to target that niche?

I'm actually fairly neutral on that argument when talking about 
languages in general. I don't know about bare-metal programming 
enough to be sure. But D is pretty much committed to support the 
said niche, so I don't think reversing that decision is a good 
idea even if the niche isn't that important in general.
Sep 14 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 14 September 2021 at 12:52:00 UTC, Dukc wrote:

 On Tuesday, 14 September 2021 at 11:36:30 UTC, Paulo Pinto 
 wrote:

 [...]


 And I didn't say "GC does not belong to systems programming". I 
 asked whether Go can do without GC if someone wants to manage 
 memory 100% manually anyway?

 [...]


Imo, D would/could be the perfect fit for embedded
Sep 14 2021
prev sibling parent reply Paulo Pnito <pjmlp progtools.org> writes:
On Tuesday, 14 September 2021 at 12:52:00 UTC, Dukc wrote:

 On Tuesday, 14 September 2021 at 11:36:30 UTC, Paulo Pinto 
 wrote:

 Why should I constrain myself, GC has a place in systems 
 programming as proven by stuff being shipped in production, 
 more so than what D has achieved thus far.


 And I didn't say "GC does not belong to systems programming". I 
 asked whether Go can do without GC if someone wants to manage 
 memory 100% manually anyway?


Well, Go is bootstraped and the GC is written in Go itself.

https://github.com/golang/go/blob/master/src/runtime/malloc.go

In any case, just like C and C++ have subsets for embedded use, 
in TamaGo you can for example do DMA in plain Go code.

https://github.com/f-secure-foundry/tamago/blob/master/dma/alloc.go

https://github.com/f-secure-foundry/tamago/blob/master/dma/dma.go

https://github.com/f-secure-foundry/tamago/blob/master/soc/bcm2835/dma.go

Naturally there is some Assembly, just like even C needs Assembly 
for the features not available in ISO C.


 ...

 Hmm, DasBetterC and C have an underlying runtime too. I think 
 you're saying that such a minimal runtime C has is an outdated 
 approach, that a high-language should have a heavier runtime 
 than that even when doing systems programming? And the real-low 
 level stuff where you just can't use the GC but could use 
 C++/Rust/DasBetterC (like some device drivers and the 
 implementation of GC) are so few that it's just better to use C 
 or assembly there? That it's not worthwhile for higher-level 
 languages to target that niche?

 I'm actually fairly neutral on that argument when talking about 
 languages in general. I don't know about bare-metal programming 
 enough to be sure. But D is pretty much committed to support 
 the said niche, so I don't think reversing that decision is a 
 good idea even if the niche isn't that important in general.


Coming back to D, basically my point is that GC is part of the 
productivity equation, even in systems programming.

Naturally there are scenarios where any kind of memory allocation 
is a no-go, those where SPARK, MISRA-C and formal methods are the 
only options.

However there are plenty of other kinds of deployment scenarios, 
where those strict requirements don't play a role and as such, D 
can be a good choice with the runtime for the ride.

If you prefer one of those typical car analogies, classical 
manual memory management is like driving stick with fossil fuel, 
while using D with all its features, is driving a Porsche Taycan.

Surely there are plenty of cases where the old technology still 
wins out, yet the trend is clear.
Sep 14 2021
parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 14 September 2021 at 20:31:24 UTC, Paulo Pnito wrote:

 Well, Go is bootstraped and the GC is written in Go itself.

 https://github.com/golang/go/blob/master/src/runtime/malloc.go

 In any case, just like C and C++ have subsets for embedded use, 
 in TamaGo you can for example do DMA in plain Go code.


So Go isn't totally dependent on the GC, just like D isn't. Good 
to know - I won't make myself silly by claiming otherwise in 
future debates. And your original point, that Go is a contender 
in systems programming space, is easy to believe when the 
language implements it's own GC.


 Coming back to D, basically my point is that GC is part of the 
 productivity equation, even in systems programming.

 Naturally there are scenarios where any kind of memory 
 allocation is a no-go, those where SPARK, MISRA-C and formal 
 methods are the only options.


No disagreement here. I have seen many others here say the same.


 If you prefer one of those typical car analogies, classical 
 manual memory management is like driving stick with fossil 
 fuel, while using D with all its features, is driving a Porsche 
 Taycan.


And the best cars are ones that are automatic by default but can 
switch manually if need be. For example, when you're driving a 
downhill route you might want to use a lower gear than normal to 
save your brake pads. JavaScript would I think be the car with 
absolutely no manual gear control and runs the risk of 
overheating it's brakes as a result.
Sep 16 2021
prev sibling parent reply Kenneth Dallmann <fake 123.con> writes:
On Monday, 13 September 2021 at 20:04:01 UTC, IGotD- wrote:

 On Monday, 13 September 2021 at 18:31:59 UTC, Kenneth Dallmann 
 wrote:

 C has been around for a long time and is the de facto language 
 of almost everything. To my understanding, Rust and D are the 
 only two languages that can compete.


 It's a little bit more than that. Contenders to C are

 C++
 D
 Rust
 Nim
 Zig

 My criteria is that the languages work on bare metal with 
 minimum library support. Some made Go work with small embedded 
 systems but still requires a runtime so I don't consider Go to 
 be a contender. D barely qualifies for this category as there 
 are so many library functions that require GC. If betterC 
 didn't exist I would have excluded D.



Yeah, C++ is a contender.  I don't know about Nim or Zig.
C++ is visually displeasing to some, that's why I don't like it.

I'm no expert, but I believe that Rust and D are sharing opposite 
strengths and
weaknesses.

Rust could be a good alternative to C, but like C it doesn't have 
a full set
of OOP features.

D has a full set of OOP features, but it may not play as well 
with pointers and
bare metal code as Rust.

Rust or C for absolute minimal runtime and most control and D or 
C++ for OOP.

C++ is my least favorite.

D is like if Java and C had a baby.   It has the high level 
features that make
interpreted languages easy and memory safe to write but also 
pointers.

It seems like those two things can be a bad mix though.

There might be some potholes in the design of D.  I think if I 
were to design
something like D I would follow Rust's example for memory 
management, and then
add in GC as an optional feature.
Sep 14 2021
next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann 
wrote:

 D has a full set of OOP features, but it may not play as well 
 with pointers and
 bare metal code as Rust.


Yes and no. In betterC classes are disabled as well as TypeInfo. 
In betterC you have to use structs and structs do not provide 
full OOP features, only composition (there are hacks around this 
I've seen). For many systems structs are enough but sometimes you 
want full classes with inheritance and virtual methods. I would 
like that betterC could allow classes as well as TypeInfo. For 
very small embedded system TypeInfo might just eat up important 
space but for medium or large ones, TypeInfo can actually help.

In the ideal world I would like that the OOP features of D 
becomes more bare metal friendly. This also leads into the memory 
management discussion, but I'll leave that out in this thread.

I've also read the Rust is disliked for small embedded systems 
because of the restrictive memory model. People seem to flee to 
other programming languages for like Zig if it is not C/C++. I 
think D can position itself better here if we can get our act 
together when it comes to the memory model.
Sep 14 2021
next sibling parent drug <drug2004 bk.ru> writes:
14.09.2021 21:46, IGotD- пишет:

 On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann wrote:

 D has a full set of OOP features, but it may not play as well with 
 pointers and
 bare metal code as Rust.


 
 Yes and no. In betterC classes are disabled as well as TypeInfo. In 
 betterC you have to use structs and structs do not provide full OOP 
 features, only composition (there are hacks around this I've seen). For 
 many systems structs are enough but sometimes you want full classes with 
 inheritance and virtual methods. I would like that betterC could allow 
 classes as well as TypeInfo. For very small embedded system TypeInfo 
 might just eat up important space but for medium or large ones, TypeInfo 
 can actually help.
 
 In the ideal world I would like that the OOP features of D becomes more 
 bare metal friendly. This also leads into the memory management 
 discussion, but I'll leave that out in this thread.
 
 I've also read the Rust is disliked for small embedded systems because 
 of the restrictive memory model. People seem to flee to other 
 programming languages for like Zig if it is not C/C++. I think D can 
 position itself better here if we can get our act together when it comes 
 to the memory model.


I don't test it but can't you use extern(C++) classes in DasBetterC mode?
Sep 14 2021
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Tuesday, 14 September 2021 at 18:46:09 UTC, IGotD- wrote:

 In betterC classes are disabled as well as TypeInfo.


You can actually still use extern(C++) classes even with -betterC.

Strangely though interfaces don't work there, but probably just 
an oversight bug (betterC is all about arbitrary limitations...).


But -betterC sucks anyway. Just use a minimal custom runtime and 
get exactly what you want!

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_07_27.html#zero-runtime-classes
Sep 14 2021
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/14/2021 11:03 AM, Kenneth Dallmann wrote:

 There might be some potholes in the design of D.  I think if I were to design
 something like D I would follow Rust's example for memory management, and then
 add in GC as an optional feature.


GC already is an optional feature in D.
Sep 15 2021
next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright 
wrote:

 GC already is an optional feature in D.


It depends what you mean by that, arrays and about all other data 
structures rely on GC. Also entire Phobos require GC.

D without any libraries does not rely on GC but then you have 
removed many useful features of the language. The situation is 
similar with C++ but there the library only depends on 
malloc/free without any extra memory penalty and tracing penalty.
Sep 15 2021
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 15/09/2021 10:28 PM, IGotD- wrote:

 On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright wrote:

 GC already is an optional feature in D.


 
 It depends what you mean by that, arrays and about all other data 
 structures rely on GC. Also entire Phobos require GC.


False. std.traits works just fine ;)

std.format could work if it wasn't for exceptions!


 D without any libraries does not rely on GC but then you have removed 
 many useful features of the language. The situation is similar with C++ 
 but there the library only depends on malloc/free without any extra 
 memory penalty and tracing penalty.


There really are only 3 features that you end up missing in -betterC, 
aside from the GC.

Exceptions, classes, TLS.

Classes are slowly coming along, but they are being resolved.
https://issues.dlang.org/show_bug.cgi?id=21416 is as far as I'm aware 
one of the few bugs associated with it.

TLS is out of the question as far as I'm aware.

Exceptions, using stack unwinding do need a runtime, so they are out, 
but I *really* want to see that resolved. I'd love to see an alternative 
to heap allocated stack unwinding exceptions in D.
Sep 15 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 15 September 2021 at 10:35:50 UTC, rikki cattermole 
wrote:

 On 15/09/2021 10:28 PM, IGotD- wrote:

 [...]


 False. std.traits works just fine ;)

 std.format could work if it wasn't for exceptions!


 [...]


 There really are only 3 features that you end up missing in 
 -betterC, aside from the GC.

 Exceptions, classes, TLS.

 Classes are slowly coming along, but they are being resolved.
 https://issues.dlang.org/show_bug.cgi?id=21416 is as far as I'm 
 aware one of the few bugs associated with it.

 TLS is out of the question as far as I'm aware.

 Exceptions, using stack unwinding do need a runtime, so they 
 are out, but I *really* want to see that resolved. I'd love to 
 see an alternative to heap allocated stack unwinding exceptions 
 in D.


Why is TLS out of question, when it is a standard C11 feature?
Sep 15 2021
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 15/09/2021 11:43 PM, Paulo Pinto wrote:

 Why is TLS out of question, when it is a standard C11 feature?


-betterC can be used without a libc.

It is also a different implementation compiler hook wise to regular D.

The problem is, regardless of who implements it, it still needs a runtime.
Sep 15 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 15 September 2021 at 11:43:19 UTC, Paulo Pinto 
wrote:

 Why is TLS out of question, when it is a standard C11 feature?


TLS doesn't play well with embedded systems. TLS is an OS related 
feature and not all OS:es support TLS among the small embedded 
ones. In general, we should avoid TLS as much we can because it's 
horrible under the hood.

Many languages support TLS including C++ and Rust. It's there to 
give the programmer the opportunity to use it.
Sep 15 2021
parent reply Araq <rumpf_a web.de> writes:
On Wednesday, 15 September 2021 at 14:48:56 UTC, IGotD- wrote:

 TLS doesn't play well with embedded systems. TLS is an OS 
 related feature and not all OS:es support TLS among the small 
 embedded ones. In general, we should avoid TLS as much we can 
 because it's horrible under the hood.


To emulate TLS allocate a block of memory at the top/bottom of 
your stack and use a bitmask on your stack pointer in order to 
access it. No OS support required.
Sep 15 2021
next sibling parent Reimer Behrends <behrends gmail.com> writes:
On Thursday, 16 September 2021 at 05:59:57 UTC, Araq wrote:

 To emulate TLS allocate a block of memory at the top/bottom of 
 your stack and use a bitmask on your stack pointer in order to 
 access it. No OS support required.


This can be pretty fast and portable, but there are some 
additional challenges with separate compilation.

Without separate compilation, you can generate constant offsets 
into the TLS area at compile time; with separate compilation, you 
either need to somehow bake this into the linking step or figure 
out offsets at runtime.

Likewise for the stack size, which must be consistent across all 
separately compiled modules.

But even with those constraints, it can still be a pretty good 
option.
Sep 16 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 16 September 2021 at 05:59:57 UTC, Araq wrote:

 To emulate TLS allocate a block of memory at the top/bottom of 
 your stack and use a bitmask on your stack pointer in order to 
 access it. No OS support required.


The TLS standard requires the OS to initialize the TLS area for 
each new thread so OS support is required. You have size 
constraints when you put TLS on the stack. If some bright 
programmer decides to have several megabytes of data as TLS, this 
is not an option but this is a fringe case though. If your OS 
supports shared libraries, the implementation becomes much more 
complicated.

The C++ standard doesn't support contructors/deconstuctors in the 
TLS area, only simple zero and copy initialization is supported. 
D makes this more complicated as it supports 
contructors/deconstuctors in TLS. Because of this TLS increases 
the time for spawning new threads, especially in D and this 
regardless if the thread use any TLS variable or not.

If you have a single thread program, you can use the GCC TLS 
emulation.

The TLS standard feels rushed and shoved in with a shoehorn. 
There are several fringe cases to deal with.
Sep 16 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 16 September 2021 at 10:04:22 UTC, IGotD- wrote:

 On Thursday, 16 September 2021 at 05:59:57 UTC, Araq wrote:

 [...]


 The TLS standard requires the OS to initialize the TLS area for 
 each new thread so OS support is required. You have size 
 constraints when you put TLS on the stack. If some bright 
 programmer decides to have several megabytes of data as TLS, 
 this is not an option but this is a fringe case though. If your 
 OS supports shared libraries, the implementation becomes much 
 more complicated.

 [...]


What TLS standard?

POSIX, C11, C++11, Java, .NET, Win32 are the only standards that 
come to my mind where some kind of TLS is included, and naturally 
all of them have different semantics.
Sep 16 2021
parent reply IGotD- <nise nise.com> writes:
On Thursday, 16 September 2021 at 11:43:09 UTC, Paulo Pinto wrote:

 What TLS standard?

 POSIX, C11, C++11, Java, .NET, Win32 are the only standards 
 that come to my mind where some kind of TLS is included, and 
 naturally all of them have different semantics.


The TLS standard determined by executable format standard (like 
ELF) and also in the RunTime ABI for the specific CPU 
architecture.
Sep 16 2021
parent reply Araq <rumpf_a web.de> writes:
On Thursday, 16 September 2021 at 15:59:09 UTC, IGotD- wrote:


 The TLS standard determined by executable format standard (like 
 ELF) and also in the RunTime ABI for the specific CPU 
 architecture.


I fail to see how anything of that is relevant for "embedded 
without an OS" development.
Sep 17 2021
parent reply IGotD- <nise nise.com> writes:
On Friday, 17 September 2021 at 13:10:23 UTC, Araq wrote:

 I fail to see how anything of that is relevant for "embedded 
 without an OS" development.


The compiler follows the RunTime ABI for the specific CPU 
architecture. That means how the compiled code accesses the TLS 
variables which is something you cannot completely decide for 
your self.
Sep 17 2021
parent Araq <rumpf_a web.de> writes:
On Friday, 17 September 2021 at 13:14:01 UTC, IGotD- wrote:

 The compiler follows the RunTime ABI for the specific CPU 
 architecture. That means how the compiled code accesses the TLS 
 variables which is something you cannot completely decide for 
 your self.


Well, but the compiler doesn't have to do that as long as the 
semantics of TLS are preserved.
Sep 17 2021
prev sibling parent Kenneth Dallmann <fake 123.con> writes:
On Wednesday, 15 September 2021 at 10:28:05 UTC, IGotD- wrote:

 On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright 
 wrote:

 GC already is an optional feature in D.


 It depends what you mean by that, arrays and about all other 
 data structures rely on GC. Also entire Phobos require GC.

 D without any libraries does not rely on GC but then you have 
 removed many useful features of the language. The situation is 
 similar with C++ but there the library only depends on 
 malloc/free without any extra memory penalty and tracing 
 penalty.




     I just realized, hahaha. Duh. If D can call C or C++ 
libraries then
it doesn't even need a line of D API.

   I'd been reading comments about how API's depend on the GC, but 
on these comment boards
there are people trying to find a place in the world.

   I can say that I'm definitely not the most knowledgable 
programmer or best one, although
I might know a thing or two some others don't.  I think that 
thinking down on others,
or saying that they can't, is one way of making oneself feel 
better when facing insecurities.

   The opinion battle...  Well, D is among C++, Swift and 
Objective C.  I know C++
is a bit hairy, and Objective C, if I remember correctly, doesn't 
have complete error checking, Smalltalk based, more like a 
script.  D is one of the few languages that
has a full range of features.

C is very simple, that's one thing I've come to appreciate. And, 
with C structs you can
still do it all, just not as easily as in a class, but there's 
trade offs.  C can make
something like type checked JS, because you can implement 
prototyping with the structs.


I've had some ideas for a syntax that could hypothetically be a 
discretely simple notation. It would be
space blocked, like Python and I've thought of a trick or two to 
bring the needed symbols
down to a minimum. Also, it could use symbols like -> for 
conditionals, ~> for loops to increase lingual accessibility.  I 
have also thought of a scheme to eliminate try/catch blocks 
altogether, without losing any of their use.
If possible I would opt to eliminate the need for left side 
statement typing, while retaining strong typing.

ty
Sep 17 2021
prev sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright 
wrote:

 GC already is an optional feature in D.


If only the standard library helped make this easier to work with.

We have the half-dead std.experimental.allocator, but no standard 
collections or lifetime containers.

D can shout that the GC is optional, and whilst true, it's only 
half the story.

I'm not even a GC-phobic, but I still see issues here.
Sep 15 2021
next sibling parent SealabJaster <sealabjaster gmail.com> writes:
On Wednesday, 15 September 2021 at 18:55:01 UTC, SealabJaster 
wrote:

 We have the half-dead std.experimental.allocator, but no 
 standard collections or lifetime containers.


* based around allocators.
Sep 15 2021
prev sibling parent russhy <russhy gmail.com> writes:
On Wednesday, 15 September 2021 at 18:55:01 UTC, SealabJaster 
wrote:

 On Wednesday, 15 September 2021 at 10:00:39 UTC, Walter Bright 
 wrote:

 GC already is an optional feature in D.


 If only the standard library helped make this easier to work 
 with.

 We have the half-dead std.experimental.allocator, but no 
 standard collections or lifetime containers.

 D can shout that the GC is optional, and whilst true, it's only 
 half the story.

 I'm not even a GC-phobic, but I still see issues here.


C doesn't have a GC, can use libc, and nobody complain

D can do the same, so why complain? has full access to both libc 
and C libraries, you get  safeties and modern features on top of 
that

GC is optional, i use D myself without the GC most of the time

When memory management doesn't matter, i'm happy that it has the 
GC

Saying GC is not optional is plain and simple not true

D is the perfect tool because it adapts to the problem you want 
to solve

Want to do system level programming, it got you covered

Want to do scripting? it got you covered

Want to do a mix of the two? it gove you covered too
Sep 15 2021
prev sibling parent reply Antonio <antonio abrevia.net> writes:
On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann 
wrote:


 There might be some potholes in the design of D.  I think if I 
 were to design
 something like D I would follow Rust's example for memory 
 management, and then
 add in GC as an optional feature.


One of the advantages of GC is the expressiveness of the language.

See this:

```d
T[] sorted(T)(T[] xs)
{
   return xs.length == 0 ? [] :
     xs[1..$].filter!(x=> x < xs[0]).array.sorted ~
     xs[0..1] ~
     xs[1..$].filter!(x=> x >= xs[0]).array.sorted;
}
void main()
{
     [ 3, 1, 2, 4, 0 ].sorted.writeln;
}

```

You simply can't write this kind of "one expression" syntax with 
Rust... If you try, you still end up with a mental sprain:

```Rust
fn sorted(xs:Vec<f64>)->Vec<f64> {
     return match xs.len() {
         0 => Vec::<f64>::new(),
         _ =>
             sorted( 
xs[1..].iter().filter(|&x|x<=&xs[0]).map(|&x|x).collect() 
).iter().
             chain( iter::once(&xs[0]) ).
             chain( sorted( 
xs[1..].iter().filter(|&x|x>&xs[0]).map(|&x|x).collect() ).iter() 
).
             map(|&x|x).collect(),
     }
}
```

D expressiveness is great...  Rust has not this capability
Sep 15 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 15 September 2021 at 15:51:11 UTC, Antonio wrote:

 On Tuesday, 14 September 2021 at 18:03:32 UTC, Kenneth Dallmann 
 wrote:


 [...]


 One of the advantages of GC is the expressiveness of the 
 language.

 [...]


Agreed. If D could get squeeze out those last 10% I would love to 
use it at work. Also adoption has to increase so the ecosystem 
can flourish
Sep 15 2021