www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why do you continue to use D?

reply aberba <karabutaworld gmail.com> writes:
I personally can't use any other system programming language due 
to the expressiveness and familiarity of D. Its familiar and some 
syntactic expressiveness are just hard to get in other systems 
languages...feels easier to model code in D.

I don't use D primarily for work (Node.Js due to packages and 
cloud support...web services), but D is my go-to system language. 
Personally, wished I could use D for everything.

I like the community here better, I like the engagement and 
support. Yeah, it's not perfect but way better than anywhere else 
I've been.

What are you?
Jun 03
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:

 What are you?
Oops, what about you?
Jun 03
next sibling parent reply Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 Oops, what about you?
As a PhD Student I do lot of coding in Python. We use it (and other languages) to generate high performant C/C++ code. Why am I curious about D and like working with it? 1) Using Python and other dynamic typed languages makes me forget how to program with statically typed languages. I don't like being tied up to only functional (Haskell), to weird templates (C++) or to the JVM (Kotlin). Go doesn't have the expressiveness and I haven't really tried Rust, but I suspect the same. 2) I think D's motto "write fast, read fast, run fast" describes the language pretty well. The syntax is nice. Once you understood "you want to use structs" and "ranges are cool" it really is nice to look at. 3) D's compile time capabilities are fantastic (CTFE, Templates) 4) Community. Lot's of nice and most notably competent people here. 5) I hope to get rid of Python -> C++ some day.
Jun 03
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-06-03 at 17:59 +0000, Jan H=C3=B6nig via Digitalmars-d wrote:
[=E2=80=A6]
 (C++) or to the JVM (Kotlin). Go doesn't have the expressiveness=20
 and I haven't really tried Rust, but I suspect the same.
As ever, what does "expressiveness" mean? For me D and Rust are in the same bucket in terms of what I deem "expressiveness" means with Go much less. [=E2=80=A6]
 5) I hope to get rid of Python -> C++ some day.
I think there are many who would say that D is the static language that Pyt= hon isn't. I suspect I am one of them. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jun 03
prev sibling parent FunkyD <MrFunky YourDaddy.com> writes:
On Wednesday, 3 June 2020 at 17:59:37 UTC, Jan Hönig wrote:
 On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 Oops, what about you?
As a PhD Student I do lot of coding in Python. We use it (and other languages) to generate high performant C/C++ code. Why am I curious about D and like working with it? 1) Using Python and other dynamic typed languages makes me forget how to program with statically typed languages. I don't like being tied up to only functional (Haskell), to weird templates (C++) or to the JVM (Kotlin). Go doesn't have the expressiveness and I haven't really tried Rust, but I suspect the same. 2) I think D's motto "write fast, read fast, run fast" describes the language pretty well. The syntax is nice. Once you understood "you want to use structs" and "ranges are cool" it really is nice to look at. 3) D's compile time capabilities are fantastic (CTFE, Templates) 4) Community. Lot's of nice and most notably competent people here. 5) I hope to get rid of Python -> C++ some day.
You should just learn D, it is not difficult. Then you can make the decision. If you already know several languages you should be able to pick up D quite naturally, specially if you can program in C\C++. Just learn it. As a language, for the most part, it is quite easy. Templates are quite natural. They are sort of just an extension of a typed language. That is, "templates" types are just abstract types. You can always use D for certain things that you find natural once you have learned it. Don't expect much and you won't have any problems. D can be used in other languages so once you know enough about it you'll have an additional tool. I don't use D mainly because the ecosystem, but I have little problem with the language itself. There are a few hairballs but overall it's worth learning. Far better than python, C, C++. Of course, a language is a tool. Ultimately you must use the right tool for the job... but if you have no idea how to use a tool how can you possibly know if it's right? For me, D is good at small utilities. Not much more. Any time I try to write a large app I always come to some issues that makes me want to kill myself. I always think "Man, I'll be able to use all the amazing meta programming to do really cool stuff" and I do but then something basic that I need always destroys any progress I made with meta programming. D is a special language for special people... kinda anal retentive autistics.
Jun 08
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 what about you?
D's systems programming features let me access the full power of the computer and control it precisely. D's powerful meta-programming features allow me to actually use that power and control without having the project take forever, or turn out excessively buggy.
Jun 03
prev sibling next sibling parent Anonymouse <zorael gmail.com> writes:
On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 Oops, what about you?
It's all I know. shrug.
Jun 06
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 Oops, what about you?
I first got into D as I was looking for an object-oriented programming language, that is easier to get into quickly with a Java background than C++. If I had a few more months, I probably have tried C++ instead. Then I stuck with it. It was way more fun to develop with it than any other language I've learned, and somewhat I enjoy writing my own libraries too for stuff that already exists in other programming languages. I've learned way more through them than any class in college.
Jun 08
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
Oops, what about you?
not really much contest in which of the two is better when external factors don't push either choice. D code is easier to keep short, easier to modularize and easier to make performant. suppposed to be a scalable language? A good example is D `x.abs` whole file, not just for one function. Also for a static want to split a class in two, I have to change code calling the member functions. In D I can just need to change some imports, since the functions would be module-level. Can't speak whether I'd prefer D over Rust or Nim since I haven't used either. I suspect they would be around equal overall.
Jun 09
next sibling parent Atwork <fwafwa fwfafa.com> writes:
On Tuesday, 9 June 2020 at 12:05:45 UTC, Dukc wrote:

 be a class, so if I want to split a class in two, I have to 
 change code calling the member functions. In D I can just need 
 to change some imports, since the functions would be 
 module-level.
Jun 09
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 9 June 2020 at 12:05:45 UTC, Dukc wrote:
 On Wednesday, 3 June 2020 at 11:14:13 UTC, aberba wrote:
 On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
Oops, what about you?
is not really much contest in which of the two is better when external factors don't push either choice. D code is easier to keep short, easier to modularize and easier to make performant. suppposed to be a scalable language? A good example is D for the whole file, not just for one function. Also for a so if I want to split a class in two, I have to change code calling the member functions. In D I can just need to change some imports, since the functions would be module-level.
You can achieve that with a mix of partial classes and using
Jun 09
parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 9 June 2020 at 13:06:30 UTC, Paulo Pinto wrote:
 You can achieve that with a mix of partial classes and using 

 side.
I thought about this a bit. Perhaps it goes like this: In D, I I should split files when I want to split what I import. Meaning, if I have two functions and want to import `System.Collections` for only one of them, I should consider splitting them to different files, using the partial class trick. Correct?
Jun 09
prev sibling next sibling parent JN <666total wp.pl> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
I can't stand C/C++ and my programming projects revolve around game development, so D is a good fit here. Whenever I tried some because I am missing some feature or it's harder to do C interop. A possible alternative for me would be Rust, but I am not a fan of its syntax and design choices (I don't really care much about memory safety and I am a hardcore OOP fan). For web stuff I use Dart instead of JS, because I can't stand JS. I also wish I could use D for web stuff, but we're not there yet (I know betterC works for WebAssembly, but betterC feels too limiting for me).
Jun 03
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
It has been the case that my best _products_ happen to be done with D, so I haven't looked elsewhere. It's the language that let me think about the outcome the most, not sure if it make sense.
Jun 03
parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 3 June 2020 at 12:07:58 UTC, Guillaume Piolat wrote:
 On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
It has been the case that my best _products_ happen to be done with D, so I haven't looked elsewhere. It's the language that let me think about the outcome the most, not sure if it make sense.
Makes a lot of sense.
Jun 03
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
I'd love to use D at work for writing microservices and other backend code, but thus far I haven't been able to get my boss to agree (the main sticking point being a lack of a good OpenAPI library). The most I've used it at work is for writing scripts to parse different kinds of files. Of course all my hobby projects are in D. I agree that it's hard to use any other language once you get comfortable with it (though I've been using Groovy at work and like that language a lot). I dropped C++ years ago and never looked back.
Jun 03
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
D is the one language that I rarely feel like I am fighting it; 
there's the least barrier between brain and computer and when the 
language does get in the middle it generally actually helps 
prevent mistakes.

Using other langs I just feel like I'm wasting time fighting it 
instead of getting work done.
Jun 03
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jun 03, 2020 at 03:27:12PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
 D is the one language that I rarely feel like I am fighting it;
 there's the least barrier between brain and computer and when the
 language does get in the middle it generally actually helps prevent
 mistakes.
 
 Using other langs I just feel like I'm wasting time fighting it
 instead of getting work done.
+1. For me, D is the closest to the "ideal language" in my mind. It's not perfect, for sure, and there are dark corners that I generally avoid, but it's a lot closer than any other language I know of. And yeah, like Adam, I find that with D, I'm generally focusing my attention more on solving the problem domain rather than fighting the language. With other languages, I find that I'm constantly spending time fighting the language instead of making progress in the problem domain. With C, I'm constantly spelling out low-level operations and manually managing error codes and worrying about memory management. Maybe about 5% of the actual mental effort is spent in the problem domain, the rest is spent explaining myself in excruciating detail to a machine that simply doesn't understand what I'm trying to do. With C++ the abstraction level is somewhat better but I'm constantly fighting with obscure language semantics and the pathological syntax. Not to mention *avoiding* the hundred obvious ways to write code, which is almost always the wrong way, that will blow up in horrible ways. With Java, I find myself with my hands tied behind my back and the simplest of tasks requires declaring 5 helper classes, 3 wrapper classes, 2 interfaces, and excessively-long identifiers just to do something I could express in 3 lines of D. I find myself spending more time manipulating baroque language constructs and writing boilerplate than actually making progress in the problem domain. With scripting languages, performance is often subpar and the lack of static typing a prime source of human errors which are hard to debug, because you can never be absolutely sure what the real type of something is, or whether you're accessing it in the wrong way. I used to be a fan of Perl, but its weird and inconsistent syntax (this was Perl 5, BTW, never bothered to try Perl 6) makes it non-scalable to non-trivial projects. And besides, I find that D is generally expressive enough to fill most of my scripting needs anyway, so I find myself reaching for D instead of other scripting languages these days. For very small scripts I just use shell scripting because of convenience; but anything that requires actual computation (like manipulating lists or doing non-trivial things with strings) D is definitely the go-to solution. Plus, with D, you can easily expand what's initially a throwaway script into something much bigger without having to reengineer the whole thing from scratch. T -- A programming language should be a toolbox for the programmer to draw upon, not a minefield of dangerous explosives that you have to very carefully avoid touching in the wrong way.
Jun 03
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 3 June 2020 at 15:27:12 UTC, Adam D. Ruppe wrote:
 D is the one language that I rarely feel like I am fighting it; 
 there's the least barrier between brain and computer and when 
 the language does get in the middle it generally actually helps 
 prevent mistakes.

 Using other langs I just feel like I'm wasting time fighting it 
 instead of getting work done.
I think that's testament to this... that there's not a thing you've never done in D. It's impressive what you do with D.
Jun 03
prev sibling next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
Why do I continue to use D? Many reasons but two biggies: 1) D enables a significantly better speed/complexity ratio than my previous language choice, C++. I'm hoping that dcompute will likewise displace CUDA for future GPU projects. (not a SycL fan) 2) The D community appears to be both game and able. I look forward to pitching in once I've gained more experience.
Jun 03
prev sibling next sibling parent Superstar64 <Hexagonalstar64 gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
I'm a few years into my project and I can't be bothered to rewrite it in Haskell.
Jun 03
prev sibling next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
D is the least of the evils out there.
Jun 03
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
Luckily I can use D at work. There are a lot spots where D fits nicely due to its C interoperability and due to the fact it is a compiled language. The project I work for is actually a cloud / big data project. Yes there is always s.th. missing in D ecosystem but either I can just use a C library or in worst case I solve it by calling another executable which provides the missing features. Kind regards Andre
Jun 03
parent reply matheus <matheus gmail.com> writes:
On Wednesday, 3 June 2020 at 18:45:34 UTC, Andre Pany wrote:
 Yes there is always s.th. missing in D...
What is s.th. ? "Something"? I tried google without luck. My gosh guys please think about non-native English people while writing. Matheus.
Jun 03
parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 3 June 2020 at 18:50:08 UTC, matheus wrote:
 On Wednesday, 3 June 2020 at 18:45:34 UTC, Andre Pany wrote:
 Yes there is always s.th. missing in D...
What is s.th. ? "Something"? I tried google without luck. My gosh guys please think about non-native English people while writing. Matheus.
Non native speaker here;) I thought I learnt in secondary school That you abbreviate something with s.th. But you are right, I also do not find it in google. Grüße aus dem Schwabenland Andre
Jun 03
next sibling parent reply Meta <jared771 gmail.com> writes:
On Wednesday, 3 June 2020 at 19:34:24 UTC, Andre Pany wrote:
 On Wednesday, 3 June 2020 at 18:50:08 UTC, matheus wrote:
 On Wednesday, 3 June 2020 at 18:45:34 UTC, Andre Pany wrote:
 Yes there is always s.th. missing in D...
What is s.th. ? "Something"? I tried google without luck. My gosh guys please think about non-native English people while writing. Matheus.
Non native speaker here;) I thought I learnt in secondary school That you abbreviate something with s.th. But you are right, I also do not find it in google. Grüße aus dem Schwabenland Andre
Ironically, I've seen ESL speakers use this abbreviation far more frequently than native speakers.
Jun 03
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 3 June 2020 at 20:31:09 UTC, Meta wrote:
 [snip]

 Ironically, I've seen ESL speakers use this abbreviation far 
 more frequently than native speakers.
I've seen the abbreviation before, primarily from non-native speakers as well. Below is the first thing that came up when I googled for "s.th" https://english.stackexchange.com/questions/353395/meaning-of-s-th
Jun 03
parent Matheus. <matheus gmail.com> writes:
On Wednesday, 3 June 2020 at 20:48:30 UTC, jmh530 wrote:
 On Wednesday, 3 June 2020 at 20:31:09 UTC, Meta wrote:
 [snip]

 Ironically, I've seen ESL speakers use this abbreviation far 
 more frequently than native speakers.
I've seen the abbreviation before, primarily from non-native speakers as well. Below is the first thing that came up when I googled for "s.th" https://english.stackexchange.com/questions/353395/meaning-of-s-th
Keep in mind that google shows different results according the country you live, like Andre Pany said before. Matheus.
Jun 03
prev sibling next sibling parent Matheus. <matheus gmail.com> writes:
On Wednesday, 3 June 2020 at 19:34:24 UTC, Andre Pany wrote:
 On Wednesday, 3 June 2020 at 18:50:08 UTC, matheus wrote:
 On Wednesday, 3 June 2020 at 18:45:34 UTC, Andre Pany wrote:
 Yes there is always s.th. missing in D...
What is s.th. ? "Something"? I tried google without luck. My gosh guys please think about non-native English people while writing. Matheus.
Non native speaker here;)
Ouch! No problem and thanks for taking this amicably. :) Matheus.
Jun 03
prev sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Wednesday, 3 June 2020 at 19:34:24 UTC, Andre Pany wrote:
 On Wednesday, 3 June 2020 at 18:50:08 UTC, matheus wrote:
 On Wednesday, 3 June 2020 at 18:45:34 UTC, Andre Pany wrote:
 Yes there is always s.th. missing in D...
What is s.th. ? "Something"? I tried google without luck. My gosh guys please think about non-native English people while writing. Matheus.
Non native speaker here;) I thought I learnt in secondary school That you abbreviate something with s.th. But you are right, I also do not find it in google. Grüße aus dem Schwabenland Andre
n.th. to worry about ;-)
Jun 03
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
All programming languages are bad. D is the least bad of them all.
Jun 03
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
I use D primarily because of its performance, CTFE and over-all expressiveness in the language. I don't really care much about libraries, I'm the kind of guy to write most stuff myself. Of course I still use libraries but usually just "core" things.
Jun 03
parent reply Vinod K Chandran <kcvinu82 gmail.com> writes:
On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:

 I don't really care much about libraries, I'm the kind of guy 
 to write most stuff myself.
I like that attitude. Well, I hope you have written your own GUI library ? At least for Windows ?
Jun 04
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 4 June 2020 at 19:23:35 UTC, Vinod K Chandran wrote:
 On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:

 I don't really care much about libraries, I'm the kind of guy 
 to write most stuff myself.
I like that attitude. Well, I hope you have written your own GUI library ? At least for Windows ?
i have!
Jun 04
next sibling parent reply Vinod K Chandran <kcvinu82 gmail.com> writes:
On Thursday, 4 June 2020 at 19:29:22 UTC, Adam D. Ruppe wrote:
 i have!
Oh great ! Could you please share the link ?
Jun 05
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 5 June 2020 at 19:12:41 UTC, Vinod K Chandran wrote:
 Oh great ! Could you please share the link ?
https://code.dlang.org/packages/arsd-official%3Aminigui nothing great about it, just made for my own use.
Jun 05
parent Vinod K Chandran <kcvinu82 gmail.com> writes:
On Friday, 5 June 2020 at 21:34:52 UTC, Adam D. Ruppe wrote:
 https://code.dlang.org/packages/arsd-official%3Aminigui

 nothing great about it, just made for my own use.
Thanks for the link. Will check it sure.
Jun 06
prev sibling parent reply Liu <liiudk gmail.com> writes:
On Thursday, 4 June 2020 at 19:29:22 UTC, Adam D. Ruppe wrote:
 On Thursday, 4 June 2020 at 19:23:35 UTC, Vinod K Chandran 
 wrote:
 On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:

 I don't really care much about libraries, I'm the kind of guy 
 to write most stuff myself.
I like that attitude. Well, I hope you have written your own GUI library ? At least for Windows ?
i have!
No way! Where is it?
Jun 06
parent matheus <matheus gmail.com> writes:
On Saturday, 6 June 2020 at 18:04:27 UTC, Liu wrote:
 On Thursday, 4 June 2020 at 19:29:22 UTC, Adam D. Ruppe wrote:
 On Thursday, 4 June 2020 at 19:23:35 UTC, Vinod K Chandran 
 wrote:
 On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:

 I don't really care much about libraries, I'm the kind of 
 guy to write most stuff myself.
I like that attitude. Well, I hope you have written your own GUI library ? At least for Windows ?
i have!
No way! Where is it?
Re responded: https://forum.dlang.org/post/mnfewrzjklmhkkzylosu forum.dlang.org Matheus.
Jun 06
prev sibling next sibling parent reply mw <mingwu gmail.com> writes:
On Thursday, 4 June 2020 at 19:23:35 UTC, Vinod K Chandran wrote:
 On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:
 I don't really care much about libraries, I'm the kind of guy 
 to write most stuff myself.
I like that attitude. Well, I hope you have written your own GUI library ? At least for Windows ?
I like to "stand on the shoulders of giants": so I choose to use high-quality libraries as much as I can find, then I can concentrate my energy on my own problem domain.
Jun 04
next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2020-06-04 at 19:31 +0000, mw via Digitalmars-d wrote:
 On Thursday, 4 June 2020 at 19:23:35 UTC, Vinod K Chandran wrote:
 On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:
 I don't really care much about libraries, I'm the kind of guy=20
 to write most stuff myself.
=20
I like that attitude. Well, I hope you have written your own=20 GUI library ? At least for Windows ?
=20 I like to "stand on the shoulders of giants": so I choose to use=20 high-quality libraries as much as I can find, then I can=20 concentrate my energy on my own problem domain.
I just had a situation in Rust where I found a crate that a lot of people u= se and is maintained, added two derive annotations to various bits of my code, deleted half the code in a large module of my code and increased the functionality and capability of my code. I like good libraries. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jun 05
prev sibling parent Vinod K Chandran <kcvinu82 gmail.com> writes:
On Thursday, 4 June 2020 at 19:31:13 UTC, mw wrote:
 I like to "stand on the shoulders of giants": so I choose to 
 use high-quality libraries as much as I can find, then I can 
 concentrate my energy on my own problem domain.
That's a good point, but sometimes its fun to write our own libs if you have time.
Jun 05
prev sibling parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 4 June 2020 at 19:23:35 UTC, Vinod K Chandran wrote:
 On Thursday, 4 June 2020 at 04:54:53 UTC, bauss wrote:

 I don't really care much about libraries, I'm the kind of guy 
 to write most stuff myself.
I like that attitude. Well, I hope you have written your own GUI library ? At least for Windows ?
At one point I was working on one but killed the project years ago. I do a lot more network / website stuff than GUI stuff so that's my primary area of D. It is something I wanna work on again in the future, so maybe one day but there are a couple GUI libraries atm. that are decent already.
Jun 05
parent Vinod K Chandran <kcvinu82 gmail.com> writes:
On Friday, 5 June 2020 at 17:36:32 UTC, bauss wrote:
 At one point I was working on one but killed the project years 
 ago. I do a lot more network / website stuff than GUI stuff so 
 that's my primary area of D.

 It is something I wanna work on again in the future, so maybe 
 one day but there are a couple GUI libraries atm. that are 
 decent already.
Thanks for the reply. :)
Jun 05
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Wed, Jun 3, 2020 at 9:15 PM aberba via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 I personally can't use any other system programming language due
 to the expressiveness and familiarity of D. Its familiar and some
 syntactic expressiveness are just hard to get in other systems
 languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and
 cloud support...web services), but D is my go-to system language.
 Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and
 support. Yeah, it's not perfect but way better than anywhere else
 I've been.

 What are you?
To be honest... because I'm too far in. I suffer from extreme sunk-cost syndrome. I wrestle with the reality on a daily basis that D may have materially damaged my career. To be clear, I quite like D, although there's a bunch of weird and slightly broken shit which gets in the way much more often than what's acceptable. But relative to C/C++ (my professional career aseline (gamedev)), D is comparatively so luxurious that I have developed such an extreme distaste for C/C++ bullshit that I actually hate doing my real actual job in a lot of practical ways. I hate being paid good money to write terrible code, and then having my peers and supervisors think that it's fine when it's actually terrible!! The inevitable complexity creep predictably becomes unsustainable, and then everyone's surprised as if nobody saw it coming 10 miles off, then we start spending unreasonable amounts of lifetime trying to recover... and for some reason, the business just keeps pouring money into it! It's bizarre and insane that gamedev is populated by zealots that would rather piss away insane amounts of money than to ask the question if there's any better way out there. So, my professional work is intolerable, but I can't use D professionally... despite over a decade of effort to try and move in that direction, and so many parts of the puzzle slowly falling into place. Why aren't we there yet? There's always just a couple more things! And a number of battles I fought for years and didn't win which are major issues that haven't just gone away. Why don't we fix them? Mostly political bullshit... mostly because I need to convince Walter & Andrei what's important without always being able to present concrete cases. The amount of time to make tiny maneuvers is crazy, and opportunities in my workplace just keep passing us by... D seems to be a hobby for most users, and few people actually really care for it to be a commercial success, or they'd listen to those of us who want to use it industrially for those things that are really important. Do I keep hammering away? My tank's empty, but I don't know how or when to admit to myself that I need to stop pushing... accept that I'm a C/C++ programmer... but then I just hate programming. What am I supposed to do? I'm lost in a dark place :(
Jun 04
next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 4 June 2020 at 11:59:33 UTC, Manu wrote:
 On Wed, Jun 3, 2020 at 9:15 PM aberba via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 To be honest... because I'm too far in. I suffer from extreme 
 sunk-cost syndrome.

 [...]
That's a real case right there. I'm optimistic we'll get things together. I like the idea about freezing things,for the most part, and fixing what we already have. The real issues everyday devs find troubling.
Jun 04
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 4 June 2020 at 11:59:33 UTC, Manu wrote:
 Do I keep hammering away? My tank's empty, but I don't know how 
 or when to admit to myself that I need to stop pushing... 
 accept that I'm a C/C++ programmer... but then I just hate 
 programming. What am I supposed to do? I'm lost in a dark place 
 :(
Was a D programmer stuck in C++ setting (oh, the pain). I can guarantee a small internal tool takes twice the time to build in C++ vs D. Since going indie C++ is now the competition. I know it's bad, but it's a pretty good feeling when competitors talk about their 6-hours-long builds, or try to explain concepts to each other.
Jun 04
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 4 June 2020 at 13:02:06 UTC, Guillaume Piolat wrote:
 On Thursday, 4 June 2020 at 11:59:33 UTC, Manu wrote:
 Do I keep hammering away? My tank's empty, but I don't know 
 how or when to admit to myself that I need to stop pushing... 
 accept that I'm a C/C++ programmer... but then I just hate 
 programming. What am I supposed to do? I'm lost in a dark 
 place :(
Was a D programmer stuck in C++ setting (oh, the pain). I can guarantee a small internal tool takes twice the time to build in C++ vs D. Since going indie C++ is now the competition. I know it's bad, but it's a pretty good feeling when competitors talk about their 6-hours-long builds, or try to explain concepts to each other.
cough cough some people have 5 hours builds in D. They build the world though.
Jun 04
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 4 June 2020 at 11:59:33 UTC, Manu wrote:
 It's bizarre and insane that gamedev is populated by zealots 
 that would
 rather piss away insane amounts of money than to ask the 
 question if
 there's any better way out there.
Hellblade: Senua's Sacrifice shows how inefficient some game studios are at making playable content. For 30€ there is a lot of game in it. Compared that to other projects where 2 mil copies sold at 60€ is below expectation and not financially sustainable.
 Why don't we fix them? Mostly political bullshit... mostly 
 because I need
 to convince Walter & Andrei what's important without always 
 being able to
 present concrete cases.
I have seen your proposals and they look like you want to fix your problem quickly and with least amount of work. This is good approach for game development but bad for language changes. If you make a mistake in game no big deal. But if you make a mistake in language design you might have to pay for that mistake for over a decade. Should I say string auto decoding...
Jun 04
next sibling parent Avrina <avrina12309412342 gmail.com> writes:
On Thursday, 4 June 2020 at 18:05:49 UTC, welkam wrote:
 On Thursday, 4 June 2020 at 11:59:33 UTC, Manu wrote:
 It's bizarre and insane that gamedev is populated by zealots 
 that would
 rather piss away insane amounts of money than to ask the 
 question if
 there's any better way out there.
Hellblade: Senua's Sacrifice shows how inefficient some game studios are at making playable content. For 30€ there is a lot of game in it. Compared that to other projects where 2 mil copies sold at 60€ is below expectation and not financially sustainable.
There's lots of indie games, and some solo developed games that illustrate this. AAA games focus on the wrong things and don't take risks because they are so expensive. It's why some games have endless sequels, making something new is a risk. Don't get me wrong, having a nice realistic looking game is pretty. But as long as it has some sort of art style, you don't have to pour millions into making it look that realistic.
 Why don't we fix them? Mostly political bullshit... mostly 
 because I need
 to convince Walter & Andrei what's important without always 
 being able to
 present concrete cases.
I have seen your proposals and they look like you want to fix your problem quickly and with least amount of work. This is good approach for game development but bad for language changes. If you make a mistake in game no big deal. But if you make a mistake in language design you might have to pay for that mistake for over a decade. Should I say string auto decoding...
No one knows what will be good or not. Look at DIP1028, almost everyone thought it was a terrible idea but it almost went on through anyways. It took a s-storm to have it be undone. A lot of the work Manu has done has been on the practical side, you can reason about it with rationality. And it being used in practice, as he actually codes and isn't as worried about ideology. I think you aren't giving Manu the acknowledgement he deserves. What he has pushed for and got into the language has been a net gain for me.
Jun 04
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jun 5, 2020 at 4:10 AM welkam via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Thursday, 4 June 2020 at 11:59:33 UTC, Manu wrote:
 It's bizarre and insane that gamedev is populated by zealots
 that would
 rather piss away insane amounts of money than to ask the
 question if
 there's any better way out there.
Hellblade: Senua's Sacrifice shows how inefficient some game studios are at making playable content. For 30=E2=82=AC there is a lot of game in it. Compared that to other projects where 2 mil copies sold at 60=E2=82=AC is below expectation and not financially sustainable.
 Why don't we fix them? Mostly political bullshit... mostly
 because I need
 to convince Walter & Andrei what's important without always
 being able to
 present concrete cases.
I have seen your proposals and they look like you want to fix your problem quickly and with least amount of work. This is good approach for game development but bad for language changes. If you make a mistake in game no big deal. But if you make a mistake in language design you might have to pay for that mistake for over a decade. Should I say string auto decoding...
'Quickly'? 'Least amount of work'? Pfft... like what? I've been hammering away for almost 12 years. I've carried lots of missions that spanned many years. I was banging on about `scope` (which we finally have) for the entire duration of dconf 2013, and ceaselessly after that. I'm not aware of anything I've motivated being a failure or having done damage to D. D is riddled with small mistakes. Most of my effort has been related to fixing them, with varying levels of success. I certainly have no part in string auto-decoding! I've spent the last 2 years trying to talk about `shared`, while **spectacularly huge** opportunities just sail on by. We've made very small incremental (and broken) progress. The important stuff has been blocked, and no counter-proposals ever presented. Blizzard is one of the biggest and most important gamedev houses in the world; imagine if there were some D code at the heart of all future Blizzard games. What could that bring to D in terms of interest, resources, manpower, etc. We're a $50 billion company= . My current project would benefit *enormously* from D and various key colleagues are interested to learn more, but a couple of the key benefits just have broken implementations (ie, shared), which I can't possibly demonstrate to my colleagues without a fix... a broken demonstration is a demonstration of why NOT to use D rather than why we should. `pragma(inline)` is another one that I just need to work right for our project but it's broken in an insane way. It's comical, because Walter added that in ~2011 specifically because I showed that we needed it, but then the implementation doesn't actually work right (from the day it was merged), and I haven't been able to use it. It exists because I needed it, but it never satisfied the one customer that asked for it... and that's a weirdly common pattern in dlang dev. It's like, one little thing can ruin the entire case when it's a critical thing. I can say it's important... but then it's really hard to gather consensus that it's important. `shared` is broken, I've done what work I can do alone, but if it's rejected, other people need to step in and make a counter proposal, or if nobody wants to after 2 years missed opportunity, then just get out of the way and let me get on with it. I know what we need to do with shared. So, I'll refer back to that thing I said above that you responded to; I don't know how to convince key folks that shared is really important any more than I am able to say "shared is really important, and this opportunity depends on it"...? Back on-topic; I still use D because I just can't stand C++, and I somehow fundamentally believe D can 'get there'... but god is it a hard and frustrating road! Eternally so close, but always juuuust misses the mark. Maybe one day we'll land the shot >_<
Jun 04
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2020 7:44 PM, Manu wrote:
 ...
Regarding shared, void test(shared(int)* p) { *p = 1; } dmd -preview=nosharedaccess test test.d(31): Error: direct access to shared *p is not allowed, see core.atomic Isn't that what you wanted?
Jun 05
next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Friday, 5 June 2020 at 10:15:25 UTC, Walter Bright wrote:
 On 6/4/2020 7:44 PM, Manu wrote:
 ...
Regarding shared, void test(shared(int)* p) { *p = 1; } dmd -preview=nosharedaccess test test.d(31): Error: direct access to shared *p is not allowed, see core.atomic Isn't that what you wanted?
There are quite a few bugs with the `-preview=nosharedaccess` switch, and before you ask, yes it's in bugzilla: https://issues.dlang.org/show_bug.cgi?id=20195 Regarding inline, here's what I believe Manu is complaining about: https://issues.dlang.org/show_bug.cgi?id=19570 I will add that rvalue references are also completely broken, but I'm not sure how relevant it is to Manu (it's certainly relevant for C++ interop, though): - https://issues.dlang.org/show_bug.cgi?id=20706 - https://issues.dlang.org/show_bug.cgi?id=20705 - https://issues.dlang.org/show_bug.cgi?id=20704
Jun 05
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2020 3:28 AM, Mathias LANG wrote:
 here's what I believe Manu is complaining about: 
I wish Manu would include a list of bugzilla issues every time he complains about problems, so we won't have to guess.
Jun 05
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jun 5, 2020 at 3:20 AM Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On 6/4/2020 7:44 PM, Manu wrote:
 ...
Regarding shared, void test(shared(int)* p) { *p = 1; } dmd -preview=nosharedaccess test test.d(31): Error: direct access to shared *p is not allowed, see core.atomic Isn't that what you wanted?
That's the very very very start of the journey. That change alone only opens the door; but there's open issues relating to initialisation from that change, there's important opportunities with `shared` in conjunction with `scope` (which is what I was arguing for when I was making the case for `scope` as it is today way back in dconf2013, if you can recall those long arguments), and we had a big discussion about how to implement parallel-for (and associated machinery) which you rejected because you found it unacceptable that a library may have to insert fences at the appropriate places rather than the compiler doing it automatically (redundantly) everywhere the pattern emerged. Timon said he thought he knew how to work the proposal into a form you'd find agreeable, but he hasn't replied to me on that recently. This was all discussed at length over many months. It kinda just stalled when I fatigued. If we're ready to pick up the ball, that would be really valuable work.
Jun 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2020 5:08 PM, Manu wrote:
 but there's open issues relating to initialisation from that change,
I know about that one, but it doesn't seem a showstopper.
 there's important opportunities with `shared` in conjunction with `scope`
(which 
 is what I was arguing for when I was making the case for `scope` as it is
today 
 way back in dconf2013, if you can recall those long arguments),
Yes.
 and we had a big 
 discussion about how to implement parallel-for (and associated machinery)
which 
 you rejected because you found it unacceptable that a library may have to
insert 
 fences at the appropriate places rather than the compiler doing it
automatically 
 (redundantly) everywhere the pattern emerged.
I don't recall that one.
 Timon said he thought he knew how 
 to work the proposal into a form you'd find agreeable, but he hasn't replied
to 
 me on that recently.
 This was all discussed at length over many months. It kinda just stalled when
I 
 fatigued. If we're ready to pick up the ball, that would be really valuable
work.
I'm not ready today, but it'd be nice if you made a text file of the status of all your initiatives with links to the discussions, so you won't have to keep retyping them.
Jun 05
parent reply Manu <turkeyman gmail.com> writes:
On Sat, Jun 6, 2020 at 3:05 PM Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On 6/5/2020 5:08 PM, Manu wrote:
 but there's open issues relating to initialisation from that change,
I know about that one, but it doesn't seem a showstopper.
Initialisation and `ref` emit errors? They're absolutely show stoppers. Values must be initialised, and code has `ref` in it all the time. You can't write code without those things.
 there's important opportunities with `shared` in conjunction with `scope`
 (which
 is what I was arguing for when I was making the case for `scope` as it
is today
 way back in dconf2013, if you can recall those long arguments),
Yes.
 and we had a big
 discussion about how to implement parallel-for (and associated
machinery) which
 you rejected because you found it unacceptable that a library may have
to insert
 fences at the appropriate places rather than the compiler doing it
automatically
 (redundantly) everywhere the pattern emerged.
I don't recall that one.
There are uber-threads on it. But if you feel like you have time to think about this problem space we can open it up again.
 Timon said he thought he knew how
 to work the proposal into a form you'd find agreeable, but he hasn't
replied to
 me on that recently.
 This was all discussed at length over many months. It kinda just stalled
when I
 fatigued. If we're ready to pick up the ball, that would be really
valuable work. I'm not ready today, but it'd be nice if you made a text file of the status of all your initiatives with links to the discussions, so you won't have to keep retyping them.
Okay, I'll try and find some time to dig them up. I have almost no time recently; work-from-home is hard and I work 12-14 hours a day to try and make up for lost productivity, and still falling behind. ... and, tragically, the reason for that is mostly because we wrote this thing in C++! I've been having a really un-fun time at work because I failed to make a pitch for D in the ~18 months window we had, and now I have to suffer that failure :(
Jun 05
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2020 10:16 PM, Manu wrote:
 Initialisation and `ref` emit errors?
 They're absolutely show stoppers. Values must be initialised, and code has
`ref` 
 in it all the time.
 You can't write code without those things.
You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper. You can use pointers instead of ref, inconvenient, not a showstopper.
 Okay, I'll try and find some time to dig them up.
 I have almost no time recently; work-from-home is hard and I work 12-14 hours
a 
 day to try and make up for lost productivity, and still falling behind.
 ... and, tragically, the reason for that is mostly because we wrote this thing 
 in C++! I've been having a really un-fun time at work because I failed to make
a 
 pitch for D in the ~18 months window we had, and now I have to suffer that 
 failure :(
I understand.
Jun 06
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 6 June 2020 at 07:00:57 UTC, Walter Bright wrote:
 On 6/5/2020 10:16 PM, Manu wrote:
 Initialisation and `ref` emit errors?
 They're absolutely show stoppers. Values must be initialised, 
 and code has `ref` in it all the time.
 You can't write code without those things.
You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper. You can use pointers instead of ref, inconvenient, not a showstopper.
The whole point of a programming language feature is to be more convenient. If a feature is any more inconvenient than it needs to be people will be a averse to using it. (For some reason the boost people don't fall into that ...) For shared to be convenient the shared checks have to be disabled based on context. For example during initialization or when taking a ref.
Jun 06
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/20 3:00 AM, Walter Bright wrote:
 On 6/5/2020 10:16 PM, Manu wrote:
 Initialisation and `ref` emit errors?
 They're absolutely show stoppers. Values must be initialised, and code 
 has `ref` in it all the time.
 You can't write code without those things.
You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper. You can use pointers instead of ref, inconvenient, not a showstopper.
It depends on if you think the show is one you want to watch. Saying "it was ugly, but we still put on the show even though nobody paid to see it" isn't success. I think the shared changes are welcome and a huge improvement. But they need to be correct before anyone will adopt them over even existing D codebase, much less migrating from a different language. -Steve
Jun 06
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/6/2020 10:00 AM, Steven Schveighoffer wrote:
 It depends on if you think the show is one you want to watch. Saying "it was 
 ugly, but we still put on the show even though nobody paid to see it" isn't 
 success.
Every language has its uglies. It's not the same thing as a showstopper.
Jun 06
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/20 4:55 PM, Walter Bright wrote:
 On 6/6/2020 10:00 AM, Steven Schveighoffer wrote:
 It depends on if you think the show is one you want to watch. Saying 
 "it was ugly, but we still put on the show even though nobody paid to 
 see it" isn't success.
Every language has its uglies. It's not the same thing as a showstopper.
Not all showstoppers are objective lines. On one side is pain you are willing to go through to make the horrible system you are using do what you want it to do (see for instance, web applications). On the other side is too much pain to even consider it. And there are factors. If D was the only game in town for the target audience, it's very likely they would do as Manu is doing with C++, and suffer through the horror. But if another option is available, that has different horrors, then you make a decision based on which horror scares you the least. To continue the "show" analogy, consider a theater show where all the show light bulbs burn out simultaneously. You could say "Well, they can do it by flashlight," and yes, it could happen. People wouldn't be able to see it, but the show would *happen*. So one could argue that not having significant lighting is not a showstopper in the way you are saying "just use void initialization". -Steve
Jun 06
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 6 June 2020 at 21:14:44 UTC, Steven Schveighoffer 
wrote:
 To continue the "show" analogy, consider a theater show where 
 all the show light bulbs burn out simultaneously. You could say 
 "Well, they can do it by flashlight," and yes, it could happen. 
 People wouldn't be able to see it, but the show would *happen*. 
 So one could argue that not having significant lighting is not 
 a showstopper in the way you are saying "just use void 
 initialization".
There are theatre works that are designed to be performed in total or near-total darkness :-)
Jun 06
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/6/2020 2:14 PM, Steven Schveighoffer wrote:
 To continue the "show" analogy, consider a theater show where all the show
light 
 bulbs burn out simultaneously. You could say "Well, they can do it by 
 flashlight," and yes, it could happen. People wouldn't be able to see it, but 
 the show would *happen*. So one could argue that not having significant
lighting 
 is not a showstopper in the way you are saying "just use void initialization".
On the other hand, how many shared local variables does one have in a program? Every shared variable is a risk of threading problems, and one should try to minimize their use.
Jun 06
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/20 5:56 PM, Walter Bright wrote:
 On 6/6/2020 2:14 PM, Steven Schveighoffer wrote:
 To continue the "show" analogy, consider a theater show where all the 
 show light bulbs burn out simultaneously. You could say "Well, they 
 can do it by flashlight," and yes, it could happen. People wouldn't be 
 able to see it, but the show would *happen*. So one could argue that 
 not having significant lighting is not a showstopper in the way you 
 are saying "just use void initialization".
On the other hand, how many shared local variables does one have in a program?
I thought the intialization problem was in constructors for shareable items, not for local variables? In any case, this is bending an implementation deficiency into a "feature" of dissuasion. If something shouldn't be done, there are better ways to prevent it than requiring void initialization (which in itself is a dangerous thing to require).
 Every shared variable is a risk of threading problems, and one should 
 try to minimize their use.
This is why the changes are great -- you have to write code that removes the shared qualifier to deal with actually using the data, under the guidance of the library which knows the semantic meaning of the data. Wrapping this into a useful type is what the purpose is. But constructors generally have free reign to provide an initial value even for immutable data. I don't see why it should be different for shared (the point is that it's being constructed, so nothing has access to that item yet). Maybe I'm misunderstanding the issues. If there's a way to make it so only a small amount of code has to use void initialization, and user code never has to do that, it might be workable (but I don't speak for Manu). But certainly that is still considered a bug, and not an intended feature, right? -Steve
Jun 06
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/6/2020 3:12 PM, Steven Schveighoffer wrote:
 I thought the intialization problem was in constructors for shareable items,
not 
 for local variables? In any case, this is bending an implementation deficiency 
 into a "feature" of dissuasion.
I said it was ugly, not a feature.
 But certainly that 
 is still considered a bug, and not an intended feature, right?
I posted a PR to fix it. But it's still not a showstopper.
Jun 06
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/6/20 9:37 PM, Walter Bright wrote:
 On 6/6/2020 3:12 PM, Steven Schveighoffer wrote:
 I thought the intialization problem was in constructors for shareable 
 items, not for local variables? In any case, this is bending an 
 implementation deficiency into a "feature" of dissuasion.
I said it was ugly, not a feature.
Good. Sometimes statements like "well you shouldn't be doing that anyway" can make things unclear what the expectation is.
 
 But certainly that is still considered a bug, and not an intended 
 feature, right?
I posted a PR to fix it. But it's still not a showstopper.
Thanks. -Steve
Jun 07
next sibling parent reply Greatsam4sure <greatsam4sure yahoo.com> writes:
On Sunday, 7 June 2020 at 14:18:50 UTC, Steven Schveighoffer 
wrote:
 On 6/6/20 9:37 PM, Walter Bright wrote:
 On 6/6/2020 3:12 PM, Steven Schveighoffer wrote:
 I thought the intialization problem was in constructors for 
 shareable items, not for local variables? In any case, this 
 is bending an implementation deficiency into a "feature" of 
 dissuasion.
I said it was ugly, not a feature.
Good. Sometimes statements like "well you shouldn't be doing that anyway" can make things unclear what the expectation is.
 
 But certainly that is still considered a bug, and not an 
 intended feature, right?
I posted a PR to fix it. But it's still not a showstopper.
Thanks. -Steve
This thread has a specific purpose. The purpose is those people using D in production or their project, why are they using it. So that others can find confidence and use it too. It is not a thread to argue about D problems. Let keep the focus of the thread. This one of the most beautiful thread I have enjoyed since my two years plus of being this forum. Move all other discussions to another thread pls..... This thread if properly utilize or manage will be a great encouragement to a newbie in D tomorrow. I am really encouraged by D. So we are waiting for more testimonies from happy users
Jun 07
parent aberba <karabutaworld gmail.com> writes:
On Sunday, 7 June 2020 at 16:09:08 UTC, Greatsam4sure wrote:
 On Sunday, 7 June 2020 at 14:18:50 UTC, Steven Schveighoffer 
 wrote:
 [...]
This thread has a specific purpose. The purpose is those people using D in production or their project, why are they using it. So that others can find confidence and use it too. It is not a thread to argue about D problems. Let keep the focus of the thread. This one of the most beautiful thread I have enjoyed since my two years plus of being this forum. Move all other discussions to another thread pls.....
Thank you! 🙏
 This thread if properly utilize or manage will be a great 
 encouragement to a newbie in D tomorrow. I am really encouraged 
 by D.
I really want to do something about promoting more of this.
 So we are waiting for more testimonies from happy users
Yes. Please share more testimonies.
Jun 07
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/7/2020 7:18 AM, Steven Schveighoffer wrote:
 Good. Sometimes statements like "well you shouldn't be doing that anyway" can 
 make things unclear what the expectation is.
I still think that having lots of shared variables is not a good sign, like having lots of globals is not a good sign.
Jun 08
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Monday, 8 June 2020 at 09:09:52 UTC, Walter Bright wrote:
 On 6/7/2020 7:18 AM, Steven Schveighoffer wrote:
 Good. Sometimes statements like "well you shouldn't be doing 
 that anyway" can make things unclear what the expectation is.
I still think that having lots of shared variables is not a good sign, like having lots of globals is not a good sign.
I think for Manu shared means: "We don't know who owns this. This has to go through the scheduler". I'd expect almost everything to have to go through the scheduler. Because core counts are rising! I have 32 cores with 2 hyper-threads per core. Giving me 64 logical cores. There's no way I can just dedicate certain threads to certain tasks. It's unmanageable.
Jun 08
prev sibling parent Manu <turkeyman gmail.com> writes:
On Sun, Jun 7, 2020 at 8:00 AM Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On 6/6/2020 2:14 PM, Steven Schveighoffer wrote:
 To continue the "show" analogy, consider a theater show where all the
show light
 bulbs burn out simultaneously. You could say "Well, they can do it by
 flashlight," and yes, it could happen. People wouldn't be able to see
it, but
 the show would *happen*. So one could argue that not having significant
lighting
 is not a showstopper in the way you are saying "just use void
initialization". On the other hand, how many shared local variables does one have in a program? Every shared variable is a risk of threading problems, and one should try to minimize their use.
Not how our ecosystem works... practically everything is shared. The whole gig is about declaring access control, and mechanisms which schedule appropriately synchronised access to shared things. Without type-safety, mistakes are way too easy to make. Shared is a really big deal for D that it's never truly capitalised on.
Jun 08
prev sibling parent Kagamin <spam here.lot> writes:
On Saturday, 6 June 2020 at 21:14:44 UTC, Steven Schveighoffer 
wrote:
 To continue the "show" analogy, consider a theater show where 
 all the show light bulbs burn out simultaneously. You could say 
 "Well, they can do it by flashlight," and yes, it could happen. 
 People wouldn't be able to see it, but the show would *happen*. 
 So one could argue that not having significant lighting is not 
 a showstopper in the way you are saying "just use void 
 initialization".
Ugliness is intended, though. Even if you know what you are doing, even if nothing can go wrong, you still must write ugly code to do basic things - this is exactly what Manu proposes. And it's predictably frustraiting too, guess it's about time you understand the obvious.
Jun 12
prev sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Saturday, 6 June 2020 at 07:00:57 UTC, Walter Bright wrote:
 On 6/5/2020 10:16 PM, Manu wrote:
 Initialisation and `ref` emit errors?
 They're absolutely show stoppers. Values must be initialised, 
 and code has `ref` in it all the time.
 You can't write code without those things.
You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper. You can use pointers instead of ref, inconvenient, not a showstopper.
Do you really believe this, or are you just making up an excuse? Putting safe on declarations is inconvenient, but NOT a showstopper. How much multi-threading work do you do on a daily basis? I think it would be best to leave what is and isn't a "showstopper" to the experts that do the work on a daily basis.
Jun 07
parent Avrina <avrina12309412342 gmail.com> writes:
On Sunday, 7 June 2020 at 18:12:57 UTC, Avrina wrote:
 On Saturday, 6 June 2020 at 07:00:57 UTC, Walter Bright wrote:
 On 6/5/2020 10:16 PM, Manu wrote:
 Initialisation and `ref` emit errors?
 They're absolutely show stoppers. Values must be initialised, 
 and code has `ref` in it all the time.
 You can't write code without those things.
You can declare them with =void; and set them with the atomics. That's inconvenient, but NOT a showstopper. You can use pointers instead of ref, inconvenient, not a showstopper.
Do you really believe this, or are you just making up an excuse? Putting safe on declarations is inconvenient, but NOT a showstopper. How much multi-threading work do you do on a daily basis? I think it would be best to leave what is and isn't a "showstopper" to the experts that do the work on a daily basis.
#DIP1028
Jun 07
prev sibling next sibling parent reply matheus <matheus gmail.com> writes:
On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 ... and, tragically, the reason for that is mostly because we 
 wrote this
 thing in C++! I've been having a really un-fun time at work 
 because I
 failed to make a pitch for D in the ~18 months window we had, 
 and now I
 have to suffer that failure :(
I'm really curious, if you had those features (Shared for example) the way you liked... you could pitched the company (Blizzard) to develop games for videogames in D? What about the GC? Wouldn't that be a bottleneck or it would be without GC? Matheus.
Jun 06
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via Digitalmars-d wrote:
 On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 ... and, tragically, the reason for that is mostly because we wrote
 this thing in C++! I've been having a really un-fun time at work
 because I failed to make a pitch for D in the ~18 months window we
 had, and now I have to suffer that failure :(
I'm really curious, if you had those features (Shared for example) the way you liked... you could pitched the company (Blizzard) to develop games for videogames in D? What about the GC? Wouldn't that be a bottleneck or it would be without GC?
Wasn't Manu one of the people who pushed for nogc and eventually got it in? T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Jun 06
parent matheus <matheus gmail.com> writes:
On Saturday, 6 June 2020 at 13:20:53 UTC, H. S. Teoh wrote:
 On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via 
 Digitalmars-d wrote:
 On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 ... and, tragically, the reason for that is mostly because 
 we wrote this thing in C++! I've been having a really un-fun 
 time at work because I failed to make a pitch for D in the 
 ~18 months window we had, and now I have to suffer that 
 failure :(
I'm really curious, if you had those features (Shared for example) the way you liked... you could pitched the company (Blizzard) to develop games for videogames in D? What about the GC? Wouldn't that be a bottleneck or it would be without GC?
Wasn't Manu one of the people who pushed for nogc and eventually got it in?
I dunno. Matheus.
Jun 06
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via Digitalmars-d wrote:
 On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 ... and, tragically, the reason for that is mostly because we wrote
 this thing in C++! I've been having a really un-fun time at work
 because I failed to make a pitch for D in the ~18 months window we
 had, and now I have to suffer that failure :(
I'm really curious, if you had those features (Shared for example) the way you liked... you could pitched the company (Blizzard) to develop games for videogames in D? What about the GC? Wouldn't that be a bottleneck or it would be without GC?
Wasn't Manu one of the people who pushed for nogc and eventually got it in?
Yes, nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;) Outside the realtime code though, GC can be useful. It's not bad the language has GC, but it would be nice if nogc existed much earlier so there was a better culture of writing libraries to support it. Most libraries I've written recently work with or without GC.
Jun 07
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via 
 Digitalmars-d wrote:
 On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 [...]
I'm really curious, if you had those features (Shared for example) the way you liked... you could pitched the company (Blizzard) to develop games for videogames in D? What about the GC? Wouldn't that be a bottleneck or it would be without GC?
Wasn't Manu one of the people who pushed for nogc and eventually got it in?
Yes, nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;)
Sounds like...I got nogc into D but meh, don't wan it anymore.
Jun 08
parent Manu <turkeyman gmail.com> writes:
On Mon, Jun 8, 2020 at 6:35 PM aberba via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via
 Digitalmars-d wrote:
 On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 [...]
I'm really curious, if you had those features (Shared for example) the way you liked... you could pitched the company (Blizzard) to develop games for videogames in D? What about the GC? Wouldn't that be a bottleneck or it would be without GC?
Wasn't Manu one of the people who pushed for nogc and eventually got it in?
Yes, nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;)
Sounds like...I got nogc into D but meh, don't wan it anymore.
Ummm, no... that's not even remotely what I said.
Jun 08
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via 
 Digitalmars-d wrote:
 [...]
Wasn't Manu one of the people who pushed for nogc and eventually got it in?
Yes, nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;) Outside the realtime code though, GC can be useful. It's not bad the language has GC, but it would be nice if nogc existed much earlier so there was a better culture of writing libraries to support it. Most libraries I've written recently work with or without GC.
To bad that nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor. -Alex
Jun 08
parent reply Manu <turkeyman gmail.com> writes:
On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 On Sat, Jun 6, 2020 at 11:21 PM H. S. Teoh via Digitalmars-d <
 digitalmars-d puremagic.com> wrote:

 On Sat, Jun 06, 2020 at 01:11:46PM +0000, matheus via
 Digitalmars-d wrote:
 [...]
Wasn't Manu one of the people who pushed for nogc and eventually got it in?
Yes, nogc is totally my meddling, and it's a very valuable tool! If only we could get a robust ARC solution over the line... ;) Outside the realtime code though, GC can be useful. It's not bad the language has GC, but it would be nice if nogc existed much earlier so there was a better culture of writing libraries to support it. Most libraries I've written recently work with or without GC.
To bad that nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor. -Alex
What do you mean?
Jun 08
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 9 June 2020 at 00:55:44 UTC, Manu wrote:
 On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 [...]
To bad that nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor. -Alex
What do you mean?
You can't call the destroy function for classes in a nogc context. The de-constructor is not virtual, because of this, it doesn't inherent the attributes. -Alex
Jun 09
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/9/20 9:54 AM, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 00:55:44 UTC, Manu wrote:
 On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d < 
 digitalmars-d puremagic.com> wrote:

 On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 [...]
To bad that nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.
 What do you mean?
You can't call the destroy function for classes in a nogc context. The de-constructor is not virtual, because of this, it doesn't inherent the attributes.
That's true of classes with most attributes in general. For example, you can't compare objects for equality in safe code. This was the point for the ProtoObject idea. -Steve
Jun 09
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 9 June 2020 at 14:08:24 UTC, Steven Schveighoffer 
wrote:
 On 6/9/20 9:54 AM, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 00:55:44 UTC, Manu wrote:
 On Tue, Jun 9, 2020 at 4:15 AM 12345swordy via Digitalmars-d 
 < digitalmars-d puremagic.com> wrote:

 On Monday, 8 June 2020 at 06:51:59 UTC, Manu wrote:
 [...]
To bad that nogc is useless when it comes to manual memory management when it comes to classes as it doesn't work well at all with the class deconstructor.
 What do you mean?
You can't call the destroy function for classes in a nogc context. The de-constructor is not virtual, because of this, it doesn't inherent the attributes.
That's true of classes with most attributes in general. For example, you can't compare objects for equality in safe code. This was the point for the ProtoObject idea. -Steve
An idea that show no progress for what? Two years? I am losing my patience with this already. I can't consider d to be a serious language if this bug won't be fix in some reasonable time frame in the future. -Alex
Jun 09
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09.06.20 17:11, 12345swordy wrote:
 ...
 
 An idea that show no progress for what? Two years? I am losing my 
 patience with this already. I can't consider d to be a serious language 
 if this bug won't be fix in some reasonable time frame in the future.
 
 -Alex
I am not sure what you hope to accomplish with this rhetoric. There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/... I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.
Jun 09
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
 On 09.06.20 17:11, 12345swordy wrote:
 ...
 
 An idea that show no progress for what? Two years? I am losing 
 my patience with this already. I can't consider d to be a 
 serious language if this bug won't be fix in some reasonable 
 time frame in the future.
 
 -Alex
I am not sure what you hope to accomplish with this rhetoric. There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/... I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.
This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years! It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone. https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.dispose?view=netcore-3.1
Jun 09
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Tuesday, 9 June 2020 at 15:45:29 UTC, 12345swordy wrote:

 It can be fix by having the druntime providing a interface say 
 "Dispose" and just have the destroy function call that and 
 leave the old deconstructors alone.
There's no need for a new interface. What needs to happen is resolution of [1] and amendment to destroy() so it avoids rt_finalize and infers correct attributes. Which, even three years later, I maintain should be resolved by disallowing classes to loosen destructor attributes. [1] https://issues.dlang.org/show_bug.cgi?id=15246 Until that happens, locally, in your own codebase, you can just have your own variant of destroy() that infers attributes as weakest of all in a given hierarchy. Provided you don't write classes that violate dtor attributes down the inheritance chain. So at least this problem can be sidestepped, though I agree it should have a formal resolution in the language and the runtime library.
Jun 09
parent Kagamin <spam here.lot> writes:
On Tuesday, 9 June 2020 at 16:33:13 UTC, Stanislav Blinov wrote:
 There's no need for a new interface. What needs to happen is 
 resolution of [1] and amendment to destroy() so it avoids 
 rt_finalize and infers correct attributes. Which, even three 
 years later, I maintain should be resolved by disallowing 
 classes to loosen destructor attributes.

 [1] https://issues.dlang.org/show_bug.cgi?id=15246

 Until that happens, locally, in your own codebase, you can just 
 have your own variant of destroy() that infers attributes as 
 weakest of all in a given hierarchy. Provided you don't write 
 classes that violate dtor attributes down the inheritance chain.
 So at least this problem can be sidestepped, though I agree it 
 should have a formal resolution in the language and the runtime 
 library.
Destructors should be already nogc, it's a contract imposed by GC itself, it's not formally enforced because destructors predate nogc attribute, but violation of the contract is still a bug in user code, so destroy can simply cast destructors to nogc and call like that.
Jun 13
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 09.06.20 17:45, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
 On 09.06.20 17:11, 12345swordy wrote:
 ...

 An idea that show no progress for what? Two years? I am losing my 
 patience with this already. I can't consider d to be a serious 
 language if this bug won't be fix in some reasonable time frame in 
 the future.

 -Alex
I am not sure what you hope to accomplish with this rhetoric. There seems to be a recent surge in people assuming that people contribute to the language because they want it to be "popular"/"serious"/... I highly doubt that this is the case and those messages clutter the forums without adding anything interesting to discussions.
This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years! It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone. https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.disp se?view=netcore-3.1
I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes. Also see: https://issues.dlang.org/show_bug.cgi?id=20914
Jun 09
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 9 June 2020 at 16:43:21 UTC, Timon Gehr wrote:
 On 09.06.20 17:45, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
 [...]
This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years! It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone. https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.dispose?view=netcore-3.1
I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes. Also see: https://issues.dlang.org/show_bug.cgi?id=20914
Which in order for that to happen it needs to be virtual function, not a static function.
Jun 09
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 6/9/20 8:12 PM, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 16:43:21 UTC, Timon Gehr wrote:
 On 09.06.20 17:45, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
 [...]
This is the first bug that I had encounter first hand when programming in d. An bug that hasn't been fixed in years! It can be fix by having the druntime providing a interface say "Dispose" and just have the destroy function call that and leave the old deconstructors alone. https://docs.microsoft.com/en-us/dotnet/api/system.idisposable.disp se?view=netcore-3.1
I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes. Also see: https://issues.dlang.org/show_bug.cgi?id=20914
Which in order for that to happen it needs to be virtual function, not a static function.
No, that's also not necessary. You can inherit attributes without making the function defined by the destructor function declaration virtual. __xdtor still needs to be virtual, but that appears to be the case already.
Jun 09
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 9 June 2020 at 18:47:13 UTC, Timon Gehr wrote:
 On 6/9/20 8:12 PM, 12345swordy wrote:
 On Tuesday, 9 June 2020 at 16:43:21 UTC, Timon Gehr wrote:
 On 09.06.20 17:45, 12345swordy wrote:
[...]
I don't think that's necessary. Destructors should just inherit the base class destructor's attributes, then `destroy` can annotate itself with appropriate attributes. Also see: https://issues.dlang.org/show_bug.cgi?id=20914
Which in order for that to happen it needs to be virtual function, not a static function.
No, that's also not necessary. You can inherit attributes without making the function defined by the destructor function declaration virtual. __xdtor still needs to be virtual, but that appears to be the case already.
How exactly? By having attributes themselves check the attributes for the parent class of the deconstructor?
Jun 09
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Tuesday, 9 June 2020 at 18:57:41 UTC, 12345swordy wrote:

 Which in order for that to happen it needs to be virtual 
 function, not a static function.
No, that's also not necessary. You can inherit attributes without making the function defined by the destructor function declaration virtual. __xdtor still needs to be virtual, but that appears to be the case already.
How exactly? By having attributes themselves check the attributes for the parent class of the deconstructor?
Attributes can't check anything, they're attributes :) The compiler should statically check your destructor against those of members (if any) and a paren't class (which has already gone through the same check). I.e. you simply shouldn't be allowed to derive a class that has less strict attributes than the most strict intersection of the above. If any member has a nogc destructor, the class would have to have a nogc destructor as well. Same if a parent has a nogc destructor. This way would ensure that you could destroy objects of derived classes even via a reference to base class without violating attributes, as such class definition simply would not have compiled.
Jun 09
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
 On 09.06.20 17:11, 12345swordy wrote:
 There seems to be a recent surge in people assuming that people 
 contribute to the language because they want it to be 
 "popular"/"serious"/...
 I highly doubt that this is the case and those messages clutter 
 the forums without adding anything interesting to discussions.
Isn't this way of thinking in itself a problem. How is it any different from bashing Walter for things he's not personally interested in? His complaints wasn't worded out well but you just blew it all over the place.
Jun 09
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10.06.20 02:46, aberba wrote:
 On Tuesday, 9 June 2020 at 15:29:39 UTC, Timon Gehr wrote:
 On 09.06.20 17:11, 12345swordy wrote:
 There seems to be a recent surge in people assuming that people 
 contribute to the language because they want it to be 
 "popular"/"serious"/...
 I highly doubt that this is the case and those messages clutter the 
 forums without adding anything interesting to discussions.
Isn't this way of thinking in itself a problem.
Probably no, but I am not sure which "way of thinking" or what kind of "problem" you are referring to.
 How is it any different from bashing Walter for things he's not personally
interested in?
 ...
What is "it" and why does it have to be different?
 His complaints wasn't worded out well...
 
It was worded out in a way that likely does not encourage potential contributors to work on his issue. I just pointed that out and noted that he is not the only one who has been doing that recently.
 but you just blew it all over the place.
Again, I am not sure what you are trying to say, nor why your reaction is warranted.
Jun 09
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:
 I work 12-14 hours a day to try and make up for lost
 productivity
This isn't good for you... gonna burn yourself out and for nothing. :(
Jun 06
prev sibling parent Jacob Carlborg <doob me.com> writes:
On Saturday, 6 June 2020 at 05:16:59 UTC, Manu wrote:

 I have almost no time recently; work-from-home is hard and I 
 work 12-14
 hours a day to try and make up for lost productivity, and still 
 falling
 behind.
Wow, that sucks. That's not healthy at all. You should come here to Sweden instead and work for DICE :) We care about our employees. Sweden also has one of the world's strongest laws related to employment. -- /Jacob Carlborg
Jun 09
prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:

 Back on-topic; I still use D because I just can't stand C++, 
 and I somehow fundamentally believe D can 'get there'... but 
 god is it a hard and frustrating road! Eternally so close, but 
 always juuuust misses the mark. Maybe one day we'll land the 
 shot >_<
In my opinion there will always be that one missing feature that prevents D from getting there. In other words, if features were a stopping factor then how did anyone ever use C++ 10 years ago?
Jun 05
parent reply Manu <turkeyman gmail.com> writes:
On Fri, Jun 5, 2020 at 3:30 AM Dibyendu Majumdar via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:

 Back on-topic; I still use D because I just can't stand C++,
 and I somehow fundamentally believe D can 'get there'... but
 god is it a hard and frustrating road! Eternally so close, but
 always juuuust misses the mark. Maybe one day we'll land the
 shot >_<
In my opinion there will always be that one missing feature that prevents D from getting there. In other words, if features were a stopping factor then how did anyone ever use C++ 10 years ago?
I feel like I made the case that it's not strictly 'features', so much as implementation quality and/or the complete package experience. I mean, one instance of 'new functionality' is extern(C++), which really is a massive enabler; it creates a migration opportunity which wouldn't be there otherwise. I've been working for years to improve C++ interaction and make it comprehensive and useful. It hasn't been on my list of key struggles recently. We do need to get on top of move construction though... but it's not holding me back personally. `shared` though, that's been in a weird limbo state for a very very long time, and in this instance, the key competitive advantage D offers over C++ is that it has `shared` in the type system. But having that sticker on the box isn't enough, it has to do something meaningful. It actually has to implement mechanics that help us resist the kinds of bugs that you experience with shared data. Even if those _features_ do work, it still needs to pass the tests where it shows it can fit into an elaborate existing ecosystem. When really basic things like inline and weak linkage don't work, that's just a kind of super boring mechanical barrier to successful integration, and there's no excuse I can make for those. We can make workarounds, but they're embarrassing, and we should spend our small quota of "disadvantage points" on the key stuff that's not trivial to fix. So when I say "always just one thing", it's not features; it might be... but it's often also implementation quality, or binary environment integration issues, or build issues, or tooling issues... unfortunately we must _exceed_ a very high bar set by the C++ to ecosystem be successful. We're not evaluating which environment is the best experience overall, what we have to do is *dislodge* a deeply seated establishment by demonstrating sufficient advantages that it tips a subjective threshold of a businesses technical directors. They need to do an evaluation, easily recognise the advantages, and not be nervous. I think we've been pretty close to having everything we need for a while now, but what I was saying here is it absolutely needs to WORK... we can't show that an idea (`shared`) is there but the implementation is broken. That will be received worse than if it wasn't there at all.
Jun 05
parent Dibyendu Majumdar <mobile majumdar.org.uk> writes:
On Saturday, 6 June 2020 at 01:17:02 UTC, Manu wrote:
 On Fri, Jun 5, 2020 at 3:30 AM Dibyendu Majumdar via 
 Digitalmars-d < digitalmars-d puremagic.com> wrote:

 On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:

 Back on-topic; I still use D because I just can't stand C++, 
 and I somehow fundamentally believe D can 'get there'... but 
 god is it a hard and frustrating road! Eternally so close, 
 but always juuuust misses the mark. Maybe one day we'll land 
 the shot >_<
In my opinion there will always be that one missing feature that prevents D from getting there. In other words, if features were a stopping factor then how did anyone ever use C++ 10 years ago?
I feel like I made the case that it's not strictly 'features', so much as implementation quality and/or the complete package experience.
 So when I say "always just one thing", it's not features; it 
 might be...
 but it's often also implementation quality, or binary 
 environment
 integration issues, or build issues, or tooling issues... 
 unfortunately we
 must _exceed_ a very high bar set by the C++ to ecosystem be 
 successful.
 We're not evaluating which environment is the best experience 
 overall, what
 we have to do is *dislodge* a deeply seated establishment by 
 demonstrating
 sufficient advantages that it tips a subjective threshold of a 
 businesses
 technical directors. They need to do an evaluation, easily 
 recognise the
 advantages, and not be nervous.
In my opinion it's been to D's detriment that there is this ever present view that if only this particular feature was added, it would take D over the line... But really what matters more in organizations is that can they depend on D to always work. It is far more important that all existing features work 100% reliably all the time. And most organizations want good tooling support as well. Regards
Jun 06
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:
 'Quickly'? 'Least amount of work'? Pfft... like what?
Oh boy I forgot that other people use a word work as a synonym for effort/time spent and that derailed everything. So I will try again. You value (X). You see a lot of benefit of doing (X). Doing (X) have served you well over the years. (X) is good. You write a proposal for D using (X). People do not immediately accept it so you do more (X) to convince them. If that didnt help you try to do (X) even harder. And if that didnt help you think to yourself that you just need to do (X) just a little bit harder. Then you write another proposal and the pattern continues producing the same kind of problems again and again. Maybe your proposals have enough of (X) and you have problems because you didnt do enough of (Y).
 `shared` is broken, I've done what work I can do alone, but if 
 it's rejected, other people need to step in and make a counter 
 proposal, <...> I know what we need to do with shared.
Whas it rejected or not accepted? Thats a big difference. Rejected means people thought its a bad idea. Not accepted might mean that people are not sure so they play safe. If its the later then changing proposal would not change the outcome.
 I don't know how to convince key folks that shared is really 
 important any more > than I am able to say "shared is really 
 important, and this opportunity depends > on it"...?
I know. Make sure that proposed changes do not negatively affect or block other valid ways of doing multithreading on all platforms(powerPC, GPUs, etc.). And describe how everything should work in all edge cases on all platforms. Then Walter would accept it. Ofcourse you dont have to do that in one swing. You can start by writing a blog post describing lesions learned from game dev on how to do multithreading. What has been tried? What were the problems with those approaches? What is done now? How changes to shared would affect that? In a style of past, present, future covering as much cases as possible. There are not that many people with the kind of experience you have. It would be nice if you could share it. Not only it will improve collective wisdom but also move us closer to a solution to shared. Another approach that has value of its own and helps us move closer to fixing shared is to make compiler multithreaded. When compiler people(Walter) have to work with shared everyday it would be much easier to explain certain things. P.s. My previous post was not intended to insult, belittle or otherwise negatively affect you. If that happened I am sorry and will try express my thoughts in different way
Jun 05
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/4/20 10:44 PM, Manu wrote:
 Most of my effort has been related to fixing them, with varying levels 
 of success.
BTW I wonder how your rvalue binding initiative worked out.
Jun 05
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2020 12:46 PM, Andrei Alexandrescu wrote:
 On 6/4/20 10:44 PM, Manu wrote:
 Most of my effort has been related to fixing them, with varying levels of 
 success.
BTW I wonder how your rvalue binding initiative worked out.
Did you mean this? https://github.com/dlang/DIPs/pull/182
Jun 05
prev sibling parent Meta <jared771 gmail.com> writes:
On Friday, 5 June 2020 at 02:44:17 UTC, Manu wrote:
 I've spent the last 2 years trying to talk about `shared`, 
 while **spectacularly huge** opportunities just sail on by. 
 We've made very small incremental (and broken) progress. The 
 important stuff has been blocked, and no counter-proposals ever 
 presented. Blizzard is one of the biggest and most important 
 gamedev houses in the world; imagine if there were some D code 
 at the heart of all future Blizzard games.
Wow, somehow I missed you changing companies. Have you been at Blizzard since you left Euclideon? Anyway, belated congratulations.
Jun 05
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Manu is a walking talking use case for D.

If there was a single person who would be worth spending millions of 
dollars to satisfy, its him.
Jun 04
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d wrote:
[=E2=80=A6]
 Back on-topic; I still use D because I just can't stand C++, and I someho=
w
 fundamentally believe D can 'get there'... but god is it a hard and
 frustrating road! Eternally so close, but always juuuust misses the mark.
 Maybe one day we'll land the shot >_<
For me writing GTK+ desktop applications, I'd rather use D than Rust or Val= a (I do not actually use Vala at all as it is just too niche), but the develo= per experience with Rust is just so much nicer than using D. Writing Rust code = is harder than writing the same functionality in D (except for asynchronous an= d futures based code, where Rust just wins over D hands down), but the D plug= in to CLion and IntelliJ IDEA isn't anywhere near the capability of the Rust plugin. Writing all code with Emacs, Bash and lldb is just a terrible experience, despite the wonders of Emacs. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jun 05
next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
 On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d 
 wrote: […]
 [...]
For me writing GTK+ desktop applications, I'd rather use D than Rust or Vala (I do not actually use Vala at all as it is just too niche), but the developer experience with Rust is just so much nicer than using D. Writing Rust code is harder than writing the same functionality in D (except for asynchronous and futures based code, where Rust just wins over D hands down), but the D plugin to CLion and IntelliJ IDEA isn't anywhere near the capability of the Rust plugin. Writing all code with Emacs, Bash and lldb is just a terrible experience, despite the wonders of Emacs.
Please also have a look at Visual Studio Code and code-d extension. It works really nice and debugging also works great. Kind regards Andre
Jun 05
next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Friday, 5 June 2020 at 09:08:23 UTC, Andre Pany wrote:
[...]
 Please also have a look at Visual Studio Code and code-d 
 extension. It works really nice and debugging also works great.

 Kind regards
 Andre
+1 I am not a fan of Microsoft - to say it gently - but VS Code, which works on Linux quite well, is the only MS program I use every day.
Jun 05
prev sibling next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 5 June 2020 at 09:08:23 UTC, Andre Pany wrote:
 On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
 On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d 
 wrote: […]
 [...]
For me writing GTK+ desktop applications, I'd rather use D than Rust or Vala (I do not actually use Vala at all as it is just too niche), but the developer experience with Rust is just so much nicer than using D. Writing Rust code is harder than writing the same functionality in D (except for asynchronous and futures based code, where Rust just wins over D hands down), but the D plugin to CLion and IntelliJ IDEA isn't anywhere near the capability of the Rust plugin. Writing all code with Emacs, Bash and lldb is just a terrible experience, despite the wonders of Emacs.
Please also have a look at Visual Studio Code and code-d extension. It works really nice and debugging also works great. Kind regards Andre
+1. Like Andre, I really like VS Code+code-d. Then again I jumped to VS Code from a 70s era text editor that I originally wrote in VAX assembly language, not a patch on CLion. My guess is that I was the only person in the world still using the editor whereas CLion, according to a recent survey of Rust programmers, is used by 1.1% of the 3997 respondents. The same article has VSCode in first place at 34.9%. As I've inferred from many of Russel's postings, the tools surrounding the language matter, a lot. I agree completely. It's easier for people to start using D, and continue using D, when the tools offload the mechanical. Hats off to the D tool builders!
Jun 05
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2020-06-05 at 09:08 +0000, Andre Pany via Digitalmars-d wrote:
 On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
 On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d=20
 wrote: [=E2=80=A6]
Does this mean using the Microsoft build with all the telemetry it has or Codium which is a build without all the branding and telemetry? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jun 06
parent Jan =?UTF-8?B?SMO2bmln?= <hrominium gmail.com> writes:
On Saturday, 6 June 2020 at 09:10:04 UTC, Russel Winder wrote:
 On Fri, 2020-06-05 at 09:08 +0000, Andre Pany via Digitalmars-d 
 wrote:
 On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
 On Fri, 2020-06-05 at 12:44 +1000, Manu via Digitalmars-d 
 wrote: […]
Does this mean using the Microsoft build with all the telemetry it has or Codium which is a build without all the branding and telemetry?
I am using codium. So far I didn't have any problems.
Jun 06
prev sibling parent reply Cogitri <oss cogitri.dev> writes:
On Friday, 5 June 2020 at 08:39:09 UTC, Russel Winder wrote:
 For me writing GTK+ desktop applications, I'd rather use D than 
 Rust or Vala (I do not actually use Vala at all as it is just 
 too niche), but the developer experience with Rust is just so 
 much nicer than using D. Writing Rust code is harder than 
 writing the same functionality in D
Same for me, writing in D is just so much more fun and quicker than writing it in Rust (at least for GTK applications since the GTK concept doesn't really map well onto Rust). Most advantages of Rust are kind of moot when using GTK anyway since that means refcounting all the things and trusting upon the D GC to handle the refcounting works really well for that. I do have to admit that I miss how infrequent SIGSEGVs are with Rust (read: somewhat impossible unless you have bad bindings/C libs), but since I don't have to manually manage memory in D too often it's not too bad in D either and in return I save loads of time while coding due to the capabilities I have in D that Rust takes away from me. Also, static-if and static-for rocks and at least in the way I use it doesn't cause my compilation times to easily go into the minutes for small programs (right, Rust? :)
Jun 05
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2020-06-05 at 10:22 +0000, Cogitri via Digitalmars-d wrote:
[=E2=80=A6]
 Same for me, writing in D is just so much more fun and quicker=20
 than writing it in Rust (at least for GTK applications since the=20
 GTK concept doesn't really map well onto Rust). Most advantages=20
 of Rust are kind of moot when using GTK anyway since that means=20
 refcounting all the things and trusting upon the D GC to handle=20
 the refcounting works really well for that. I do have to admit=20
 that I miss how infrequent SIGSEGVs are with Rust (read: somewhat=20
 impossible unless you have bad bindings/C libs), but since I=20
 don't have to manually manage memory in D too often it's not too=20
 bad in D either and in return I save loads of time while coding=20
 due to the capabilities I have in D that Rust takes away from me.=20
 Also, static-if and static-for rocks and at least in the way I=20
 use it doesn't cause my compilation times to easily go into the=20
 minutes for small programs (right, Rust? :)
I get the feeling that there is a bit of a fight going on between the C++, Rust, Python, and Vala camps as to what is the replacement for C for GTK+ = =E2=80=93 it has been going on since C++ created a binding and Vala was created, but I think GTK+ 4 is reopening things obviously. For so many Python is a non-starter, and yet it gets used for so much stuff= . Interesting. Clearly there are people saying C is the one true language that shall never= be replaced, which is fine for them but not for me. Vala has a following but is just a bit too niche to get real traction, but maybe I am wrong. C++ had lost the race till C++11, but didn't really get moving after that except amongst the C++ lovers. C++20 may change that, but maybe not. Rust is being seen as the replacement for C for application developers and = a lot of effort is going into it.=20 Of course D is the "happy place" between C++, Vala, and Rust. (And Python?)= It has inheritance of classes so beats Rust, It is less niche so beats Vala. (= It is static and not dynamic so beats Python?) Whilst a big language D is simp= ler and easier than C++ so beats C++.=20 GTK+ does all it's own garbage collection of GTK+ objects, so none of the D= GC gets used there. This provides ammunition for the GC haters to say Rust (an= d C++?) is better that D. Obviously they are wrong but as the saying goes "haters going to hate". Python has it's own GC and no-one treats that as a downside of using Python for GTK+ work. Clearly then D having a GC means ju= st the same as Python having a GC: managing memory is the last of your worries= as an application programmer. Regarding SIGSEGV, I get none from Rust, some from D, but most from the C libraries all my stuff gets build on. This is just going to be a problem un= til all the libraries get written in Rust, D, or Go. The big problem for me staying with D for GTK+ stuff, and I may just be repeating myself here, is that whilst D has GtkD, rust had gtk-rs, and Pyth= on is dynamic. The issue here is that GtkD is a pure automated translated binding, whereas gtk-rs is an automated translated binding with added extra= s. gtk-rs is just that little bit more Rust-y that GtkD is D-y. But most importantly gtk-rs has a lot more support for asynchronous working using ev= ent loops. D has the tools, but compared to the Rust tools, D is just a little = bit more clunky, enough to get irritating. Irritation leads to fear and thence "Fear Leads to Anger. Anger Leads to Hate. Hate Leads to Suffering". Or something like that. So for pure GTK+ stuff D is great, so why hasn't it wiped Vala off the map?= I guess because Vala is a GTK+ home grown offering, and very few GTK+ folk lo= ok outside the C++, Rust, Vala, C, Python, bubble. Clearly the problem is resource. C, C++, Python and Rust have it, D and Val= a don't. And that is the problem at the end of the day, Rust and Python suppo= rt for GTK+ working evolves as people complain and use it, D support does not.= :- ( PS Thanks to Mike Wey for all he does with GtkD, I just there were ways of getting more people working on it. PPS Thanks to Samael for all he does with IntelliJ-DLanguage, I just wish there were ways of getting more people working on it. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Jun 06
parent mw <mingwu gmail.com> writes:
On Saturday, 6 June 2020 at 08:50:51 UTC, Russel Winder wrote:
 Of course D is the "happy place" between C++, Vala, and Rust. 
 (And Python?) It has inheritance of classes so beats Rust, It 
 is less niche so beats Vala. (It is static and not dynamic so 
 beats Python?) Whilst a big language D is simpler and easier 
 than C++ so beats C++.
I like this assessment :-) Now, if we can improve D compiler & libraries' stability, and with a killer app, D will surely take off!
Jun 06
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What [about] you?
Because I get paid for it... And because my new language project isn't ready yet. ;-) IMO, D is the worst best language. It simultaneously goes so far in useful directions that it makes using any other C-like painful, but still falls so far short of what it itself shows is possible. (shared, immutable, copy constructors, the half-working lifetime tracking, great templates with horrible performance, mixin but no macros, ddoc but no introspection...) I think that's the reason why D people keep wandering off to make their own compilers. Lisp has somewhat the same property, but there's less impetus to go off and make your own Lisp because the base language is so very extensible.
Jun 04
next sibling parent Max Samukha <maxsamukha gmail.com> writes:
On Friday, 5 June 2020 at 04:55:36 UTC, FeepingCreature wrote:
 

 And because my new language project isn't ready yet. ;-)

 IMO, D is the worst best language. It simultaneously goes so 
 far in useful directions that it makes using any other C-like 
 painful, but still falls so far short of what it itself shows 
 is possible. (shared, immutable, copy constructors, the 
 half-working lifetime tracking, great templates with horrible 
 performance, mixin but no macros, ddoc but no introspection...) 
 I think that's the reason why D people keep wandering off to 
 make their own compilers. Lisp has somewhat the same property, 
 but there's less impetus to go off and make your own Lisp 
 because the base language is so very extensible.
Here is a concrete illustration of the above. Consider someone wants to accomplish a trivial code generation task: void foo() { static foreach(i, ...) { static if (i == 3) outerDecl; localDecl; statement; } } Non-static foreach does not fit because of outerDecl. localDecl is problematic because 'static foreach' does not introduce local scopes. The poor programmer tries the most obvious: { localDecl; } This does not work, because of the old bug https://issues.dlang.org/show_bug.cgi?id=3031, which was deemed not deserving a proper fix. Next attempt - template mixin, which does introduce a special kind of scope: void foo() { mixin template Local() { localDecl; statement; } static foreach (..) mixin Local; } This doesn't work because declaring mixin templates are not allowed inside functions. Work around by taking the mixin decl out of the function at the cost of cluttering the parent scope. Then, the poor programmer is reminded that mixins cannot have statements. After a significant amount of cursing, the programmer, desperately trying to avoid the ugliness of string mixins and the inglorious lambda-statement hack, discovers this https://github.com/dlang/dmd/pull/6760, reads the DIP and realizes that his issue should have been solved 3 years ago but was forgotten or deemed unimportant, who knows. Of course, all this can be worked around with ugly hacks. However, if you multiply this experience by half the number of D's features, you will have the answer why people get frustrated. I think the problem is that the designers of the features do not use them. Another problem is the "hardcore mechanical engineer" culture: if there's a working hack, no matter how ugly, use it and never look back.
Jun 05
prev sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Friday, 5 June 2020 at 04:55:36 UTC, FeepingCreature wrote:
 mixin but no macros
Reminds me of q{}-based mixins: https://forum.dlang.org/post/jekltctbqxettfzzefbc forum.dlang.org It's not macros directly, but about the best you can get from macros without suffering from the bad consequences of C++ macros, including the proposal getting directly rejected by Walter.
Jun 10
prev sibling next sibling parent Mathias LANG <geod24 gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
Learning D made me a better C++ developer, which was previously my language of choice. Also, there's not other language where I can express my thoughts the way I do it in D (so, modeling power).
Jun 05
prev sibling next sibling parent Luis <luis.panadero gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
I use D for toy or small personal projects. I only had the luxury to use it for work, to make a small tool to help to automate deploys on tomcat servers, downloading the WAR from a nexus server. And now these tool isn't necessary anymore (now it's all doing with a Jenkins taks doing mvn package + bash script + ansible) Why? Well, what I like more of D it's the metaprograming power that gives CTFE + mixins and another little details that makes it great (slices, parallel for, NVI pattern, etc). However, I always have the sensation that it's unpolished and need to fix too many rough corners.
Jun 05
prev sibling next sibling parent tastyminerals <tastyminerals gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 I personally can't use any other system programming language 
 due to the expressiveness and familiarity of D. Its familiar 
 and some syntactic expressiveness are just hard to get in other 
 systems languages...feels easier to model code in D.

 I don't use D primarily for work (Node.Js due to packages and 
 cloud support...web services), but D is my go-to system 
 language. Personally, wished I could use D for everything.

 I like the community here better, I like the engagement and 
 support. Yeah, it's not perfect but way better than anywhere 
 else I've been.

 What are you?
I might sound naive but I picked D for speed and then when I learned more about the language a really liked pragmatic the "get things done" approach which this language streamlines. It's not ceremonious and self-important as Scala which I use at work or too high level and slow as Python. It's just there, take it and use it after a couple of weeks reading the first few chapters. Mild learning curve with C++ like performance and no bullshit. A rare combination. Also, I like the community.
Jun 05
prev sibling next sibling parent Vladimirs Nordholm <v vladde.net> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
Little late to the party. I feel the language is reasonable and there are very rarely any surprises. Compared to PHP or C++ for instance: - PHP language design is horrible and bad decisions made long ago affect the language even today. - C++ has weird syntax, like `std::something<here, there<more>>` and still catches me with its include system. And I love the community. The forum's "Learn" is so helpful, and I have never had a bad experience there.
Jun 08
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 What are you?
My days in college were assignments in Java and reimplement them I have utilities written in D at work and my hobby programming, not much these days. I develop test automation for a web based app as my day job. My preference to use D probably comes from a number of different parts. * I'm familiar with the library selection * The language has many toys to play with feels like the compiler avoids helping you to write correct meta programs) With having history in D I have these benefits * I know when I'm pushing the boundaries of the language * writing a quick hack for a specific use case can be easier than finding a generic library that mostly fits. But things get even stranger when I consider the tools at work. I don't have any other contributors, supposedly because it is D for these tools. I personally have jumped into improving VB, When we look at the future of our automation, it looks like Javascript will be the language to go to. But even that is a to a mainstream language is going to be a pain. So now when I need a script for some infrastructure at work... I'm dead in the water. I want to write it in D. I feel obligated to use something standard, I don't want to build it in something standard and then be the sole maintainer.
Jun 10
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 11 June 2020 at 04:51:28 UTC, Jesse Phillips wrote:
 On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 [...]
My days in college were assignments in Java and reimplement [...]
Seems like you're in the tight position choosing between these two. I've talked to folks who say D is nice but the ecosystem doesn't help to get things done...libraries, development tools, and content seems to pop up a lot.
Jun 11
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 11 June 2020 at 11:07:12 UTC, aberba wrote:
 On Thursday, 11 June 2020 at 04:51:28 UTC, Jesse Phillips wrote:
 On Wednesday, 3 June 2020 at 11:12:08 UTC, aberba wrote:
 [...]
My days in college were assignments in Java and reimplement [...]
Seems like you're in the tight position choosing between these two. I've talked to folks who say D is nice but the ecosystem doesn't help to get things done...libraries, development tools, and content seems to pop up a lot.
True. What I do for writing selenium based tests, or switch to another browser test API just would not be possible today. We would have to build the api communication from the ground up. The company I work for doesn't develop software testing solutions so I would not be able to convince them to put what would basically be money to improve D. I think D is fine for the scripts we tend to have and if every was fluent/enjoying D, I could see time taken to implement something in D. But I'm working with QA and developers which don't appear to be doing it for the joys of programming.
Jun 11
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips wrote:
 I think D is fine for the scripts we tend to have and if every 
 was fluent/enjoying D, I could see time taken to implement 
 something in D. But I'm working with QA and developers which 
 don't appear to be doing it for the joys of programming.
Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm. That will be the case until/unless D becomes a mainstream language with a better reason to use it than "it's a fun language to program in".
Jun 11
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
 On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips wrote:
 I think D is fine for the scripts we tend to have and if every 
 was fluent/enjoying D, I could see time taken to implement 
 something in D. But I'm working with QA and developers which 
 don't appear to be doing it for the joys of programming.
Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm.
I don't think the core team wants it to remain this way. Unless D is fine staying this way for another 10yrs. By then we'll all be gone.
 That will be the case until/unless D becomes a mainstream 
 language with a better reason to use it than "it's a fun 
 language to program in".
It depends on what you mean by mainstream. These issues as I cited are not not related to the language itself per se. Its related to the ecosystem. And its mislead to make it seem like there's some "elite" group of coders here who are absolutely comfortable with the current state of affairs. Besides, you can read from all the experiences shared in this thread and see how many of them are not related to D itself being a blocker. Its the other stuff. Do we know how many people use D or are interested in D? No. Do we know the "self-selected group" of people or the sort of interest in D? No. Do we know what people are using D for in their companies? I'm not sure we do. Very little survey is done on some of these things. Its again misleading to think comments here is a true representation of D users. Many people I've unexpectedly met online almost never post anything here. And since no~ one really knows where the D money goes and where help is much needed (as such information is not available for community members to know), I'll say there not much~ financial investment into D tools. To expect that someone will do this for free is almost not going to happen. Again we've seen that anytime the D Foundation pays someone (through funds, campaign, etc), job gets done. If there was an "elite" group of hard-core programmers who don't care about tools, Visual Studio wouldn't exist in the first place. I'm not saying we are Microsoft, I'm saying we should NOT beat down concerns and issues expressed in relations to the tools we have or don't have...yet. I'm personally very glad we have people here who go as far (some each and every days for yrs) to invest heavily in D tools out of their free time. But that alone is not enough for a small community like ours. Again the community could be bigger. And about community, it not just about popularity at all. Its more about having many hands on deck, people with diverse skills and experience to contribute to both the core language, tools, resources, finance and the like.
Jun 11
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 11 June 2020 at 20:21:12 UTC, aberba wrote:
 On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
 On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips 
 wrote:
 I think D is fine for the scripts we tend to have and if 
 every was fluent/enjoying D, I could see time taken to 
 implement something in D. But I'm working with QA and 
 developers which don't appear to be doing it for the joys of 
 programming.
Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm.
I don't think the core team wants it to remain this way. Unless D is fine staying this way for another 10yrs. By then we'll all be gone. <snip>
I *think* we're in agreement here. I just wanted to correct your inference that I meant some kind of "elite" super hackers when I said that the people posting on this list are a "self-selected group". What I meant is that the people who generally post on this mailing list are by definition not average programmers, in that they don't just learn the popular languages/frameworks you need to know to get a job and stick to those; they go out of their way to use more obscure and possibly experimental languages out of a joy for programming and/or taking new and interesting approaches to problems. That being said, a lot of the people who post here are far and away some of the best programmers I've ever seen, and I've learned a great deal just being involved with D in some small capacity.
Jun 12
parent aberba <karabutaworld gmail.com> writes:
On Friday, 12 June 2020 at 19:29:09 UTC, Meta wrote:
 On Thursday, 11 June 2020 at 20:21:12 UTC, aberba wrote:
 On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
 On Thursday, 11 June 2020 at 13:18:58 UTC, Jesse Phillips 
 wrote:
 I think D is fine for the scripts we tend to have and if 
 every was fluent/enjoying D, I could see time taken to 
 implement something in D. But I'm working with QA and 
 developers which don't appear to be doing it for the joys of 
 programming.
Good point. It's been said many times before, but the people who use D the most and post on this mailing list are a self-selected group that, by definition, are outside the norm.
I don't think the core team wants it to remain this way. Unless D is fine staying this way for another 10yrs. By then we'll all be gone. <snip>
I *think* we're in agreement here. I just wanted to correct your inference that I meant some kind of "elite" super hackers when I said that the people posting on this list are a "self-selected group". What I meant is that the people who generally post on this mailing list are by definition not average programmers, in that they don't just learn the popular languages/frameworks you need to know to get a job and stick to those; they go out of their way to use more obscure and possibly experimental languages out of a joy for programming and/or taking new and interesting approaches to problems.
I guess that's you speaking for yourself. And then are you saying those again special programmers don't care about the ecosystem experience and are willing to live whatever it is. That
 being said, a lot of the people who post here are far and away 
 some of the best programmers I've ever seen,
Best is debatable. Are back-end devs better than frontend? Are systems programmers better than web devs? I don't doubt the are people who think they are smarter just because they find themselves in a certain domain. And that only their needs matter. Again, read through the experience and go through the dub repository, you see how all kinds of people use D. Is D popular? No, not even close. Is it the best to get to job done, it's dependence (at least for me)...ecosystem wise, No. Does D have the best modeling power? Yes Again this is not about popularity. The thing is if you've never experienced something like the rust community or python community or JavaScript, you'll never get this I'm trying to say. The power of a bigger community. and I've learned a
 great deal just being involved with D in some small capacity.
We both have.
Jun 13
prev sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 11 June 2020 at 18:00:51 UTC, Meta wrote:
 Good point. It's been said many times before, but the people 
 who use D the most and post on this mailing list are a 
 self-selected group that, by definition, are outside the norm. 
 That will be the case until/unless D becomes a mainstream 
 language with a better reason to use it than "it's a fun 
 language to program in".
I'm quite thankful for what D has done for me. I've only done a little bit of C and C++. I really didn't want to program in those languages. D has allowed me access to similar tools and abilities to interact with C based libraries easily. As annoying as the Win32 api can be, I can still easily incorporate it into my programs. be better in D. Every time I reach for generics it is never the tool I think it is and I have to resort to runtime type information.
Jun 12