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
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
ok zoomer
Jun 05
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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