www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - I have a plan.. I really DO

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
I never ever (I think) did something provocative, something to 
finally see:

- who in the community WANTS D language to succeed?

- who are just these funny “people” let’s call th this, that are 
I don’t know “just hang around”

Because shame is a weapon much like fear (of death esp), pride 
can be used as weapon but ehm better shame the bastard...

And so on.

So - until we all understand that these donations are not because 
we are begging fir money.

I will send ~ 10$ each day _specifically_ to see who WANTS D TO 
SUCCED and WILL NOT BE SHAMED LIKE THAT FOR ONCE!

It is because it’s (soon) your last chance to invest into the 
Future.

P.S. I mean what you think the future of native code is??? Rust? 
Crystal?? Nim???
Jun 29 2018
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 I never ever (I think) did something provocative, something to 
 finally see:

 - who in the community WANTS D language to succeed?

 - who are just these funny “people” let’s call th this, that 
 are I don’t know “just hang around”

 Because shame is a weapon much like fear (of death esp)



And because I (of aaall people at least here, maybe I just don’t 
see others!) have no shame!

I will roll on. You like the daily rant?
Come get it! I have all the fucking bikering over say the 
merits(!) of say rstrip vs stripRight, right here - come take 
some, it’s fresh! Free even!

Like how will these attempt to stop me look like? Pathetic, most 
likely but they will and we all we will have the good guys ( 
Atilla, this for you, man I swear WE will have fun and forums 
will be cool again)...


sandwich (for free!!) and he doesn’t like it - vegetarian(!).

Okay:

- I want async and await and async function and ALL of thay stuff 


( I wait for a few moments to “compose” myself!)


know it?)

- Then how much effort (at least in theory, nit to mention that 
is an awful approach and we have Fibers, vibed, mecca and maybe 
soon Photon will roll!) does it take?!

- Please let’s start with symbolic gesture, with plans like that 
a 1000$ is just a sign of goodwill right?

....


 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???
Jun 29 2018
prev sibling next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 I never ever (I think) did something provocative, something to 
 finally see:

 - who in the community WANTS D language to succeed?

 - who are just these funny “people” let’s call th this, that 
 are I don’t know “just hang around”

 Because shame is a weapon much like fear (of death esp), pride 
 can be used as weapon but ehm better shame the bastard...

 And so on.

 So - until we all understand that these donations are not 
 because we are begging fir money.

 I will send ~ 10$ each day _specifically_ to see who WANTS D TO 
 SUCCED and WILL NOT BE SHAMED LIKE THAT FOR ONCE!

 It is because it’s (soon) your last chance to invest into the 
 Future.

 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???


I know most people here don't agree with me, but I think you're 
fighting an already lost battle ;)

As you know, I'm convinced that D could be marketed as the 
perfect language to develop native web servers and mobile 
applications, and have its core libraries somewhat extended in 
thqg direction, like Go and Crystal which allow "plug'n'play" web 
server development for instance, but obviously the D "leadership" 
remains convinced that D must be sold as the best alternative to 
C++.

Personally I'm a complete D fan because it is SOOO MUCH better 
than JavaScript/Python/Perl/etc for file processing...

For engine and game development I'm still using C++, despite I 
prefer D, and believe me this won't change for a while.

Game development is a very special use case, but personally I 
don't think that many of those who use C++ for close-to-the-metal 
development should be that much interested in switching to D, 
because most of its standard libraries depend on the presence of 
a GC...

And to answer your question, IMHO the future of native code 
probably remains C++ (not Rust) for system programming, and 
(unfortunately) Go for web development (great ecosystem, db 

several core feature many developers need (generics, etc).

Once Crystal integrates parallelism (at 1.0), it should become de 

it's actually "Go-made-right". For instance it's genericity 
system works well, and its type inference system natively support 
union types.


instance, it doesn't manage mutual dependencies automatically for 
you, which is a pity.

And Rust, despite it has perfect C/C++-like performance and 
doens't need a GC, its borrow checker made it a hell to use at 
first, as unfortunately Rust hasn't integrated strong/weak 
references as a core feature of the language (Rc/Weak are 
templates, RefCell is needed for mutability, etc), despite that's 
actually what many C++ developers use today for resource 
management, and would be more than enough for them to get their 
job done once they switch to Rust...
Jun 29 2018
next sibling parent reply Gheorghe Gabriel <knoppy273 live.com> writes:
On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky 
 wrote:>
 For engine and game development I'm still using C++, despite I 
 prefer D, and believe me this won't change for a while.

 Game development is a very special use case, but personally I 
 don't think that many of those who use C++ for 
 close-to-the-metal development should be that much interested 
 in switching to D, because most of its standard libraries 
 depend on the presence of a GC...


I switched form C++ to D on game development one year ago.
I am developing CrystalEngine in D, it's on DUB.
The performance with GC it's good, for now.
Anyway, I try to avoid GC as much as possible.
The main issue for me in game development with D is the 
cross-compilation (e.g. iOS, Windows Universal Platform..).
But also, with (static if/foreach, mixin) and other CTFE stuff, I 
can optimize the code much better than with c++ poor CTFE and 
preprocessor.
Jun 29 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Anyway, I try to avoid GC as much as possible.
 The main issue for me in game development with D is the 
 cross-compilation (e.g. iOS, Windows Universal Platform..).


+1

That's why I don't think C++ will be soon replaced by Rust, D, etc

Maybe in a few years, but obviously not right now...
Jun 29 2018
prev sibling next sibling parent reply bauss <jj_1337 live.dk> writes:
On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 As you know, I'm convinced that D could be marketed as the 
 perfect language to develop native web servers and mobile 
 applications, and have its core libraries somewhat extended in 
 thqg direction, like Go and Crystal which allow "plug'n'play" 
 web server development for instance


D allows for plug n' play web server development too.
Jun 29 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 10:06:12 UTC, bauss wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 As you know, I'm convinced that D could be marketed as the 
 perfect language to develop native web servers and mobile 
 applications, and have its core libraries somewhat extended in 
 thqg direction, like Go and Crystal which allow "plug'n'play" 
 web server development for instance


 D allows for plug n' play web server development too.


Then this should be more advertised...

For instance :

https://crystal-lang.org/

The FIRST paragraph of text of Crystal's web page is :

"Syntax

Crystal’s syntax is heavily inspired by Ruby’s, so it feels 
natural to read and easy to write, and has the added benefit of a 
lower learning curve for experienced Ruby devs.


require "http/server"

server = HTTP::Server.new do |context|
   context.response.content_type = "text/plain"
   context.response.print "Hello world, got 

end

puts "Listening on http://127.0.0.1:8080"
server.listen(8080)
"

So the FIRST thing you learn about Crystal is that the standard 
library already gives you all you need to program a simple "hello 
world" web server.

The Go standard library is also known to provide the same 
building blocks :

package main

import (
	"fmt"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r 
*http.Request) {
		fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
	})

	http.ListenAndServe(":80", nil)
}

Both are batteries-included for web development. That's why many 
developers don't feel the need to use thirdparty frameworks to 
implement their microservices...

So if it's also the case for D, then sorry for my mistake...
Jun 29 2018
parent reply Bauss <jj_1337 live.dk> writes:
On Friday, 29 June 2018 at 12:32:46 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 10:06:12 UTC, bauss wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 As you know, I'm convinced that D could be marketed as the 
 perfect language to develop native web servers and mobile 
 applications, and have its core libraries somewhat extended 
 in thqg direction, like Go and Crystal which allow 
 "plug'n'play" web server development for instance


 D allows for plug n' play web server development too.


 Then this should be more advertised...

 For instance :



 https://crystal-lang.org/

 The FIRST paragraph of text of Crystal's web page is :

 "Syntax

 Crystal’s syntax is heavily inspired by Ruby’s, so it feels 
 natural to read and easy to write, and has the added benefit of 
 a lower learning curve for experienced Ruby devs.


 require "http/server"

 server = HTTP::Server.new do |context|
   context.response.content_type = "text/plain"
   context.response.print "Hello world, got 

 end

 puts "Listening on http://127.0.0.1:8080"
 server.listen(8080)
 "

 So the FIRST thing you learn about Crystal is that the standard 
 library already gives you all you need to program a simple 
 "hello world" web server.

 The Go standard library is also known to provide the same 
 building blocks :

 package main

 import (
 	"fmt"
 	"net/http"
 )

 func main() {
 	http.HandleFunc("/", func(w http.ResponseWriter, r 
 *http.Request) {
 		fmt.Fprintf(w, "Hello, you've requested: %s\n", r.URL.Path)
 	})

 	http.ListenAndServe(":80", nil)
 }

 Both are batteries-included for web development. That's why 
 many developers don't feel the need to use thirdparty 
 frameworks to implement their microservices...

 So if it's also the case for D, then sorry for my mistake...


Sorry. My misunderstanding.

I thought you meant there were no frameworks that could be used 
as plug n play for web development.

For this to ever happen std.socket needs to be deprecated already 
and rewritten so D can have a standard http module.

I don't really see that happening though.

However I agree with the third party libraries to an extended, 
but it's not really an issue. All developers will end up with 
third party dependencies in one way or another, especially for 
web development. Like you'll most likely end up with some kind of 
JavaScript library, some sass/less compiler etc.

If you're a web developer with no dependencies then youre either 
reinventing the wheel (could cause trouble in the long run, if 
your implementations aren't correct.) Or your application just 
isn't more than a hobby project.

Most enterprise projects will have dependencies outside standard 
libraries and that is true for ex. Go too.

You also have to remember that D has a very different philosophy.
Jun 29 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 If you're a web developer with no dependencies then youre 
 either reinventing the wheel (could cause trouble in the long 
 run, if your implementations aren't correct.) Or your 
 application just isn't more than a hobby project.

 Most enterprise projects will have dependencies outside 
 standard libraries and that is true for ex. Go too.


I agree with you, but what I mean is that all those nice Go and 
Crystal web frameworks are actually implemented using exactly the 
same building blocks, so that their authors didn't have to 
reinvent the wheel to reimplement them.

That's why there are so many available frameworks, and you can 
easily pick one which closely matches your needs and 
preferences...
Jun 29 2018
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 29 June 2018 at 17:08:12 UTC, Ecstatic Coder wrote:

 If you're a web developer with no dependencies then youre 
 either reinventing the wheel (could cause trouble in the long 
 run, if your implementations aren't correct.) Or your 
 application just isn't more than a hobby project.

 Most enterprise projects will have dependencies outside 
 standard libraries and that is true for ex. Go too.


 I agree with you, but what I mean is that all those nice Go and 
 Crystal web frameworks are actually implemented using exactly 
 the same building blocks, so that their authors didn't have to 
 reinvent the wheel to reimplement them.

 That's why there are so many available frameworks, and you can 
 easily pick one which closely matches your needs and 
 preferences...


Well you don't really need to re-invent the wheel at all with D 
either tbh.

You would need to with vibe.d, because it's really just the 
skeleton of a web application, but with Diamond? Not so much. It 
supports things that other frameworks don't even support, which 
you will end up implementing yourself anyway in 99% of all other 
frameworks. To give an example, consent, privacy and GDPR. There 
is no framework, at least what I have seen, that has compliance 
for such things implemented, but Diamond has it usable straight 
out of the box. Another example would be validation for email, 
url, various credit-cards, files (Not just extension, but also 
whether the data is correct.) etc. most of such validations are 
very limited in other frameworks or non-existent at all.

My point is that, even if those languages has http somewhat 
standard, they do not implement actual features that are useful 
to your business logic, application design etc. only to the 
skeleton.

However with frameworks in D you do get the best of both worlds.

http://diamondmvc.org/
Jun 29 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 18:48:19 UTC, bauss wrote:

 On Friday, 29 June 2018 at 17:08:12 UTC, Ecstatic Coder wrote:

 If you're a web developer with no dependencies then youre 
 either reinventing the wheel (could cause trouble in the long 
 run, if your implementations aren't correct.) Or your 
 application just isn't more than a hobby project.

 Most enterprise projects will have dependencies outside 
 standard libraries and that is true for ex. Go too.


 I agree with you, but what I mean is that all those nice Go 
 and Crystal web frameworks are actually implemented using 
 exactly the same building blocks, so that their authors didn't 
 have to reinvent the wheel to reimplement them.

 That's why there are so many available frameworks, and you can 
 easily pick one which closely matches your needs and 
 preferences...


 Well you don't really need to re-invent the wheel at all with D 
 either tbh.

 You would need to with vibe.d, because it's really just the 
 skeleton of a web application, but with Diamond? Not so much. 
 It supports things that other frameworks don't even support, 
 which you will end up implementing yourself anyway in 99% of 
 all other frameworks. To give an example, consent, privacy and 
 GDPR. There is no framework, at least what I have seen, that 
 has compliance for such things implemented, but Diamond has it 
 usable straight out of the box. Another example would be 
 validation for email, url, various credit-cards, files (Not 
 just extension, but also whether the data is correct.) etc. 
 most of such validations are very limited in other frameworks 
 or non-existent at all.

 My point is that, even if those languages has http somewhat 
 standard, they do not implement actual features that are useful 
 to your business logic, application design etc. only to the 
 skeleton.

 However with frameworks in D you do get the best of both worlds.

 http://diamondmvc.org/


Indeed this framework looks really complete, and should get much 
more promotion from D's official website.

But I still think that D's vision of what should be included in 
the standard library really diverges from those of Go and 
Crystal, despite this strategy has worked pretty well for them, 
and that Diamond clearly proves that D has all the basic language 
features to compete well with them (native performance, 
fiber-based concurrency, great string and array support, etc).
Jun 29 2018
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 Once Crystal integrates parallelism (at 1.0), it should become 

 because it's actually "Go-made-right". For instance it's 
 genericity system works well, and its type inference system 
 natively support union types.


Except it has no Windows support and doesn't look like it will 
happen anytime soon. Some people might be living in a UNIX 
bubble, but Windows is a big market, and a language won't make it 
big without Windows support.
Jun 29 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 Once Crystal integrates parallelism (at 1.0), it should become 

 because it's actually "Go-made-right". For instance it's 
 genericity system works well, and its type inference system 
 natively support union types.


 Except it has no Windows support and doesn't look like it will 
 happen anytime soon. Some people might be living in a UNIX 
 bubble, but Windows is a big market, and a language won't make 
 it big without Windows support.


Right :)

But remember that Crystal is still in its infancy, as it hasn't 
reached its 1.0 version yet.

Parallelism is on its way, and Windows support too...

Don't forget that nowadays many (can I say most ?) servers are 
based on unix variants, so their platform support order looks 
perfectly fine and logical to me.
Jun 29 2018
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 29 June 2018 at 19:42:56 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 Once Crystal integrates parallelism (at 1.0), it should 

 etc, because it's actually "Go-made-right". For instance it's 
 genericity system works well, and its type inference system 
 natively support union types.


 Except it has no Windows support and doesn't look like it will 
 happen anytime soon. Some people might be living in a UNIX 
 bubble, but Windows is a big market, and a language won't make 
 it big without Windows support.


 Right :)

 But remember that Crystal is still in its infancy, as it hasn't 
 reached its 1.0 version yet.

 Parallelism is on its way, and Windows support too...

 Don't forget that nowadays many (can I say most ?) servers are 
 based on unix variants, so their platform support order looks 
 perfectly fine and logical to me.


Actually a large share of servers run Windows Server and/or Azure 
servers running Windows too.

It's not logical to not support both.

D already has that advantage supporting pretty much every 
platform you can think of.
Jun 29 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 19:46:06 UTC, bauss wrote:

 On Friday, 29 June 2018 at 19:42:56 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder wrote:

 Once Crystal integrates parallelism (at 1.0), it should 

 etc, because it's actually "Go-made-right". For instance 
 it's genericity system works well, and its type inference 
 system natively support union types.


 Except it has no Windows support and doesn't look like it 
 will happen anytime soon. Some people might be living in a 
 UNIX bubble, but Windows is a big market, and a language 
 won't make it big without Windows support.


 Right :)

 But remember that Crystal is still in its infancy, as it 
 hasn't reached its 1.0 version yet.

 Parallelism is on its way, and Windows support too...

 Don't forget that nowadays many (can I say most ?) servers are 
 based on unix variants, so their platform support order looks 
 perfectly fine and logical to me.


 Actually a large share of servers run Windows Server and/or 
 Azure servers running Windows too.

 It's not logical to not support both.

 D already has that advantage supporting pretty much every 
 platform you can think of.


I agree, but you must compare what is comparable.

Have a look at Crystal's Github project, you will see that 
Crystal, still in development and quite far from its 1.0 mile 
version (= despite no parallism and windows support, etc) ALREADY 
has 11206 stars, 881 forks and 292 contributors :

https://github.com/crystal-lang/crystal

Not bad for a language in its 0.25 version and first released in 
June 2014 (4 years), especially compared to D in its 2.0 version 
and first released in December 2001 (16 years), whose official 
compiler has 1806 stars, 452 forks and 168 contributors :

https://github.com/dlang/dmd

If those numbers means anything, I think its that Crystal is 
probably getting popularity much quicker than D, and honestly, 
after having tried it, I think it's really deserved, even if I 
agree that there are still many things that remain to be 
implemented before it's really ready for an official 
"production-ready" 1.0 release.
Jun 29 2018
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 19:46:06 UTC, bauss wrote:

 On Friday, 29 June 2018 at 19:42:56 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder 
 wrote:

 Once Crystal integrates parallelism (at 1.0), it should 
 become de facto one of the best alternative to Go, Java, 

 instance it's genericity system works well, and its type 
 inference system natively support union types.


 Except it has no Windows support and doesn't look like it 
 will happen anytime soon. Some people might be living in a 
 UNIX bubble, but Windows is a big market, and a language 
 won't make it big without Windows support.


 Right :)

 But remember that Crystal is still in its infancy, as it 
 hasn't reached its 1.0 version yet.

 Parallelism is on its way, and Windows support too...

 Don't forget that nowadays many (can I say most ?) servers 
 are based on unix variants, so their platform support order 
 looks perfectly fine and logical to me.


 Actually a large share of servers run Windows Server and/or 
 Azure servers running Windows too.

 It's not logical to not support both.

 D already has that advantage supporting pretty much every 
 platform you can think of.


 I agree, but you must compare what is comparable.

 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 mile 
 version (= despite no parallism and windows support, etc) 
 ALREADY has 11206 stars, 881 forks and 292 contributors :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first released 
 in June 2014 (4 years), especially compared to D in its 2.0 
 version and first released in December 2001 (16 years), whose 
 official compiler has 1806 stars, 452 forks and 168 
 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and honestly, 
 after having tried it, I think it's really deserved, even if I 
 agree that there are still many things that remain to be 
 implemented before it's really ready for an official 
 "production-ready" 1.0 release.


Yes. Crystal is a fantastic language already.

As someone who uses many languages, I tend to just use what does 
the task at hand best.

I'm sure I'll be able to find some usage for Crystal when it's 
production ready, but it doesn't mean I'll abandon D. That'll 
probably never happen, especially considering I have a lot of 
projects written in D with thousands of lines of code.
Jun 29 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 20:51:56 UTC, bauss wrote:

 On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 19:46:06 UTC, bauss wrote:

 On Friday, 29 June 2018 at 19:42:56 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 17:09:44 UTC, JN wrote:

 On Friday, 29 June 2018 at 08:43:34 UTC, Ecstatic Coder 
 wrote:

 Once Crystal integrates parallelism (at 1.0), it should 
 become de facto one of the best alternative to Go, Java, 

 instance it's genericity system works well, and its type 
 inference system natively support union types.


 Except it has no Windows support and doesn't look like it 
 will happen anytime soon. Some people might be living in a 
 UNIX bubble, but Windows is a big market, and a language 
 won't make it big without Windows support.


 Right :)

 But remember that Crystal is still in its infancy, as it 
 hasn't reached its 1.0 version yet.

 Parallelism is on its way, and Windows support too...

 Don't forget that nowadays many (can I say most ?) servers 
 are based on unix variants, so their platform support order 
 looks perfectly fine and logical to me.


 Actually a large share of servers run Windows Server and/or 
 Azure servers running Windows too.

 It's not logical to not support both.

 D already has that advantage supporting pretty much every 
 platform you can think of.


 I agree, but you must compare what is comparable.

 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 mile 
 version (= despite no parallism and windows support, etc) 
 ALREADY has 11206 stars, 881 forks and 292 contributors :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first released 
 in June 2014 (4 years), especially compared to D in its 2.0 
 version and first released in December 2001 (16 years), whose 
 official compiler has 1806 stars, 452 forks and 168 
 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and honestly, 
 after having tried it, I think it's really deserved, even if I 
 agree that there are still many things that remain to be 
 implemented before it's really ready for an official 
 "production-ready" 1.0 release.


 Yes. Crystal is a fantastic language already.

 As someone who uses many languages, I tend to just use what 
 does the task at hand best.

 I'm sure I'll be able to find some usage for Crystal when it's 
 production ready, but it doesn't mean I'll abandon D. That'll 
 probably never happen, especially considering I have a lot of 
 projects written in D with thousands of lines of code.


Same for me :)
Jun 29 2018
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:


 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 mile 
 version (= despite no parallism and windows support, etc) 
 ALREADY has 11206 stars, 881 forks and 292 contributors :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first released 
 in June 2014 (4 years), especially compared to D in its 2.0 
 version and first released in December 2001 (16 years), whose 
 official compiler has 1806 stars, 452 forks and 168 
 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and honestly, 
 after having tried it, I think it's really deserved, even if I 
 agree that there are still many things that remain to be 
 implemented before it's really ready for an official 
 "production-ready" 1.0 release.


Do you by chance work as a manager? Managers like comparisons 
that involve one number, with a higher number being better. I 
don't know what can be learned about D from that comparison and I 
don't think anyone else does either.
Jun 29 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 22:59:25 UTC, bachmeier wrote:

 On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:


 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 mile 
 version (= despite no parallism and windows support, etc) 
 ALREADY has 11206 stars, 881 forks and 292 contributors :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first released 
 in June 2014 (4 years), especially compared to D in its 2.0 
 version and first released in December 2001 (16 years), whose 
 official compiler has 1806 stars, 452 forks and 168 
 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and honestly, 
 after having tried it, I think it's really deserved, even if I 
 agree that there are still many things that remain to be 
 implemented before it's really ready for an official 
 "production-ready" 1.0 release.


 Do you by chance work as a manager? Managers like comparisons 
 that involve one number, with a higher number being better. I 
 don't know what can be learned about D from that comparison and 
 I don't think anyone else does either.


That's your opinion.

First, most managers don't become manager by chance, but because 
of their skills.

Like being able to take the right decisions, based on facts, not 
on personal preferences.

For instance, if a good manager sees that the github project of a 
4 years old compiler has been liked by 11206 persons, and the 
github project of a 16 years old compiler has been liked by 1806 
persons, I think he could probably think that MUCH more people 
are interested in the development of the first github project 
than in the second.

But if you want to think the opposite, it's perfectly your right, 
I've got not problem with that.
Jun 29 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 22:59:25 UTC, bachmeier wrote:

 On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:


 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 mile 
 version (= despite no parallism and windows support, etc) 
 ALREADY has 11206 stars, 881 forks and 292 contributors :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first released 
 in June 2014 (4 years), especially compared to D in its 2.0 
 version and first released in December 2001 (16 years), whose 
 official compiler has 1806 stars, 452 forks and 168 
 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and 
 honestly, after having tried it, I think it's really 
 deserved, even if I agree that there are still many things 
 that remain to be implemented before it's really ready for an 
 official "production-ready" 1.0 release.


 Do you by chance work as a manager? Managers like comparisons 
 that involve one number, with a higher number being better. I 
 don't know what can be learned about D from that comparison 
 and I don't think anyone else does either.


 That's your opinion.

 First, most managers don't become manager by chance, but 
 because of their skills.

 Like being able to take the right decisions, based on facts, 
 not on personal preferences.

 For instance, if a good manager sees that the github project of 
 a 4 years old compiler has been liked by 11206 persons, and the 
 github project of a 16 years old compiler has been liked by 
 1806 persons, I think he could probably think that MUCH more 
 people are interested in the development of the first github 
 project than in the second.


I'd hope a manager would look at actually meaningful stats like 
downloads, rather than just fluffy stats such as "likes":

http://www.somsubhra.com/github-release-stats/?username=crystal-lang&repository=crystal
http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

I see around 9k total downloads of the various Crystal 0.24 and 
0.25 versions over the last 8 months, compared to 14k downloads 
of the ldc 1.9 compiler alone from two months ago. Of course, all 
these stats can be gamed, but I think it'd be hard to argue 
Crystal is more popular.
Jun 30 2018
next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote:

 On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 22:59:25 UTC, bachmeier wrote:

 On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:


 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 
 mile version (= despite no parallism and windows support, 
 etc) ALREADY has 11206 stars, 881 forks and 292 contributors 
 :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first 
 released in June 2014 (4 years), especially compared to D in 
 its 2.0 version and first released in December 2001 (16 
 years), whose official compiler has 1806 stars, 452 forks 
 and 168 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and 
 honestly, after having tried it, I think it's really 
 deserved, even if I agree that there are still many things 
 that remain to be implemented before it's really ready for 
 an official "production-ready" 1.0 release.


 Do you by chance work as a manager? Managers like comparisons 
 that involve one number, with a higher number being better. I 
 don't know what can be learned about D from that comparison 
 and I don't think anyone else does either.


 That's your opinion.

 First, most managers don't become manager by chance, but 
 because of their skills.

 Like being able to take the right decisions, based on facts, 
 not on personal preferences.

 For instance, if a good manager sees that the github project 
 of a 4 years old compiler has been liked by 11206 persons, and 
 the github project of a 16 years old compiler has been liked 
 by 1806 persons, I think he could probably think that MUCH 
 more people are interested in the development of the first 
 github project than in the second.


 I'd hope a manager would look at actually meaningful stats like 
 downloads, rather than just fluffy stats such as "likes":

 http://www.somsubhra.com/github-release-stats/?username=crystal-lang&repository=crystal
 http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

 I see around 9k total downloads of the various Crystal 0.24 and 
 0.25 versions over the last 8 months, compared to 14k downloads 
 of the ldc 1.9 compiler alone from two months ago. Of course, 
 all these stats can be gamed, but I think it'd be hard to argue 
 Crystal is more popular.


Obviously you haven't read my post.

No problem, I'll repeat it.

I said that Crystal is probably gaining popularity FASTER than D.

I've never said that Crystal is more used than D.

FYI, D is in the top 50 at the TIOBE index, while Crystal is only 
in the top 100.

Of course, you will tell me that these rankings are numbers, and 
that a higher number means nothing. Right ?
Jun 30 2018
parent Joakim <dlang joakim.fea.st> writes:
On Saturday, 30 June 2018 at 07:28:24 UTC, Ecstatic Coder wrote:

 On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote:

 On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder 
 wrote:

 [...]


 I'd hope a manager would look at actually meaningful stats 
 like downloads, rather than just fluffy stats such as "likes":

 http://www.somsubhra.com/github-release-stats/?username=crystal-lang&repository=crystal
 http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

 I see around 9k total downloads of the various Crystal 0.24 
 and 0.25 versions over the last 8 months, compared to 14k 
 downloads of the ldc 1.9 compiler alone from two months ago. 
 Of course, all these stats can be gamed, but I think it'd be 
 hard to argue Crystal is more popular.


 Obviously you haven't read my post.

 No problem, I'll repeat it.

 I said that Crystal is probably gaining popularity FASTER than 
 D.

 I've never said that Crystal is more used than D.

 FYI, D is in the top 50 at the TIOBE index, while Crystal is 
 only in the top 100.

 Of course, you will tell me that these rankings are numbers, 
 and that a higher number means nothing. Right ?


I'll tell you that all data should be carefully vetted before 
using it to draw conclusions. For example, I just checked and the 
ldc data includes a download for every CI run, which skews it 
upwards, but I doubt enough to change my conclusion above:

https://github.com/ldc-developers/ldc/blob/master/.circleci/config.yml#L62
Jun 30 2018
prev sibling next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote:

 On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder wrote:

 On Friday, 29 June 2018 at 22:59:25 UTC, bachmeier wrote:

 On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote:


 Have a look at Crystal's Github project, you will see that 
 Crystal, still in development and quite far from its 1.0 
 mile version (= despite no parallism and windows support, 
 etc) ALREADY has 11206 stars, 881 forks and 292 contributors 
 :

 https://github.com/crystal-lang/crystal

 Not bad for a language in its 0.25 version and first 
 released in June 2014 (4 years), especially compared to D in 
 its 2.0 version and first released in December 2001 (16 
 years), whose official compiler has 1806 stars, 452 forks 
 and 168 contributors :

 https://github.com/dlang/dmd

 If those numbers means anything, I think its that Crystal is 
 probably getting popularity much quicker than D, and 
 honestly, after having tried it, I think it's really 
 deserved, even if I agree that there are still many things 
 that remain to be implemented before it's really ready for 
 an official "production-ready" 1.0 release.


 Do you by chance work as a manager? Managers like comparisons 
 that involve one number, with a higher number being better. I 
 don't know what can be learned about D from that comparison 
 and I don't think anyone else does either.


 That's your opinion.

 First, most managers don't become manager by chance, but 
 because of their skills.

 Like being able to take the right decisions, based on facts, 
 not on personal preferences.

 For instance, if a good manager sees that the github project 
 of a 4 years old compiler has been liked by 11206 persons, and 
 the github project of a 16 years old compiler has been liked 
 by 1806 persons, I think he could probably think that MUCH 
 more people are interested in the development of the first 
 github project than in the second.


 I'd hope a manager would look at actually meaningful stats like 
 downloads, rather than just fluffy stats such as "likes":

 http://www.somsubhra.com/github-release-stats/?username=crystal-lang&repository=crystal
 http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

 I see around 9k total downloads of the various Crystal 0.24 and 
 0.25 versions over the last 8 months, compared to 14k downloads 
 of the ldc 1.9 compiler alone from two months ago. Of course, 
 all these stats can be gamed, but I think it'd be hard to argue 
 Crystal is more popular.


Anyway, I you think that Crystal is not worth our attention, it's 
your right.

But my PERSONAL opinion is that Crystal will soon become a great 
alternative to D, Go and Rust for web server development, while I 
still think that D is BY FAR a much better language than Go or 
Rust.

So now we can try to analyze what make Crystal a useful and 
popular language in this domain and learn lessons from it, or 
simply ignore it.

Very honestly I don't care, because I exclusively use D as a file 
processing scripting language, and I'm very happy with D in its 
current state.

And to be perfectly clear on that point, its current syntax is 
perfect, very simple and concise, and if DON'T want any change 
made to its current syntax which would make it less simple and 
concise when using it in GC mode.
Jun 30 2018
prev sibling parent reply RhyS <sale rhysoft.com> writes:
On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote:

 I'd hope a manager would look at actually meaningful stats like 
 downloads, rather than just fluffy stats such as "likes":

 http://www.somsubhra.com/github-release-stats/?username=crystal-lang&repository=crystal
 http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

 I see around 9k total downloads of the various Crystal 0.24 and 
 0.25 versions over the last 8 months, compared to 14k downloads 
 of the ldc 1.9 compiler alone from two months ago.


Its hard to compare those figure because D and Crystal also use 
package installers on the respectable platforms. Going to the 
crystal download page makes that very clear. Making tracking 
downloads more harder.

D can reach more Git downloads thanks to Windows users that do 
not rely on Linux system packages.

D its buginess in between releases also does not help. I probably 
downloaded LDC and DMD in the last 9 months a dozen times, being 
forced to go back to older versions. Then trying the new 
versions, going back. Again and again on Windows.

Downloads do not mean a lot when you can not keep the people. I 
can swear that i alone am probably responsible for over 25+ 
downloads on Windows and dozens on Linux OS. And every time D 
loses me after running into issues.

Crystal its 0.24 release is still perfectly working here. I 
literally have downloaded 2 version in the last year. 0.23 and 
0.24... That is it. No switching between version because of bugs 
or package issues or dependency issues. Kind of ironic but maybe 
because the http server and other packages are build in to the 
core, i have no need for external 3th party solutions like D's 
Vibe.d.


 Of course, all these stats can be gamed, but I think it'd be 
 hard to argue Crystal is more popular.


code.d
Total 1336 packages found.

crystalshards.xyz
3359 total shards

Track both sites using archive.org and notice that Crystal is 
growing faster in regards to Shards then D its packages.

Duplicates D something like 6 postgresql driver packages. Crystal 
has 2 drivers. So D is actually fluffing its numbers with a lot 
of not maintained duplicates. Mysql ... Its not hard to tell that 
Crystal its Shards community is more active.

Crystal only recently got the funding to get a full time 
employees to work on the code base. So one can expect the 
development to increase from a mostly community driven platform. 
They out gross Nim by almost double on average ( 
salt.bountysource.com ) and that does not include the 2000$ / 
month that "84 codes" directly donates.

I do not know how much D takes in per month. This has always been 
a more obscure, as is who are the people that really are paid 
full time to work on D. Walter?

Crystal needs a lot of work but so does D. You expect D to have 
more its act together for a language this old. No default http 
server in this day and age is just really weak sauce. And Vibe.d 
breaks plenty of times in between its releases and DMD releases.

Both have issues but one is under development for 4 year and the 
other for 16 years. You expect D to simply outclass Crystal and 
other languages. Even Rust is out developing D in many areas, a 
lot thanks to a big community.
Jun 30 2018
next sibling parent Timoses <timosesu gmail.com> writes:
On Sunday, 1 July 2018 at 02:57:26 UTC, RhyS wrote:

 D its buginess in between releases also does not help. I 
 probably downloaded LDC and DMD in the last 9 months a dozen 
 times, being forced to go back to older versions. Then trying 
 the new versions, going back. Again and again on Windows.

 Downloads do not mean a lot when you can not keep the people. I 
 can swear that i alone am probably responsible for over 25+ 
 downloads on Windows and dozens on Linux OS. And every time D 
 loses me after running into issues.


Been there. Just recently found out about DVM 
(https://github.com/jacob-carlborg/dvm). Not sure how well it 
works for Windows.
Jul 01 2018
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 1 July 2018 at 02:57:26 UTC, RhyS wrote:

 On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote:

 I'd hope a manager would look at actually meaningful stats 
 like downloads, rather than just fluffy stats such as "likes":

 http://www.somsubhra.com/github-release-stats/?username=crystal-lang&repository=crystal
 http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc

 I see around 9k total downloads of the various Crystal 0.24 
 and 0.25 versions over the last 8 months, compared to 14k 
 downloads of the ldc 1.9 compiler alone from two months ago.


 Its hard to compare those figure because D and Crystal also use 
 package installers on the respectable platforms. Going to the 
 crystal download page makes that very clear. Making tracking 
 downloads more harder.

 D can reach more Git downloads thanks to Windows users that do 
 not rely on Linux system packages.

 D its buginess in between releases also does not help. I 
 probably downloaded LDC and DMD in the last 9 months a dozen 
 times, being forced to go back to older versions. Then trying 
 the new versions, going back. Again and again on Windows.

 Downloads do not mean a lot when you can not keep the people. I 
 can swear that i alone am probably responsible for over 25+ 
 downloads on Windows and dozens on Linux OS. And every time D 
 loses me after running into issues.

 Crystal its 0.24 release is still perfectly working here. I 
 literally have downloaded 2 version in the last year. 0.23 and 
 0.24... That is it. No switching between version because of 
 bugs or package issues or dependency issues. Kind of ironic but 
 maybe because the http server and other packages are build in 
 to the core, i have no need for external 3th party solutions 
 like D's Vibe.d.


 Of course, all these stats can be gamed, but I think it'd be 
 hard to argue Crystal is more popular.


 code.d
 Total 1336 packages found.

 crystalshards.xyz
 3359 total shards

 Track both sites using archive.org and notice that Crystal is 
 growing faster in regards to Shards then D its packages.

 Duplicates D something like 6 postgresql driver packages. 
 Crystal has 2 drivers. So D is actually fluffing its numbers 
 with a lot of not maintained duplicates. Mysql ... Its not hard 
 to tell that Crystal its Shards community is more active.

 Crystal only recently got the funding to get a full time 
 employees to work on the code base. So one can expect the 
 development to increase from a mostly community driven 
 platform. They out gross Nim by almost double on average ( 
 salt.bountysource.com ) and that does not include the 2000$ / 
 month that "84 codes" directly donates.

 I do not know how much D takes in per month. This has always 
 been a more obscure, as is who are the people that really are 
 paid full time to work on D. Walter?

 Crystal needs a lot of work but so does D. You expect D to have 
 more its act together for a language this old. No default http 
 server in this day and age is just really weak sauce. And 
 Vibe.d breaks plenty of times in between its releases and DMD 
 releases.

 Both have issues but one is under development for 4 year and 
 the other for 16 years. You expect D to simply outclass Crystal 
 and other languages. Even Rust is out developing D in many 
 areas, a lot thanks to a big community.


+1

At the moement, D's default standard library obviously requires a 
garbage collector, and this won't change for a while.

Trying to convince developers to use D instead of C++ is often 
pointless, because most of the time, if you develop something in 


And that reason why they don't use those nice garbage collected 
languages is generally the same reason why they won't use D 
either.

But those who currently use those same garbage collected 

because D's garbage collector won't be probably a problem for 
them either, as they are already using one in production.

So what remains a mystery for me is that the D leadership 

alternative could be much more efficient than marketing D as a 
C/C++ alternative.

Why are they trying to sell D on its weakness, instead of selling 
it on its strength.

The only thing that D needs to compete on the same ground as Go 
and Crystal is to have similar default HTTP-related libraries, 
which don't rely on thirdparty libraries for the reasons you just 
explained...

Add a 10-liner "Hello World" web server example on the main page 
and that's it.

And if they REALLY want to ALSO compete with C++, then I strongly 
suggest to add weak and strong references to the syntax (for 
instance T& and T ), and provide an alternative standard library 
which doesn't require garbage collection at all, like those of 
C++ and Rust.

But I think it's quite obvious that the first option (Go-like) 
clearly requires less time and efforts than the second (C++-like).
Jul 01 2018
parent reply Johannes Loher <johannes.loher fg4f.de> writes:
Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 
 Add a 10-liner "Hello World" web server example on the main page and
 that's it.


There already is one in the examples:


/+ dub.sdl:
name "hello_vibed"
dependency "vibe-d" version="~>0.8.0"
+/
void main()
{
    import vibe.d;
    listenHTTP(":8080", (req, res) {
        res.writeBody("Hello, World: " ~ req.path);
    });
    runApplication();
}
Jul 01 2018
next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 
 Add a 10-liner "Hello World" web server example on the main 
 page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }


Yeah I know, guess who asked for it...

But the last step, which is including such functionality into the 
standard library , will never happen, because nobody here seems 
to see the point of doing this.

I guess those who made that for Go and Crystal probably did it 
wrong.

What a mistake they did, and they don't even know they make a 
mistake, silly them... ;)
Jul 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via Digitalmars-d-announce 
wrote:

 On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 Add a 10-liner "Hello World" web server example on the main
 page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {

     import vibe.d;
     listenHTTP(":8080", (req, res) {

         res.writeBody("Hello, World: " ~ req.path);

     });
     runApplication();

 }


 Yeah I know, guess who asked for it...

 But the last step, which is including such functionality into the
 standard library , will never happen, because nobody here seems
 to see the point of doing this.

 I guess those who made that for Go and Crystal probably did it
 wrong.

 What a mistake they did, and they don't even know they make a
 mistake, silly them... ;)


What should and shouldn't go in the standard library for a language is
something that's up for a lot of debate and is likely to often be a point of
contention. There is no clear right or wrong here. Languages that have had
very sparse standard libraries have done quite well, and languages that have
had kitchen sink libraries have done quite well. There are pros and cons to
both approaches.

- Jonathan M Davis
Jul 01 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:

 On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via 
 Digitalmars-d-announce wrote:

 On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 Add a 10-liner "Hello World" web server example on the main 
 page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {

     import vibe.d;
     listenHTTP(":8080", (req, res) {

         res.writeBody("Hello, World: " ~ req.path);

     });
     runApplication();

 }


 Yeah I know, guess who asked for it...

 But the last step, which is including such functionality into 
 the standard library , will never happen, because nobody here 
 seems to see the point of doing this.

 I guess those who made that for Go and Crystal probably did it 
 wrong.

 What a mistake they did, and they don't even know they make a 
 mistake, silly them... ;)


 What should and shouldn't go in the standard library for a 
 language is something that's up for a lot of debate and is 
 likely to often be a point of contention. There is no clear 
 right or wrong here. Languages that have had very sparse 
 standard libraries have done quite well, and languages that 
 have had kitchen sink libraries have done quite well. There are 
 pros and cons to both approaches.

 - Jonathan M Davis


I agree.

But here I'm just talking of the "public image" of the language.

Languages which integrates HTTP-related components in their 
standard library, and advertize on that (like Crystal for 
instance), obviously apply a different "marketing" strategy than 
languages which have chosen not to do so.

That's all I say...

I personally appreciate that my Go and Crystal code is mostly 
based on standard components which are updated along with the 
language, but I agree that vibe.d can perfectly get the job done 
if you better trust thirdparty libraries for that.
Jul 01 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:

 On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:

 On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via 
 Digitalmars-d-announce wrote:

 On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 Add a 10-liner "Hello World" web server example on the 
 main page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {

     import vibe.d;
     listenHTTP(":8080", (req, res) {

         res.writeBody("Hello, World: " ~ req.path);

     });
     runApplication();

 }


 Yeah I know, guess who asked for it...

 But the last step, which is including such functionality into 
 the standard library , will never happen, because nobody here 
 seems to see the point of doing this.

 I guess those who made that for Go and Crystal probably did 
 it wrong.

 What a mistake they did, and they don't even know they make a 
 mistake, silly them... ;)


 What should and shouldn't go in the standard library for a 
 language is something that's up for a lot of debate and is 
 likely to often be a point of contention. There is no clear 
 right or wrong here. Languages that have had very sparse 
 standard libraries have done quite well, and languages that 
 have had kitchen sink libraries have done quite well. There 
 are pros and cons to both approaches.

 - Jonathan M Davis


 I agree.

 But here I'm just talking of the "public image" of the language.

 Languages which integrates HTTP-related components in their 
 standard library, and advertize on that (like Crystal for 
 instance), obviously apply a different "marketing" strategy 
 than languages which have chosen not to do so.

 That's all I say...


Two points:

- Andrei pushed to include vibe.d but it didn't happen.

"There's no web services framework (by this time many folks know 
of D, but of those a shockingly small fraction has even heard of 
vibe.d). I have strongly argued with Sönke to bundle vibe.d with 
dmd over one year ago, and also in this forum. There wasn't 
enough interest."
https://forum.dlang.org/post/nipb14$ldb$1 digitalmars.com

- As you acknowledge, integration has drawbacks too. I thought 
this was an interesting recent article about how it has now 
hobbled one of the biggest tech companies in the world:

https://stratechery.com/2018/intel-and-the-danger-of-integration/

I don't think the web matters enough these days that it is worth 
bundling, which is why a webassembly port is also not worth it 
for most:

https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/
Jul 01 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 2 July 2018 at 05:20:51 UTC, Joakim wrote:

 On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:

 On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:

 On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via 
 Digitalmars-d-announce wrote:

 On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 Add a 10-liner "Hello World" web server example on the 
 main page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {

     import vibe.d;
     listenHTTP(":8080", (req, res) {

         res.writeBody("Hello, World: " ~ req.path);

     });
     runApplication();

 }


 Yeah I know, guess who asked for it...

 But the last step, which is including such functionality 
 into the standard library , will never happen, because 
 nobody here seems to see the point of doing this.

 I guess those who made that for Go and Crystal probably did 
 it wrong.

 What a mistake they did, and they don't even know they make 
 a mistake, silly them... ;)


 What should and shouldn't go in the standard library for a 
 language is something that's up for a lot of debate and is 
 likely to often be a point of contention. There is no clear 
 right or wrong here. Languages that have had very sparse 
 standard libraries have done quite well, and languages that 
 have had kitchen sink libraries have done quite well. There 
 are pros and cons to both approaches.

 - Jonathan M Davis


 I agree.

 But here I'm just talking of the "public image" of the 
 language.

 Languages which integrates HTTP-related components in their 
 standard library, and advertize on that (like Crystal for 
 instance), obviously apply a different "marketing" strategy 
 than languages which have chosen not to do so.

 That's all I say...


 Two points:

 - Andrei pushed to include vibe.d but it didn't happen.

 "There's no web services framework (by this time many folks 
 know of D, but of those a shockingly small fraction has even 
 heard of vibe.d). I have strongly argued with Sönke to bundle 
 vibe.d with dmd over one year ago, and also in this forum. 
 There wasn't enough interest."
 https://forum.dlang.org/post/nipb14$ldb$1 digitalmars.com

 - As you acknowledge, integration has drawbacks too. I thought 
 this was an interesting recent article about how it has now 
 hobbled one of the biggest tech companies in the world:

 https://stratechery.com/2018/intel-and-the-danger-of-integration/

 I don't think the web matters enough these days that it is 
 worth bundling, which is why a webassembly port is also not 
 worth it for most:

 https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/


Instead of trying to integrate vibe.d, which I don't think would 
be a good idea, personally I'd rather suggest taking the 
opportunity to design the interface of those standard 
HTTP-related components from scratch (listener server, fibers, 
channels, etc), independently from vibe.d and with a minimalistic 
mindset, by taking inspiration mainly from Go, along with Crystal 
and vibe.d, even if the implementation will obviously end up 
being very similar to the one of vibe.d.
Jul 02 2018
prev sibling parent reply RhyS <sale rhysoft.com> writes:
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 
 Add a 10-liner "Hello World" web server example on the main 
 page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }


Its nice when it works.

First: its a hack as nobody will run any production code with the 
shebang include like the example posted. And they will be forced 
set up a dub package. This already confuses people as its two 
standards. Shebang is nice and well if you have Unix experience 
but not so much for Windows users who have no Posix experience.

Crystal or Go where your simply adding a import http and your can 
keep working on that code.

Second: Its a hack and it fails easily. Maybe its dub or whatever 
but i remember trying that example in the past several times and 
had a lot of issues with failures using it. Using the proper dub 
package actually worked better.

So this http example is not exactly prime. Add to this that 
Vibe.d also keeps having issues with D releases. Where DMD breaks 
something (regressions come to mind) and when Vibe.d ( and its 
dependencies ) as a result also break.

I never found D + Vibe.D very reliable or stable. Your almost 
forced to stick to a version of D and never reinstall your 
system. Even setting up a home / work setup with some time 
between can result in issues that eat away hours of your time.

It also does not help that Vibe.D has problems to reach higher 
performance levels.

https://www.techempower.com/benchmarks/#section=test&runid=7dc8ea3a-6db5-41b8-a4d3-c18cfe72182b&hw=ph&test=fortune

Even in my own tests, D+Vibe always lags behind Crystal, Go and 
other languages. That is just shucking resources out of the 
window. Not what you expect for a language this old.
Jul 03 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Tuesday, 3 July 2018 at 07:42:22 UTC, RhyS wrote:

 On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:

 Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:

 
 Add a 10-liner "Hello World" web server example on the main 
 page and that's it.


 There already is one in the examples:


 /+ dub.sdl:
 name "hello_vibed"
 dependency "vibe-d" version="~>0.8.0"
 +/
 void main()
 {
     import vibe.d;
     listenHTTP(":8080", (req, res) {
         res.writeBody("Hello, World: " ~ req.path);
     });
     runApplication();
 }


 Its nice when it works.

 First: its a hack as nobody will run any production code with 
 the shebang include like the example posted. And they will be 
 forced set up a dub package. This already confuses people as 
 its two standards. Shebang is nice and well if you have Unix 
 experience but not so much for Windows users who have no Posix 
 experience.

 Crystal or Go where your simply adding a import http and your 
 can keep working on that code.

 Second: Its a hack and it fails easily. Maybe its dub or 
 whatever but i remember trying that example in the past several 
 times and had a lot of issues with failures using it. Using the 
 proper dub package actually worked better.

 So this http example is not exactly prime. Add to this that 
 Vibe.d also keeps having issues with D releases. Where DMD 
 breaks something (regressions come to mind) and when Vibe.d ( 
 and its dependencies ) as a result also break.

 I never found D + Vibe.D very reliable or stable. Your almost 
 forced to stick to a version of D and never reinstall your 
 system. Even setting up a home / work setup with some time 
 between can result in issues that eat away hours of your time.

 It also does not help that Vibe.D has problems to reach higher 
 performance levels.

 https://www.techempower.com/benchmarks/#section=test&runid=7dc8ea3a-6db5-41b8-a4d3-c18cfe72182b&hw=ph&test=fortune

 Even in my own tests, D+Vibe always lags behind Crystal, Go and 
 other languages. That is just shucking resources out of the 
 window. Not what you expect for a language this old.


+1

It couldn't be said better...
Jul 03 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/29/2018 1:43 AM, Ecstatic Coder wrote:

 Game development is a very special use case, but personally I don't think that 
 many of those who use C++ for close-to-the-metal development should be that
much 
 interested in switching to D, because most of its standard libraries depend on 
 the presence of a GC...


DasBetterC resolves that, though the library issue remains.



 And Rust, despite it has perfect C/C++-like performance


D has perfect C/C++ like performance, if you code it the same way.
Jun 29 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 DasBetterC resolves that, though the library issue remains.


Indeed.

Unfortunately, it's often the standard library which makes the 
difference between a nice language, and a nice useful language.

D is a great language not only because of the many great 
decisions you made when designing the language (UFCS, slice-based 
strings and arrays, etc), but also because of its great standard 
library, which is well designed and very complete.

To be really useful as a C++ alternative, D still needs another 
standard library based on reference counting, instead of garbage 
collection, even if this implies that some class interfaces will 
have to diverge from their GC-based counterpart.

Without that, D will be a bit like a gun without ammunitions for 
many developers.


 And Rust, despite it has perfect C/C++-like performance


 D has perfect C/C++ like performance, if you code it the same 
 way.


+1 :)
Jun 30 2018
prev sibling next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 I never ever (I think) did something provocative, something to 
 finally see:

 - who in the community WANTS D language to succeed?

 - who are just these funny “people” let’s call th this, that 
 are I don’t know “just hang around”

 Because shame is a weapon much like fear (of death esp), pride 
 can be used as weapon but ehm better shame the bastard...

 And so on.

 So - until we all understand that these donations are not 
 because we are begging fir money.

 I will send ~ 10$ each day _specifically_ to see who WANTS D TO 
 SUCCED and WILL NOT BE SHAMED LIKE THAT FOR ONCE!

 It is because it’s (soon) your last chance to invest into the 
 Future.

 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???


And btw, if D could have its standard libraries and language 
features (strings, arrays, maps, slices, etc) also NATIVELY work 
without GC (= NATIVE weak/strong reference counting), IMHO D 
could perfectly be the future of native code, as it could become 
a better alternative to both C++, Rust, Go, etc
Jun 29 2018
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 [snip]


I'm a little confused. You're going to send $10 a day to D 
Foundation because you're upset about people complaining about D?

I have my donation come through my paycheck. Company matches up 
to a certain amount a year. It's like I don't even see it.
Jun 29 2018
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:


 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???


The future of native code will be replacing scripting languages. 
D is really good at that task.

The future of native code will not be one language. I don't know 
why the discussion always turns to that, because it goes against 
the steady increase in the number of good languages that are 
available. Different folks have different preferences, many of us 
use multiple languages, and our preferences change over our 
lifetimes. These days language interoperability is getting so 
good that "choosing a language" is becoming obsolete. If we keep 
reducing the obstacles to using D, the number of users will 
continue to grow.

WRT donating money, isn't it natural to explain what will be done 
with the money? There's been some movement in the direction of 
transparency. I'll only say there's more to be done in that area 
and leave it at that.
Jun 29 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 29 June 2018 at 22:54:34 UTC, bachmeier wrote:

 On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:


 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???


 The future of native code will be replacing scripting 
 languages. D is really good at that task.


This will never happen, doesn't matter how good D is at it, they 
will always be better because they sacrifice performance for ease 
of use.


 The future of native code will not be one language. I don't 
 know why the discussion always turns to that, because it goes 
 against the steady increase in the number of good languages 
 that are available. Different folks have different preferences, 
 many of us use multiple languages, and our preferences change 
 over our lifetimes. These days language interoperability is 
 getting so good that "choosing a language" is becoming 
 obsolete. If we keep reducing the obstacles to using D, the 
 number of users will continue to grow.


Yep, agreed.


 WRT donating money, isn't it natural to explain what will be 
 done with the money? There's been some movement in the 
 direction of transparency. I'll only say there's more to be 
 done in that area and leave it at that.


Let me echo this: transparency has historically been a big 
problem for D.  AFAIK, nobody in the broader community was ever 
told that the D foundation money would be used to fund a bunch of 
Romanian interns, it just happened. In the end, it appears to 
have worked out great, but why would anybody donate without being 
given transparency on where the money was going in the first 
place, when it could have ended badly?

I understand Andrei had connections with that Romanian 
university, but some donor might have had connections with a 
Brazilian or Chinese university that might have worked out even 
better. We'll never explore such connections and alternatives 
without transparency.

The current move to fund some IDE work with Opencollective is 
better in that regard, but with no concrete details on what it 
entails, not significantly better:

https://forum.dlang.org/post/pxwxhhbuburvddnhacgh forum.dlang.org

Anyway, I don't use such IDEs, so not a reason for me to donate 
anyway.

Honestly, Dmitry's posts starting this thread are incoherent, I'm 
not sure what he was trying to say. If he feels D users should be 
donating much more, he and others need to make clear how that 
money will be spent.
Jun 29 2018
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote:

 Honestly, Dmitry's posts


The writing style doesn't match the name.
Jun 29 2018
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote:

 The future of native code will be replacing scripting 
 languages. D is really good at that task.


 This will never happen, doesn't matter how good D is at it, 
 they will always be better because they sacrifice performance 
 for ease of use.


I think it depends on a couple of factors. First, some of us 
prefer static typing, but until a few years ago, the POS known as 
Java was the best available language with static typing. As 
languages like D build up libraries that make it easy to replace 
the functionality of scripting languages, many of us will move. 
Second, scripting languages lose their ease of use advantages 
quickly once performance becomes an issue. As data science and 
web services continue to grow at a fast pace, more programs are 
being written for which performance will eventually be an issue.


 AFAIK, nobody in the broader community was ever told that the D 
 foundation money would be used to fund a bunch of Romanian 
 interns, it just happened.


My understanding is that a lot of that was funded by Andrei (but 
maybe I am wrong) so I have never had a problem with that 
decision. Where it does cause problems is that anyone else, 
myself included, may not be eager to donate for that reason 
because it's not what we feel is going to help with adoption of 
the language. As you mentioned, some work on IDEs is being 
funded, but even then it appears to be one IDE for Windows users. 
That's not relevant to anything I'm doing. It's better if I 
contribute by improving the ecosystem in a way that helps others 
doing the same things.
Jul 02 2018
parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 2 July 2018 at 18:03:25 UTC, bachmeier wrote:

 On Saturday, 30 June 2018 at 03:02:15 UTC, Joakim wrote:

 The future of native code will be replacing scripting 
 languages. D is really good at that task.


 This will never happen, doesn't matter how good D is at it, 
 they will always be better because they sacrifice performance 
 for ease of use.




Generalization


 I think it depends on a couple of factors. First, some of us 
 prefer static typing, but until a few years ago, the POS known 
 as Java was the best available language with static typing. As 
 languages like D build up libraries that make it easy to 
 replace the functionality of scripting languages, many of us 
 will move. Second, scripting languages lose their ease of use 
 advantages quickly once performance becomes an issue. As data 
 science and web services continue to grow at a fast pace, more 
 programs are being written for which performance will 
 eventually be an issue.


JavaScript is the most popular and growing language on earth.


 AFAIK, nobody in the broader community was ever told that the 
 D foundation money would be used to fund a bunch of Romanian 
 interns, it just happened.


 My understanding is that a lot of that was funded by Andrei 
 (but maybe I am wrong) so I have never had a problem with that 
 decision. Where it does cause problems is that anyone else, 
 myself included, may not be eager to donate for that reason 
 because it's not what we feel is going to help with adoption of 
 the language. As you mentioned, some work on IDEs is being 
 funded, but even then it appears to be one IDE for Windows 
 users.


Windows?  It's not an IDE. Its a text editor by Microsoft called 
Visual Studio Code and it's cross platform. The D extension is 
the most capable cross platform option. I use it on Linux an it 
works really well. I wouldn't hesitate to donate money just to 
see it gain further improvements. Its really awesome.

When I see people complaining about lack of D support for code 
editors...I wonder if they make effort to assert their complaints.

If course D cannot be supported on every ide/text editor. Popular 
ones are well supported. Visual Studio and Visual Studio Code 
being the best IMO. However, sublime, vim, and monodevelop have 
good support too.

Maybe they should mention what they're not getting from supported 
IDEs/text editors.


 That's not relevant to anything I'm doing. It's better if I 
 contribute by improving the ecosystem in a way that helps 
 others doing the same things.



D has a very diverse use case so the generalization is moot. For 
example I prefer having the gc manage memory for me...For most of 
the things I do with D...contrary to other opinions.
Jul 02 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 D has a very diverse use case so the generalization is moot. 
 For example I prefer having the gc manage memory for me...For 
 most of the things I do with D...contrary to other opinions.


+1

For most D use cases (including mine, which is file processing), 
D's GC is a blessing, and one of its main advantages over C++, 
IMHO.

And if you want to use D for C++-like use cases where you don't 
want it, this generally leads to having to reinvent the wheel in 
order to avoid unwanted garbage collections. For instance :

https://github.com/gecko0307/dlib/blob/master/dlib/container

That's why I'm personally in favor of D supporting 
reference-counting based memory management directly in its syntax 
(T , etc), and also providing the GC-free standard components 
(strings, slices, maps, etc).

PS : BTW kudos to Timur Gafarov, it's a pity so many D developers 
prefer to start developing their own engines instead of helping 
Tibur finish Dagon to make it a production-ready game engine 
(adding terrain, UI, networking, etc). Very promising work IMHO !

https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/

And having the language help him (native strong/weak references) 
would be nice too :D
Jul 02 2018
parent aberba <karabutaworld gmail.com> writes:
On Tuesday, 3 July 2018 at 06:43:44 UTC, Ecstatic Coder wrote:

 D has a very diverse use case so the generalization is moot. 
 For example I prefer having the gc manage memory for me...For 
 most of the things I do with D...contrary to other opinions.


 +1

 For most D use cases (including mine, which is file 
 processing), D's GC is a blessing, and one of its main 
 advantages over C++, IMHO.

 And if you want to use D for C++-like use cases where you don't 
 want it, this generally leads to having to reinvent the wheel 
 in order to avoid unwanted garbage collections. For instance :

 https://github.com/gecko0307/dlib/blob/master/dlib/container

 That's why I'm personally in favor of D supporting 
 reference-counting based memory management directly in its 
 syntax (T , etc), and also providing the GC-free standard



 PS : BTW kudos to Timur Gafarov, it's a pity so many D 
 developers prefer to start developing their own engines instead 
 of helping Tibur finish Dagon to make it a production-ready 
 game engine (adding terrain, UI, networking, etc). Very 
 promising work IMHO !

 https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/

 And having the language help him (native strong/weak 
 references) would be nice too :D



I waa aware aware of dlib by I never knew about the impressive he 
had done with D, especially the game engine Dagon and physics 
engine dmech. Shows what D can do in a clean way.

Beyond that, he took time to write detailed tutorials for the 
game engine. Its definitely better for others to contribute 
instead of reinventing the wheel. His work is really impressive.

https://github.com/gecko0307/dagon/wiki/Tutorials
Jul 03 2018
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Let me echo this: transparency has historically been a big 
 problem for D.  AFAIK, nobody in the broader community was ever 
 told that the D foundation money would be used to fund a bunch 
 of Romanian interns, it just happened. In the end, it appears 
 to have worked out great, but why would anybody donate without 
 being given transparency on where the money was going in the 
 first place, when it could have ended badly?

 I understand Andrei had connections with that Romanian 
 university, but some donor might have had connections with a 
 Brazilian or Chinese university that might have worked out even 
 better. We'll never explore such connections and alternatives 
 without transparency.

 The current move to fund some IDE work with Opencollective is 
 better in that regard, but with no concrete details on what it 
 entails, not significantly better:

 https://forum.dlang.org/post/pxwxhhbuburvddnhacgh forum.dlang.org

 Anyway, I don't use such IDEs, so not a reason for me to donate 
 anyway.

 Honestly, Dmitry's posts starting this thread are incoherent, 
 I'm not sure what he was trying to say. If he feels D users 
 should be donating much more, he and others need to make clear 
 how that money will be spent.


+1

And maybe it would be a good idea to use a Kickstarter-like 
philosophy to fund D's development with more transparency.

I mean, you should offer a short panel of D enhancement projects, 
with their precise goal, minimum bugdet and investment time limit 
(for instance one year to reach the required budget), plus an 
ordered list of additional developments if the gathered money 
exceeds the initial budget.

People can then invest in the project(s) that interest them the 
most.

If the minimum budget is not reached after the time limit, the 
investors can get their money back, or decide to invest it in 
another project which hasn't expired.

As you guess, in my opinion, two possible fundable projects would 
be :

1. a project to add http-related components to D's standard 
library
2. a project to allow D to be REALLY usable without GC, i.e. add 
weak/strong reference to the language and provide a standard 
library which uses them
Jul 02 2018
parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 3 July 2018 at 05:52:40 UTC, Ecstatic Coder wrote:


 I mean, you should offer a short panel of D enhancement 
 projects, with their precise goal, minimum bugdet and 
 investment time limit (for instance one year to reach the 
 required budget), plus an ordered list of additional 
 developments if the gathered money exceeds the initial budget.

 People can then invest in the project(s) that interest them the 
 most.


That's what we thought we were getting with Open Collective goals 
before we activated it. That was a bit disappointing. Anyway, the 
plan is to have something similar to what you describe. It won't 
be Kickstarter, though. Before activating yet another service, I 
want to look at ways to integrate what we already have. I'll have 
more news on this somewhere down the road.
Jul 02 2018
prev sibling next sibling parent reply punkUser <andrew.lauritzen gmail.com> writes:
I don't normally contribute a lot here but as I've been using a 
fair mix of C/C++, D and Rust lately for a variety of projects 
from game dev to web to services, I have a few thoughts.

Without exhaustively comparing the different pros/cons of the 
languages, the most important thing that makes me pick D for a 
project these days is actually vibe.d. It's the perfect balance 
between letting me expose my low level stuff as a network/web 
service easily while not trying to take over too much of my 
application or conversely get me to manually write async network 
state machines. I'd happily argue that its cooperative fiber 

the level of Go (mostly just because it's not as ubiquitously 
supported in the standard library), I'll still happily take the 
trade-off to use a language closer to C/C++.

Rust's web framework and cooperative fiber story is still just 

which while better than nothing, isn't quite as nice as vibe.d 
where any function can effectively be part of a cooperative fiber 
without the need for infectious markup everywhere. Rust's syntax 
is also a fair bit different than C/C++ which makes it harder to 
collaborate with people for the moment, while D's is close enough 
that anyone with a decent amount of C/C++ experience can jump in 
pretty quickly.

In terms of what makes me *not* want to use D, while GC is 
certainly a factor in some uses, in more cases it's actually that 
I want more language and compiler stability. While things have 
calmed down somewhat in the past year the number of times a D 
update has broken code (mine or code in a dependency) and left me 
trying to debug someone else's code deep in a library somewhere 
when I'm trying to just do a small update has been far too high. 
Rust's "stable" branch and their new epochs model (where the 
language can change every few years but critically dependencies 
using different epochs work together) is something I would love 
to be adopted in D.

In any case I just wanted to give the feedback that from my point 
of view the main thing that keeps me coming back to it for new 
projects is vibe.d. Thus I'm in favor of making vibe.d a big part 
of the selling point and design considerations for D going 
forward.
Jun 30 2018
next sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Saturday, 30 June 2018 at 12:59:02 UTC, punkUser wrote:

 I don't normally contribute a lot here but as I've been using a 
 fair mix of C/C++, D and Rust lately for a variety of projects 
 from game dev to web to services, I have a few thoughts.

 Without exhaustively comparing the different pros/cons of the 
 languages, the most important thing that makes me pick D for a 
 project these days is actually vibe.d. It's the perfect balance 
 between letting me expose my low level stuff as a network/web 
 service easily while not trying to take over too much of my 
 application or conversely get me to manually write async 
 network state machines. I'd happily argue that its cooperative 

 quite to the level of Go (mostly just because it's not as 
 ubiquitously supported in the standard library), I'll still 
 happily take the trade-off to use a language closer to C/C++.

 Rust's web framework and cooperative fiber story is still just 

 which while better than nothing, isn't quite as nice as vibe.d 
 where any function can effectively be part of a cooperative 
 fiber without the need for infectious markup everywhere. Rust's 
 syntax is also a fair bit different than C/C++ which makes it 
 harder to collaborate with people for the moment, while D's is 
 close enough that anyone with a decent amount of C/C++ 
 experience can jump in pretty quickly.

 In terms of what makes me *not* want to use D, while GC is 
 certainly a factor in some uses, in more cases it's actually 
 that I want more language and compiler stability. While things 
 have calmed down somewhat in the past year the number of times 
 a D update has broken code (mine or code in a dependency) and 
 left me trying to debug someone else's code deep in a library 
 somewhere when I'm trying to just do a small update has been 
 far too high. Rust's "stable" branch and their new epochs model 
 (where the language can change every few years but critically 
 dependencies using different epochs work together) is something 
 I would love to be adopted in D.

 In any case I just wanted to give the feedback that from my 
 point of view the main thing that keeps me coming back to it 
 for new projects is vibe.d. Thus I'm in favor of making vibe.d 
 a big part of the selling point and design considerations for D 
 going forward.


Already tried. Good luck with that... ;)
Jun 30 2018
parent punkUser <andrew.lauritzen gmail.com> writes:
On Saturday, 30 June 2018 at 21:15:09 UTC, Ecstatic Coder wrote:

 Already tried. Good luck with that... ;)


Well to be clear I'm more providing the feedback out courtesy and 
thanks for the work people have done on D and vibe.d in 
particular. While I'd love to see D succeed in the long run, 
we're blessed with enough options these days that it's not a huge 
deal to me either way.

Thanks for the link to Diamond, I'll check it out. That said, the 
majority of my use cases are exposing lower level D code as 
network accessible services and occasionally implementing custom 
network protocols rather than writing full client web apps in D, 
but always good to keep various options in mind.
Jul 01 2018
prev sibling parent Bauss <jj_1337 live.dk> writes:
On Saturday, 30 June 2018 at 12:59:02 UTC, punkUser wrote:

 I don't normally contribute a lot here but as I've been using a 
 fair mix of C/C++, D and Rust lately for a variety of projects 
 from game dev to web to services, I have a few thoughts.

 Without exhaustively comparing the different pros/cons of the 
 languages, the most important thing that makes me pick D for a 
 project these days is actually vibe.d. It's the perfect balance 
 between letting me expose my low level stuff as a network/web 
 service easily while not trying to take over too much of my 
 application or conversely get me to manually write async 
 network state machines. I'd happily argue that its cooperative 

 quite to the level of Go (mostly just because it's not as 
 ubiquitously supported in the standard library), I'll still 
 happily take the trade-off to use a language closer to C/C++.

 Rust's web framework and cooperative fiber story is still just 

 which while better than nothing, isn't quite as nice as vibe.d 
 where any function can effectively be part of a cooperative 
 fiber without the need for infectious markup everywhere. Rust's 
 syntax is also a fair bit different than C/C++ which makes it 
 harder to collaborate with people for the moment, while D's is 
 close enough that anyone with a decent amount of C/C++ 
 experience can jump in pretty quickly.

 In terms of what makes me *not* want to use D, while GC is 
 certainly a factor in some uses, in more cases it's actually 
 that I want more language and compiler stability. While things 
 have calmed down somewhat in the past year the number of times 
 a D update has broken code (mine or code in a dependency) and 
 left me trying to debug someone else's code deep in a library 
 somewhere when I'm trying to just do a small update has been 
 far too high. Rust's "stable" branch and their new epochs model 
 (where the language can change every few years but critically 
 dependencies using different epochs work together) is something 
 I would love to be adopted in D.

 In any case I just wanted to give the feedback that from my 
 point of view the main thing that keeps me coming back to it 
 for new projects is vibe.d. Thus I'm in favor of making vibe.d 
 a big part of the selling point and design considerations for D 
 going forward.


Not to brag and what not, but if you're going straight for web 
and not anything else then use Diamond, because it gives you so 
much more than vibe.d alone does, but at the same time allows you 
to utilize vibe.d to its full extend.
Jun 30 2018
prev sibling next sibling parent Gheorghe Gabriel <knoppy273 live.com> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???


Thank you very much for mentioning about the Crystal programming 
language. I din't know there is a Crystal lang so I changed my 
project name from Crystal to Liberty, 2 days ago so people don't 
get confuzed.
Jul 01 2018
prev sibling next sibling parent reply Chris M. <chrismohrfeld comcast.net> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 I never ever (I think) did something provocative, something to 
 finally see:

 - who in the community WANTS D language to succeed?

 - who are just these funny “people” let’s call th this, that 
 are I don’t know “just hang around”

 Because shame is a weapon much like fear (of death esp), pride 
 can be used as weapon but ehm better shame the bastard...

 And so on.

 So - until we all understand that these donations are not 
 because we are begging fir money.

 I will send ~ 10$ each day _specifically_ to see who WANTS D TO 
 SUCCED and WILL NOT BE SHAMED LIKE THAT FOR ONCE!

 It is because it’s (soon) your last chance to invest into the 
 Future.

 P.S. I mean what you think the future of native code is??? 
 Rust? Crystal?? Nim???


Throw everything we can this dude's way so we can make D the most 
powerful we can

We need pattern matching, we need typeclasses, we need HKT's, we 
need linear types, we need  nogc Phobos, we need concurrency so 
fearless I can change any variable and not give two shits
Jul 03 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Throw everything we can this dude's way so we can make D the 
 most powerful we can

 We need pattern matching, we need typeclasses, we need HKT's, 
 we need linear types, we need  nogc Phobos, we need concurrency 
 so fearless I can change any variable and not give two shits


Personally I don't really NEED pattern matching, typeclasses, etc

That would be nice, but personally that wouldn't prevent me from 
getting the job done.

But indeed, being able use D in a GC-free environment (like C++ 
and Rust do) would be something many people may NEED, for 
instance to be able to EASILY use D for soft-realtime 
applications like games.

So being able to add a "-nogc" flag to the DMD compiler and use a 
minimal Phobos-like library (strings, arrays, lists, maps and 
other collections, file system functions, etc) which use 
EXCLUSIVELY reference counted memory block accessed through 
strong/weak references and pointers (T , T&, T*) would be nice.

Not an implementation like the one in the standard library of 
C++, which is maybe safe but not especially efficient or user 
friendly, but preferably something closer to this :

https://github.com/senselogic/BASE/tree/master/CODE/COUNTED

And being able to DIRECTLY use D with REAL Go-like ease of use 
and performance (http components, fibers and channels using both 
concurrency and parallelism) to implement web frameworks and 
online services is also something many people may NEED.
Jul 04 2018
parent reply wjoe <none example.com> writes:
On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote:

 But indeed, being able use D in a GC-free environment (like C++ 
 and Rust do) would be something many people may NEED, for 
 instance to be able to EASILY use D for soft-realtime 
 applications like games.


This has to be the no. 1 excuse.


Why is C++ the language of choice currently? My bet is 
productivity and economic concerns. Amongst other things the 
productivity gain from resource management via constructor and 
destructor. Which solves like 75% of the headaches of manual 
resource management and goto nightmares.

Back in the day when C was used to make games, the excuse not to 
use C++ was vtable, exception and RTTI overhead. Now it's called 
the bare metal best performance language which everything and 
their grandma is measured against. This C++ overhead didn't make 
C any slower or C++ any faster than C but it made C++ superior in 
productivity.

This was around 2002/03, and C++, at the time, some 23+ years old.

Games have been made with GC'd languages, 3D games, even. And 
successfully, too.
Minecraft, a very successful one, comes to mind, which is or at 
least was made in Java.


My bet, again, would be productivity and economic concerns. The 
countless hours wasted on debugging memory leaks and cyclic 
dependencies are better spent making the actual game/software.
And smart pointers introduce overhead of their own which makes 
them inferior to C's bare metal raw pointer performance - or GC'd 
pointers for that matter. The culprit being the collection cycle.

The best thing about this whole argument, however, is the claim 
for GC no can do and with the next breath they pull LUA into 
their games. A scripting language that brings a VM, GC and 
extraordinarily inflated loading times when the scripts are 
compiled to byte code at the end user's PC which make C64 loading 
times shine.
The reasoning probably being productivity again and C++'s lunch 
break compile times.

Using the D compiler as a library, instead of LUA, D code could 
be used for 'scripting', as well, and compiled to native machine 
code. In a snap.

I have no metrics between any AAA game engine and their port to D 
but I do know that I wrote a sound/music player library in Java, 
which folks like you claim impossible because GC, never bothered 
with GC and had no performance issues whatsoever - and I don't 
expect any porting it to D.

And there is EASTL. A STL made by Electronic Arts. Because the 
standard implementation shipped with the compiler is too slow ? 
Even though written by C++ wizards ?


Slow code is slow and allocating memory in a tight loop is a huge 
performance killer - regardless of language.

Also, why do you feel like a GC is inacceptable for games but 
doesn't matter for your file handling program? Handling dozens, 
maybe thousands, of files sounds like an awful lot of memory 
management involved and whether a e.g. grep takes 15 seconds to 
do it's job or under 1 matters not?

Nothing forces anyone to use the GC, memory can be managed 
manually via malloc/free and you get to do it with scope 
statements/nested functions which makes it nicer than in C. You 
could also implement shared/weak ptr stuff in D - warts and all.
If you need a GC free standard library, I believe there is an 
ongoing effort -or several- at code.dlang.org and probably other 
places.


You said do this and that, GC, etc. to motivate C++ folks to come 
to D. I say it's an excuse not to use D and no matter the effort 
of advertising, a GC free phobos, etc. on part of the D-Lang 
Foundation and contributors would make these folks switch. They 
would simply find a different excuse.

And where's the usefulness of toy examples like 2 line web 
servers which essentially do nothing?
And how is that helping with getting attention from the game devs 
?
Putting on the front page a 12 line maze game which can be 
imported from the standard library? Not using the GC?
Jul 04 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 04, 2018 at 06:05:15PM +0000, wjoe via Digitalmars-d-announce wrote:

 On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote:

 But indeed, being able use D in a GC-free environment (like C++ and
 Rust do) would be something many people may NEED, for instance to be
 able to EASILY use D for soft-realtime applications like games.


 
 This has to be the no. 1 excuse.


+1.  It's typical GC-phobia that is mostly subjective and only tenously
backed by real evidence.


[...]

 The best thing about this whole argument, however, is the claim for GC
 no can do and with the next breath they pull LUA into their games. A
 scripting language that brings a VM, GC and extraordinarily inflated
 loading times when the scripts are compiled to byte code at the end
 user's PC which make C64 loading times shine.


Spot on!


[...]

 You said do this and that, GC, etc. to motivate C++ folks to come to
 D. I say it's an excuse not to use D and no matter the effort of
 advertising, a GC free phobos, etc. on part of the D-Lang Foundation
 and contributors would make these folks switch. They would simply find
 a different excuse.


[...]

Exactly.  As Walter has said before, (and I paraphrase,) it's far more
profitable to cater to *existing* customers who are already using your
product, to make their experience better, than to bend over backwards to
satisfy the critical crowd who points at issue X and claim that they
would not use D because of X.  But X is not the *real* reason they don't
want to use D; it's just an excuse.  Once you solve problem X, they will
find issue Y and say *that* is the reason they're still not using D.
And if you solve Y, they will find issue Z.  It never ends, and you're
wasting your efforts on non-customers who will *never* become customers.
Why bother?  Far better to improve things for existing customers (who
may then get you new customers by word-of-mouth of their success stories
-- *eager* new customers who aren't just looking for the next excuse not
to use D).


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying
Jul 04 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Exactly.  As Walter has said before, (and I paraphrase,) it's 
 far more profitable to cater to *existing* customers who are 
 already using your product, to make their experience better, 
 than to bend over backwards to satisfy the critical crowd who 
 points at issue X and claim that they would not use D because 
 of X.  But X is not the *real* reason they don't want to use D; 
 it's just an excuse.  Once you solve problem X, they will find 
 issue Y and say *that* is the reason they're still not using D. 
 And if you solve Y, they will find issue Z.  It never ends, and 
 you're wasting your efforts on non-customers who will *never* 
 become customers. Why bother?  Far better to improve things for 
 existing customers (who may then get you new customers by 
 word-of-mouth of their success stories -- *eager* new customers 
 who aren't just looking for the next excuse not to use D).


+1

For instance, to be a perfect C++ alternative, D would probably 
need to be 100% :
1. usable (strings, slices, etc) without GC
2. interoperable with any existing C++ library

For for game development :
3. compilable on all game development platforms 
(Win/Mac/Linux/Android/iOS/Switch/PS4/etc)

I don't know if this can be achieved, or if this is really worth 
the effort.
Jul 04 2018
parent JN <666total wp.pl> writes:
On Wednesday, 4 July 2018 at 19:49:00 UTC, Ecstatic Coder wrote:

 For instance, to be a perfect C++ alternative, D would probably 
 need to be 100% :
 1. usable (strings, slices, etc) without GC
 2. interoperable with any existing C++ library

 For for game development :
 3. compilable on all game development platforms 
 (Win/Mac/Linux/Android/iOS/Switch/PS4/etc)

 I don't know if this can be achieved, or if this is really 
 worth the effort.


I think it isn't. Language is only a small part of the equation 
nowadays. The ecosystem is more important. If you made strings, 
slices etc. usable without GC, you'd probably make it 
incompatible with 90% of the existing code. The ecosystem would 
be split into "no GC" and "GC" libraries. And then you'd have the 
"C++ folks" complaining about how it's hard to tell what is 
supported, what isn't.

If you aren't decisive, you open yourself to others doubting you. 

about it? For the most part no, they just learned to deal with it 
and other language features make it worth it for them. These 
languages don't really consider adding advanced manual memory 
management options to lure in "C++ folks". Neither Unity is 
rewriting their engine in Rust as of this moment.
Jul 04 2018
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote:

 On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote:

 But indeed, being able use D in a GC-free environment (like 
 C++ and Rust do) would be something many people may NEED, for 
 instance to be able to EASILY use D for soft-realtime 
 applications like games.


 This has to be the no. 1 excuse.


 Why is C++ the language of choice currently? My bet is 
 productivity and economic concerns. Amongst other things the 
 productivity gain from resource management via constructor and 
 destructor. Which solves like 75% of the headaches of manual 
 resource management and goto nightmares.

 Back in the day when C was used to make games, the excuse not 
 to use C++ was vtable, exception and RTTI overhead. Now it's 
 called the bare metal best performance language which 
 everything and their grandma is measured against. This C++ 
 overhead didn't make C any slower or C++ any faster than C but 
 it made C++ superior in productivity.

 This was around 2002/03, and C++, at the time, some 23+ years 
 old.

 Games have been made with GC'd languages, 3D games, even. And 
 successfully, too.
 Minecraft, a very successful one, comes to mind, which is or at 
 least was made in Java.


 My bet, again, would be productivity and economic concerns. The 
 countless hours wasted on debugging memory leaks and cyclic 
 dependencies are better spent making the actual game/software.
 And smart pointers introduce overhead of their own which makes 
 them inferior to C's bare metal raw pointer performance - or 
 GC'd pointers for that matter. The culprit being the collection 
 cycle.

 The best thing about this whole argument, however, is the claim 
 for GC no can do and with the next breath they pull LUA into 
 their games. A scripting language that brings a VM, GC and 
 extraordinarily inflated loading times when the scripts are 
 compiled to byte code at the end user's PC which make C64 
 loading times shine.
 The reasoning probably being productivity again and C++'s lunch 
 break compile times.

 Using the D compiler as a library, instead of LUA, D code could 
 be used for 'scripting', as well, and compiled to native 
 machine code. In a snap.

 I have no metrics between any AAA game engine and their port to 
 D but I do know that I wrote a sound/music player library in 
 Java, which folks like you claim impossible because GC, never 
 bothered with GC and had no performance issues whatsoever - and 
 I don't expect any porting it to D.

 And there is EASTL. A STL made by Electronic Arts. Because the 
 standard implementation shipped with the compiler is too slow ? 
 Even though written by C++ wizards ?


 Slow code is slow and allocating memory in a tight loop is a 
 huge performance killer - regardless of language.

 Also, why do you feel like a GC is inacceptable for games but 
 doesn't matter for your file handling program? Handling dozens, 
 maybe thousands, of files sounds like an awful lot of memory 
 management involved and whether a e.g. grep takes 15 seconds to 
 do it's job or under 1 matters not?

 Nothing forces anyone to use the GC, memory can be managed 
 manually via malloc/free and you get to do it with scope 
 statements/nested functions which makes it nicer than in C. You 
 could also implement shared/weak ptr stuff in D - warts and all.
 If you need a GC free standard library, I believe there is an 
 ongoing effort -or several- at code.dlang.org and probably 
 other places.


 You said do this and that, GC, etc. to motivate C++ folks to 
 come to D. I say it's an excuse not to use D and no matter the 
 effort of advertising, a GC free phobos, etc. on part of the 
 D-Lang Foundation and contributors would make these folks 
 switch. They would simply find a different excuse.

 And where's the usefulness of toy examples like 2 line web 
 servers which essentially do nothing?
 And how is that helping with getting attention from the game 
 devs ?
 Putting on the front page a 12 line maze game which can be 
 imported from the standard library? Not using the GC?


First, to be clear, I mainly use D as a scripting language for 
file processing, and for this use case, having a GC is a blessing.

You say that garbage collection is not a real problem for game 
development.

Maybe, but that's not my experience. For instance, have you read 
Unity's own official recommandations on how to overcome this 
problem ?

And obviously, Tibur, a highly skilled D game engine developer, 
is not a big fan of D's non incremental garbage collector, from 
the number of  nogc he has put in his Dlib container code.

Maybe you disagree with us because you are a professional game 
developer who has already released a successful commercial game 
in D without caring for the garbage collection. If it's the case, 
then nice, I'd be happy to have it wrong on this :)

And about developing video games in C++, actually most studios 
use orthodox C++. This means no exceptions, no RTTI, few virtual 
methods, fast lightweight smart pointers and collections, etc.

Of course it's perfectly your right to develop your games without 
caring for all these performance "details". But other people do.

And about the scripting language, it's not my fault if some game 
engine developers don't care for the performance or GC issues 
when adding a scripting language to their game engine.

But obviously, some of us (including me) care for that when 
implementing or using a scripting language.

So, as I said, those who use C++ or Rust because D's GC is a 
problem for them, won't probably use D in its current state.

But I'm personally convinced that D could be much more successful 
if it was enhanced to be marketed as a true Go-like language than 
if it was enhanced to be marketed as a true C++-like language, 
for the reasons I've already explained, so I don't think that D's 
GC is really a problem from that point of view...
Jul 04 2018
next sibling parent reply wjoe <none example.com> writes:
On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote:

 First, to be clear, I mainly use D as a scripting language for 
 file processing, and for this use case, having a GC is a 
 blessing.


This is a non issue and a GC doesn't matter at all in this case. 
You could allocate all you wanted and never free and as long as 
there's enough memory to finish the script you couldn't tell the 
difference. Once a script or program is done the OS reclaims all 
memory.

But memory leaks in software, running in some kind of main loop, 
become real performance bottlenecks eventually and a time sink to 
debug.


 You say that garbage collection is not a real problem for game 
 development.


No, what I'm saying is that I've hadn't had any issues with the 
GC so far and that I don't expect any.
I'm also saying that I keep hearing this argument against using D 
but it was never backed up by anthing substantial so it sounds 
like an excuse by folks who never really considered D in the 
first place.

Like, what does it matter if a collection cycle is triggered 
during a loading screen ?
Performance aware C++ folks do have to do resource management at 
some point, too, and that's not free either and is usually done 
while the loading screen is displayed.


 For instance, have you read Unity's own official 
 recommandations on how to overcome this problem ?


No, I haven't.
It probably boils down to pre-allocation, object pools, reusing 
objects, don't allocate in a loop, caching data, be mindful of 
what you do and when and how, etc, etc.

Which would be good advice for game development in general and 
I'd do exactly that in C/C++, or any non-GC'd language, too.



 And about developing video games in C++, actually most studios 
 use orthodox C++. This means no exceptions, no RTTI, few 
 virtual methods, fast lightweight smart pointers and 
 collections, etc.


They could get that with -betterC which also does not use a GC.



 And about the scripting language, it's not my fault if some 
 game engine developers don't care for the performance or GC 
 issues when adding a scripting language to their game engine.


Never said it was your fault, just pointed out the fact that it's 
a very common occurance.


 So, as I said, those who use C++ or Rust because D's GC is a 
 problem for them, won't probably use D in its current state.


Or any other language tagged GC for that matter, except maybe LUA.

Nobody and nothing forces anyone to use the GC or features which 
use it. Just go ahead and  manage your memory manually. They will 
not be using features like dynamic arrays, the standard library, 
and such but that's not a loss since they'd roll their own, more 
performant implementations, anyways.

But I'm convinced that they wouldn't consider D - even if there 
was a GC-free Phobos.
They would find the next excuse.

Those who are willing find solutions, those who are not find 
excuses.
Jul 05 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Nobody and nothing forces anyone to use the GC or features 
 which use it. Just go ahead and  manage your memory manually. 
 They will not be using features like dynamic arrays, the 
 standard library, and such but that's not a loss since they'd 
 roll their own, more performant implementations, anyways.


That's my main problem with this approach actually.

This makes D much less interesting to use, while it creates 
several other problems hard to tackle, like C++ interoperability, 
compilation on the target platform, etc.

Probably not worth the effort in many cases...

That's also why there aren't that many commercial games developed 
in Rust too.
Jul 05 2018
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote:

 On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote:

 On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder 
 wrote:

 But indeed, being able use D in a GC-free environment (like 
 C++ and Rust do) would be something many people may NEED, for 
 instance to be able to EASILY use D for soft-realtime 
 applications like games.


 This has to be the no. 1 excuse.


 

 Games have been made with GC'd languages, 3D games, even. And 
 successfully, too.
 Minecraft, a very successful one, comes to mind, which is or 
 at least was made in Java.





+1

 Slow code is slow and allocating memory in a tight loop is a 
 huge performance killer - regardless of language.




+1


 Nothing forces anyone to use the GC, memory can be managed 
 manually via malloc/free and you get to do it with scope 
 statements/nested functions which makes it nicer than in C. 
 You could also implement shared/weak ptr stuff in D - warts 
 and all.




That's what Timur said.


 If you need a GC free standard library, I believe there is an 
 ongoing effort -or several- at code.dlang.org and probably 
 other places.

 You said do this and that, GC, etc. to motivate C++ folks to 
 come to D. I say it's an excuse not to use D and no matter the 
 effort of advertising, a GC free phobos, etc. on part of the 
 D-Lang Foundation and contributors would make these folks 
 switch. They would simply find a different excuse.





 You say that garbage collection is not a real problem for game 
 development.

 Maybe, but that's not my experience. For instance, have you 
 read Unity's own official recommandations on how to overcome 
 this problem ?

 And obviously, Tibur, a highly skilled D game engine developer, 
 is not a big fan of D's non incremental garbage collector, from 
 the number of  nogc he has put in his Dlib container code.


He has written no-GC libs for sure but he said in a blog post 
about his projects that he has no problem with GC. As long as you 
do not use it in critical areas.


 Modern D is a very attractive choice as a language for game 
 development. Even the garbage collector is not a problem, 
 because you can use object pools, custom allocators, or simply 
 malloc and free. The key point is to know when the GC is 
 invoked and try to avoid those cases in performance critical 
 code. Personally, I prefer using malloc so that I can free the 
 memory when I want, since delete has been deprecated and 
 destroy  just releases all the references to an object instance 
 without actually deleting it. Using manual memory management 
 imposes some restrictions on the code–for example, you can’t 
 use closures or D’s built-in containers–but that, again, is not 
 a big problem. A large effort is currently underway to lessen 
 GC usage in dlib, so that you can use it to write fully 
 unmanaged applications with ease. It has GC-free containers, 
 file I/O streams, image decoders, and so on.


https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/

Remember he's into real-time stuff.


 As an indie game developer with a strong bias toward graphics 
 engines and rendering tech, I always try to keep track of 
 modern compiled languages effective enough for writing 
 real-time stuff. The most obvious choice in this field is C++, 
 and I actually used it for several years until I found D in 
 2010. I immediately fell in love with the language’s clean, 
 beautiful syntax, its powerful template system, the numerous 
 built-in features absent in C++, and the rich and easy to use 
 standard library.



 Maybe you disagree with us because you are a professional game 
 developer who has already released a successful commercial game 
 in D without caring for the garbage collection. If it's the 
 case, then nice, I'd be happy to have it wrong on this :)


Read the blog post, you're wrong.


 Of course it's perfectly your right to develop your games 
 without caring for all these performance "details". But other 
 people do.


GC in not a performance bottle neck if you truly know what you're 
doing.


 So, as I said, those who use C++ or Rust because D's GC is a 
 problem for them, won't probably use D in its current state.


If D had X people. Not customers.
Jul 05 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
LOL

Ok, if I'm wrong, then this means D is already a perfect 
replacement to C++, especially for game development.

Just by curiosity, can you tell me how many successful commercial 
games based on a D game engine are released each year ?

Or just this year maybe...
Jul 06 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 LOL

 Ok, if I'm wrong, then this means D is already a perfect 
 replacement to C++, especially for game development.

 Just by curiosity, can you tell me how many successful 
 commercial games based on a D game engine are released each 
 year ?

 Or just this year maybe...


No triple AAA engine is going to switch to D for the following 
reasons:
1.)Cost vs benefit from converting C++ to D.
2.)Gamers do not care how things are implemented, they want 
results.
3.)There are high abundance of c++ programmers for employees to 
hired. I can't say the same thing for D.
4.)GC phobia.(The notorious culprit)


-Alex
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 LOL

 Ok, if I'm wrong, then this means D is already a perfect 
 replacement to C++, especially for game development.

 Just by curiosity, can you tell me how many successful 
 commercial games based on a D game engine are released each 
 year ?

 Or just this year maybe...


 No triple AAA engine is going to switch to D for the following 
 reasons:
 1.)Cost vs benefit from converting C++ to D.
 2.)Gamers do not care how things are implemented, they want 
 results.
 3.)There are high abundance of c++ programmers for employees to 
 hired. I can't say the same thing for D.
 4.)GC phobia.(The notorious culprit)


 -Alex


+1

Just one silly question.

Can the following "naive" D code trigger a garbage collection 
stall ?

score.Text = point_count.to!string() ~ " POINTS";

And what about the same code in C++ ?

Now guess why there is such a "phobia"...
Jul 06 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 07/07/2018 2:11 AM, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 LOL

 Ok, if I'm wrong, then this means D is already a perfect replacement 
 to C++, especially for game development.

 Just by curiosity, can you tell me how many successful commercial 
 games based on a D game engine are released each year ?

 Or just this year maybe...


 No triple AAA engine is going to switch to D for the following reasons:
 1.)Cost vs benefit from converting C++ to D.
 2.)Gamers do not care how things are implemented, they want results.
 3.)There are high abundance of c++ programmers for employees to hired. 
 I can't say the same thing for D.
 4.)GC phobia.(The notorious culprit)


 -Alex


 
 +1
 
 Just one silly question.
 
 Can the following "naive" D code trigger a garbage collection stall ?
 
 score.Text = point_count.to!string() ~ " POINTS";


If the GC has been disabled (which any sane performance caring 
application should do) no.
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 14:14:27 UTC, rikki cattermole wrote:

 On 07/07/2018 2:11 AM, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 LOL

 Ok, if I'm wrong, then this means D is already a perfect 
 replacement to C++, especially for game development.

 Just by curiosity, can you tell me how many successful 
 commercial games based on a D game engine are released each 
 year ?

 Or just this year maybe...


 No triple AAA engine is going to switch to D for the 
 following reasons:
 1.)Cost vs benefit from converting C++ to D.
 2.)Gamers do not care how things are implemented, they want 
 results.
 3.)There are high abundance of c++ programmers for employees 
 to hired. I can't say the same thing for D.
 4.)GC phobia.(The notorious culprit)


 -Alex


 
 +1
 
 Just one silly question.
 
 Can the following "naive" D code trigger a garbage collection 
 stall ?
 
 score.Text = point_count.to!string() ~ " POINTS";


 If the GC has been disabled (which any sane performance caring 
 application should do) no.


Yeah, I know, I'm not silly.

I meant, "if you use standard D code in a game (i.e. with GC 
enabled), the game may stole, but if you use standard C++ code in 
a game, the game may be a bit less performant".

In C++ you don't have to disable anything, and you can still use 
the standard C++ library to make your game if you want to.

With D, I CAN'T use the language and its standard library as 
usual, just because of the GC "phobia".


perfect to me, as much as "standard" C++ is nice to me.

That's my point.
Jul 06 2018
parent H. S. Teoh <hsteoh quickfur.ath.cx> writes:
On Friday, 6 July 2018 at 16:10:04 UTC, Ecstatic Coder wrote:
[...]

 With D, I CAN'T use the language and its standard library as 
 usual, just because of the GC "phobia".


 perfect to me, as much as "standard" C++ is nice to me.

 That's my point.


Uhm... have you actually *tried* to do this in D?

I have a project where, for various reasons, I need to control 
exactly when the GC runs a collection cycle.  The code is not 
 nogc; in fact there are array allocations and AA allocations all 
over the place. And it's idiomatic D code with heavy Phobos use. 
But all I need to do is:

import core.memory;
GC.disable();
... // tons of code, including allocating code, Phobos calls, etc.
if (okToCollect)
    GC.collect();
... // more allocating code
GC.enable();

No collection cycles will run in the code marked "...", because 
the GC has been disabled. That means you can happily allocate 
stuff away and there will NOT be any GC stop-the-world pauses.  
Of course, I don't want memory to leak away freely either, so at 
strategic points in the code, I call GC.collect() to clean up. 
IOW, I can predict, and *control*, when exactly I want to spend 
time to clean up my memory.

Then when I'm in a less-critical part of the code, I just 
re-enable the GC and let it do its job.

I know what you're going to say next.  There are cases where this 
level of control is not fine enough.  That's true, and that's 
where things like  nogc will help you.  But the blanket statement 
that you "can't use the language and its standard library as 
usual" just because of GC-phobia is, at best, inaccurate.
Jul 06 2018
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 [...]


 No triple AAA engine is going to switch to D for the following 
 reasons:
 1.)Cost vs benefit from converting C++ to D.
 2.)Gamers do not care how things are implemented, they want 
 results.
 3.)There are high abundance of c++ programmers for employees 
 to hired. I can't say the same thing for D.
 4.)GC phobia.(The notorious culprit)


 -Alex


 +1

 Just one silly question.

 Can the following "naive" D code trigger a garbage collection 
 stall ?

 score.Text = point_count.to!string() ~ " POINTS";


The correct answer is: I don't know, as I don't know what 
"point_count" is in the first place, as it never been defined.

-Alex
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 [...]


 No triple AAA engine is going to switch to D for the 
 following reasons:
 1.)Cost vs benefit from converting C++ to D.
 2.)Gamers do not care how things are implemented, they want 
 results.
 3.)There are high abundance of c++ programmers for employees 
 to hired. I can't say the same thing for D.
 4.)GC phobia.(The notorious culprit)


 -Alex


 +1

 Just one silly question.

 Can the following "naive" D code trigger a garbage collection 
 stall ?

 score.Text = point_count.to!string() ~ " POINTS";


 The correct answer is: I don't know, as I don't know what 
 "point_count" is in the first place, as it never been defined.

 -Alex


Actually you answer was right even if the point count was not 
stored as an integer ;)

For C++, the answer is : never.

Two small memory blocks will have to be allocated from the memory 
pool, which is not smart, obviously, but apart of that, nothing 
to worry about.

Because there is no garbage collector in C++, memory has to be 
allocated and deallocated in a continuous manner...
Jul 06 2018
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/6/18 11:19 AM, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote:

 Just one silly question.

 Can the following "naive" D code trigger a garbage collection stall ?

 score.Text = point_count.to!string() ~ " POINTS";


 The correct answer is: I don't know, as I don't know what 
 "point_count" is in the first place, as it never been defined.


 
 Actually you answer was right even if the point count was not stored as 
 an integer ;)


The real answer is what rikki says.

Note that what point_count is is irrelevant, the concatenation operator 
is going to trigger a GC allocation.

We could go further and say "Well, you haven't defined `to` or `string`" 
and then we can say we have no idea what this means at all!


 
 For C++, the answer is : never.


Of course, the answer in C++ is that it won't compile, this is D code! ;)

And yes, you can have  nogc code in D, and it's less pleasant than 
normal D code, but still WAY more pleasant that most C++ code. So will 
people put up with this who want to just write games? Given the current 
state of the landscape, probably not.

At some point, someone is going to make a fantastic game engine in D, 
and then we will have a ballgame. Maybe it happens after D gets better 
support for reference counting, maybe before. Nothing inherent in D 
makes it impossible or unlikely. But people aren't going to switch "just 
because", there needs to be a compelling reason that causes someone to 
champion it.

-Steve
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Of course, the answer in C++ is that it won't compile, this is 
 D code! ;)


Seriously ?

I wrote : "And what about the same code in C++ ?"

I thought people on this forum were smart enough to understand 
"the C++ port of this D code".

I'm sorry to have been wrong on this.

Anyway, what nobody here *wants* to understand, is that such 
"NAIVE" C++ string code may not be performant, but in C++, even 
if you make allocations/deallocations during the game loop, this 
won't be good for the game performance, but that's all.

With D, ANY forgotten allocation during the game loop (and I 
really mean even JUST ONE hidden allocation somewhere in the 
whole game or engine), may cause the game to regularly freeze at 
the wrong time, because of an unwanted GC. Hence the phobia.

Anyway, I know I'm on a D forum here, so "those who don't want to 
understand won't, and those who want will", to paraphrase a 
former poster here.
Jul 06 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 07/07/2018 3:53 AM, Ecstatic Coder wrote:

 With D, ANY forgotten allocation during the game loop (and I really mean 
 even JUST ONE hidden allocation somewhere in the whole game or engine), 
 may cause the game to regularly freeze at the wrong time, because of an 
 unwanted GC. Hence the phobia.


Disable the GC, boom! Done.
No risk at all.
Jul 06 2018
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/6/18 11:53 AM, Ecstatic Coder wrote:

 Of course, the answer in C++ is that it won't compile, this is D code! ;)


 
 Seriously ?


No, not seriously! I realized what you meant.


 I wrote : "And what about the same code in C++ ?"
 
 I thought people on this forum were smart enough to understand "the C++ 
 port of this D code".


It was a point that we are delving into the absurd, saying "it depends 
on what type point_value is".


 I'm sorry to have been wrong on this.


Sorry I made it seem like I was serious, my humor can be very dry sometimes.


 Anyway, what nobody here *wants* to understand, is that such "NAIVE" C++ 
 string code may not be performant, but in C++, even if you make 
 allocations/deallocations during the game loop, this won't be good for 
 the game performance, but that's all.


This is the reason why most game people shy away from D code. Because 
the GC is so inherent in the language, it's difficult to prove that you 
can call any function without incurring a possible GC cycle.

The two ways around this are to use  nogc, or to turn off the GC when 
you don't want it to run.

The blog has a whole series on working with and without the GC in D.


 
 With D, ANY forgotten allocation during the game loop (and I really mean 
 even JUST ONE hidden allocation somewhere in the whole game or engine), 
 may cause the game to regularly freeze at the wrong time, because of an 
 unwanted GC. Hence the phobia.


This is why you use  nogc. You then can't forget such things. But then 
of course, you need to avoid a lot of D niceties.

-Steve
Jul 06 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
 But then of course, you need to avoid a lot of D niceties.


Unfortunately, in my case this is the exact moment where D looses 
a LOT of its shininess compared to C++.

The balance is no more that much in favor of D as it was before, 
because it's "standard" D code which is so much more convenient 
than C++ in many situations, especially when implementing file 
processing scripts.

This is why I think that even C++ developers who use D as a file 
processing language (like me) will still stick to C++ for their 
game engine, even if they would probably be more than happy to be 
able to use *STANDARD* D code instead...
Jul 06 2018
prev sibling next sibling parent reply wjoe <none example.com> writes:
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:

 With D, ANY forgotten allocation during the game loop (and I 
 really mean even JUST ONE hidden allocation somewhere in the 
 whole game or engine), may cause the game to regularly freeze 
 at the wrong time, because of an unwanted GC. Hence the phobia.


You make it sound like a C++ game codes, debugs, profiles and 
optimizes itself.
And like there are no gotchas with C++.


 Anyway, I know I'm on a D forum here, so "those who don't want 
 to understand won't, and those who want will", to paraphrase a 
 former poster here.


Well, it appears that you don't.

And since you point out the D forum folks, I know game developers 
are a very special lot, too, with ther mantra like repetition of 
GC is the devil, acting like it's 1985 and the need to count 
clock cycles and top-of-the-food-chain I-never-make-mistakes 
arrogance like nobody else knows how to write fast code, yet most 
games of those clever guys are bug ridden pieces of poor quality 
even years after release, including top AAA titles *cough* TES. 
Despite - or more likely because - being made in C++.

Maybe performance aware game developers would do well to also 
adopt the idea of code quality and D offers a lot in that regard. 
Plus C++ish performance on top of that.
Jul 06 2018
next sibling parent wjoe <none example.com> writes:
On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote:

 And since you point out the D forum folks, I know game 
 developers are a very special lot, too ...


Edit: This should read: I know game developers who are a very 
special lot

My point was to only refer to the people I know, not game 
developers in general.
Jul 06 2018
prev sibling parent reply JN <666total wp.pl> writes:
On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote:

 On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:

 With D, ANY forgotten allocation during the game loop (and I 
 really mean even JUST ONE hidden allocation somewhere in the 
 whole game or engine), may cause the game to regularly freeze 
 at the wrong time, because of an unwanted GC. Hence the phobia.


 You make it sound like a C++ game codes, debugs, profiles and 
 optimizes itself.
 And like there are no gotchas with C++.


 Anyway, I know I'm on a D forum here, so "those who don't want 
 to understand won't, and those who want will", to paraphrase a 
 former poster here.


 Well, it appears that you don't.

 And since you point out the D forum folks, I know game 
 developers are a very special lot, too, with ther mantra like 
 repetition of GC is the devil, acting like it's 1985 and the 
 need to count clock cycles and top-of-the-food-chain 
 I-never-make-mistakes arrogance like nobody else knows how to 
 write fast code, yet most games of those clever guys are bug 
 ridden pieces of poor quality even years after release, 
 including top AAA titles *cough* TES. Despite - or more likely 
 because - being made in C++.

 Maybe performance aware game developers would do well to also 
 adopt the idea of code quality and D offers a lot in that 
 regard. Plus C++ish performance on top of that.


Yeah. There are plenty of games done in GC languages. C++ folks 
want to use C++. The ones that wanted to switched, switched 
already. Even if nogc gets more mature, they will find another 
excuse. Probably something like "yeah but now I don't know which 
parts of the language and library I can use and it's awkward to 
put nogc everywhere".

I do some free time game development work in various languages, 
even GC ones and the existence of GC was never a big issue for 
me. Sure, I am not a super mighty C++ programmer, so I don't know 
much, but for me it's more important as a gamedev to have 
features such as operator overloading, value types/be able to 
cast Vector3f[] to float[] without copying (something C/C++/D can 

LayoutKind.Sequential), accessibility of C bindings for popular 
libraries like SDL, SFML, ODE.

nogc, betterC, interfacing to C++, at most they get a "hmm, 
that's interesting", but I haven't really seen them bring people 
to D. And I'll take a fun and convenient language over performant 
one any day.
Jul 06 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 17:43:29 UTC, JN wrote:

 On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote:

 On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:

 With D, ANY forgotten allocation during the game loop (and I 
 really mean even JUST ONE hidden allocation somewhere in the 
 whole game or engine), may cause the game to regularly freeze 
 at the wrong time, because of an unwanted GC. Hence the 
 phobia.


 You make it sound like a C++ game codes, debugs, profiles and 
 optimizes itself.
 And like there are no gotchas with C++.


 Anyway, I know I'm on a D forum here, so "those who don't 
 want to understand won't, and those who want will", to 
 paraphrase a former poster here.


 Well, it appears that you don't.

 And since you point out the D forum folks, I know game 
 developers are a very special lot, too, with ther mantra like 
 repetition of GC is the devil, acting like it's 1985 and the 
 need to count clock cycles and top-of-the-food-chain 
 I-never-make-mistakes arrogance like nobody else knows how to 
 write fast code, yet most games of those clever guys are bug 
 ridden pieces of poor quality even years after release, 
 including top AAA titles *cough* TES. Despite - or more likely 
 because - being made in C++.

 Maybe performance aware game developers would do well to also 
 adopt the idea of code quality and D offers a lot in that 
 regard. Plus C++ish performance on top of that.


 Yeah. There are plenty of games done in GC languages. C++ folks 
 want to use C++. The ones that wanted to switched, switched 
 already. Even if nogc gets more mature, they will find another 
 excuse. Probably something like "yeah but now I don't know 
 which parts of the language and library I can use and it's 
 awkward to put nogc everywhere".

 I do some free time game development work in various languages, 
 even GC ones and the existence of GC was never a big issue for 
 me. Sure, I am not a super mighty C++ programmer, so I don't 
 know much, but for me it's more important as a gamedev to have 
 features such as operator overloading, value types/be able to 
 cast Vector3f[] to float[] without copying (something C/C++/D 

 with LayoutKind.Sequential), accessibility of C bindings for 
 popular libraries like SDL, SFML, ODE.

 nogc, betterC, interfacing to C++, at most they get a "hmm, 
 that's interesting", but I haven't really seen them bring 
 people to D. And I'll take a fun and convenient language over 
 performant one any day.


As I said, I wanted to explain the roots of the GC phobia for 
some C++ developers.

If you don't agree when I said that one allocation during a C++ 
game loop is no problem, which one allocation during a GC 
language game loop MAY eventually become a problem, that's fine 
by me.

But as many people here told me to "disable the GC" to completely 
avoid this potential risk of game freeze, I guess that all those 
D experts are also wrong in giving me this advice.
Jul 06 2018
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:


 With D, ANY forgotten allocation during the game loop (and I 
 really mean even JUST ONE hidden allocation somewhere in the 
 whole game or engine), may cause the game to regularly freeze 
 at the wrong time, because of an unwanted GC. Hence the phobia.


This program

import std.conv, std.stdio;

 nogc void main() {
	int point_count = 3;
	string score = point_count.to!string() ~ " POINTS";
	writeln(score);
}

provides this compiler output

nogc.d(5): Error:  nogc function 'D main' cannot call non- nogc 
function 'std.conv.to!string.to!int.to'
nogc.d(5): Error: cannot use operator ~ in  nogc function 'D main'
nogc.d(6): Error:  nogc function 'D main' cannot call non- nogc 
function 'std.stdio.writeln!string.writeln'

Are you saying there are bugs in the  nogc implementation? 
Otherwise I don't see how you will end up with a forgotten 
allocation.
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 17:58:46 UTC, bachmeier wrote:

 On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote:


 With D, ANY forgotten allocation during the game loop (and I 
 really mean even JUST ONE hidden allocation somewhere in the 
 whole game or engine), may cause the game to regularly freeze 
 at the wrong time, because of an unwanted GC. Hence the phobia.


 This program

 import std.conv, std.stdio;

  nogc void main() {
 	int point_count = 3;
 	string score = point_count.to!string() ~ " POINTS";
 	writeln(score);
 }

 provides this compiler output

 nogc.d(5): Error:  nogc function 'D main' cannot call non- nogc 
 function 'std.conv.to!string.to!int.to'
 nogc.d(5): Error: cannot use operator ~ in  nogc function 'D 
 main'
 nogc.d(6): Error:  nogc function 'D main' cannot call non- nogc 
 function 'std.stdio.writeln!string.writeln'

 Are you saying there are bugs in the  nogc implementation? 
 Otherwise I don't see how you will end up with a forgotten 
 allocation.


I agree.

But that feature is not something present in all the garbage 
collected language.

The problem with my "naive" text score code is that you can trust 
the C++ version to deallocate the destroyed string buffers "on 
the fly".

Because in C++, smart pointers and collections will make sure to 
free unused memory block as soon as they need to, and no later.

For the garbage collected language version, it's up to the 
garbage collector to decide when and how this memory will be 
claimed. So sometimes this may happen at the wrong time too...

So I'm not saying that D can't work with the GC disabled, etc.

I'm saying that you will find it hard to convince many C++ game 
developers that they can make a few allocations within a game 

have to worry about that.

And by saying, "just disable the garbage collector", you are 
convincing them still more of that, instead of the contrary.
Jul 06 2018
parent reply JN <666total wp.pl> writes:
On Friday, 6 July 2018 at 18:19:08 UTC, Ecstatic Coder wrote:

 Because in C++, smart pointers and collections will make sure 
 to free unused memory block as soon as they need to, and no 
 later.


I bet if D was reference counted from the start, C++ programmers 
would complain about "smart pointer overhead" and how ref 
counting is too slow for games/real time and you should be able 
to manage your memory yourself.
Jul 06 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 19:56:23 UTC, JN wrote:

 On Friday, 6 July 2018 at 18:19:08 UTC, Ecstatic Coder wrote:

 Because in C++, smart pointers and collections will make sure 
 to free unused memory block as soon as they need to, and no 
 later.


 I bet if D was reference counted from the start, C++ 
 programmers would complain about "smart pointer overhead" and 
 how ref counting is too slow for games/real time and you should 
 be able to manage your memory yourself.


Probably ;)
Jul 06 2018
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:

 For C++, the answer is : never.


...Yeah I had already figure out what your aiming at. For C++ the 
correct answer is "I do not know as I don't know how it is 
implemented". You act like there isn't any GC libraries for C++.

-Alex
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:

 For C++, the answer is : never.


 ...Yeah I had already figure out what your aiming at. For C++ 
 the correct answer is "I do not know as I don't know how it is 
 implemented". You act like there isn't any GC libraries for C++.

 -Alex


LOL

Unless you implement your game in managed-C++, I don't think 
there is much to worry about that though...
Jul 06 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:

 For C++, the answer is : never.


 ...Yeah I had already figure out what your aiming at. For C++ 
 the correct answer is "I do not know as I don't know how it is 
 implemented". You act like there isn't any GC libraries for 
 C++.

 -Alex


 LOL

 Unless you implement your game in managed-C++, I don't think 
 there is much to worry about that though...


Your comparison is logical fallacious to begin with.

-Alex
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 16:48:17 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:

 For C++, the answer is : never.


 ...Yeah I had already figure out what your aiming at. For C++ 
 the correct answer is "I do not know as I don't know how it 
 is implemented". You act like there isn't any GC libraries 
 for C++.

 -Alex


 LOL

 Unless you implement your game in managed-C++, I don't think 
 there is much to worry about that though...


 Your comparison is logical fallacious to begin with.

 -Alex


I was just trying to explain why C++ developers have GC phobia 
through a very simple example.

Even the simplest string concatenation in any garbage collected 
language (like Java, etc) can be the cause of of serious game 
freeze, which most players (including me) won't tolerate for long.

Even one tiny allocation which is hidden deep somewhere in an 
external library of some sort...

But it was obviously pointless to try to explain it on this D 
forum. I understand it now.
Jul 06 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 17:00:49 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 16:48:17 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 16:45:41 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 16:33:19 UTC, 12345swordy wrote:

 [...]


 LOL

 Unless you implement your game in managed-C++, I don't think 
 there is much to worry about that though...


 Your comparison is logical fallacious to begin with.

 -Alex


 I was just trying to explain why C++ developers have GC phobia 
 through a very simple example.

 Even the simplest string concatenation in any garbage collected 
 language (like Java, etc) can be the cause of of serious game 
 freeze, which most players (including me) won't tolerate for 
 long.

 Even one tiny allocation which is hidden deep somewhere in an 
 external library of some sort...

 But it was obviously pointless to try to explain it on this D 
 forum. I understand it now.


Are you seriously going to ignore video games that are entirely 

AN ISSUE IF YOU KNOW WHAT YOU ARE DOING!

-Alexander
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Are you seriously going to ignore video games that are entirely 

 NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING!

 -Alexander


+1

Indeed ABSOLUTELY NO garbage collection will happen during the 
game loop is 100% of your GC-language code doesn't make any 
string concatenation, object allocation, etc.

While ANY C++ game can make ANY number of allocations/allocations 
inside a game loop and still run without a risking any freeze. I 
will probably slower than it should, so you'd better don't make 
too much of them ;)

But the game won't freeze.

C++ is allocation/deallocation tolerant to a reasonable extent.

GC language aren't. You eventually have to reach the ZERO 
allocation limit, or you expose yourself to unwanted game freezes.
Jul 06 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 17:16:54 UTC, Ecstatic Coder wrote:

 Are you seriously going to ignore video games that are 

 The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING!

 -Alexander


 +1


You are start reminding me of another person who pull these type 
of stunts. Which is not a good thing btw, as that guy is a 
notorious troll.



 While ANY C++ game can make ANY number of 
 allocations/allocations inside a game loop and still run 
 without a risking any freeze.


You are doing something very wrong if you are doing this.

-Alexander
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 17:22:15 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 17:16:54 UTC, Ecstatic Coder wrote:

 Are you seriously going to ignore video games that are 

 The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING!

 -Alexander


 +1


 You are start reminding me of another person who pull these 
 type of stunts. Which is not a good thing btw, as that guy is a 
 notorious troll.


So if I agree with you, then I'm a troll ?


 While ANY C++ game can make ANY number of 
 allocations/allocations inside a game loop and still run 
 without a risking any freeze.


 You are doing something very wrong if you are doing this.

 -Alexander


Just try it.

Inside the game loop, add a for loop which evaluates the score 
text 100 times as explained above.

Or even 1000 times.

This means roughly 2000 allocations and 1999 deallocations.

Your frame rate suffer will suffer from this, which is bad (and 
as such should absolutely avoided) but zero risk of garbage 
collection freeze.

Then add ONE time the "naive" text score concatenation in the 
game loop of a garbage collected loop, and you expose yourself to 
a RISK of a garbage collection freeze. Just because of ONE string 
concatenation, executed only once per frame, which is something 
that could be tolerated in a C++ game.
Jul 06 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote:



 While ANY C++ game can make ANY number of 
 allocations/allocations inside a game loop and still run 
 without a risking any freeze.


 You are doing something very wrong if you are doing this.

 -Alexander


 Just try it.


For what rhyme or reason!? You shouldn't be allocating and 
deallocating inside a critical loop in the first place!
Regardless people have shown you solutions regarding string 
concatenation. Are you going to address that or you just going to 
ignore them?

-Alexander
Jul 06 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote:



 While ANY C++ game can make ANY number of 
 allocations/allocations inside a game loop and still run 
 without a risking any freeze.


 You are doing something very wrong if you are doing this.

 -Alexander


 Just try it.


 For what rhyme or reason!? You shouldn't be allocating and 
 deallocating inside a critical loop in the first place!
 Regardless people have shown you solutions regarding string 
 concatenation. Are you going to address that or you just going 
 to ignore them?

 -Alexander


Also when I used the word phobia I was pretty sure that I was 
referring to irrational fear of things. Big emphasis on the word 
"irrational".

-Aleaxander
Jul 06 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 19:27:51 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote:



 While ANY C++ game can make ANY number of 
 allocations/allocations inside a game loop and still run 
 without a risking any freeze.


 You are doing something very wrong if you are doing this.

 -Alexander


 Just try it.


 For what rhyme or reason!? You shouldn't be allocating and 
 deallocating inside a critical loop in the first place!
 Regardless people have shown you solutions regarding string 
 concatenation. Are you going to address that or you just going 
 to ignore them?

 -Alexander


 Also when I used the word phobia I was pretty sure that I was 
 referring to irrational fear of things. Big emphasis on the 
 word "irrational".

 -Aleaxander


Irrational would mean this would be impossible to have a GC 
freeze because of just one string concatenation during the game 
loop of a garbage collected language.
Jul 06 2018
prev sibling parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 19:22:13 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 17:59:27 UTC, Ecstatic Coder wrote:



 While ANY C++ game can make ANY number of 
 allocations/allocations inside a game loop and still run 
 without a risking any freeze.


 You are doing something very wrong if you are doing this.

 -Alexander


 Just try it.


 For what rhyme or reason!? You shouldn't be allocating and 
 deallocating inside a critical loop in the first place!
 Regardless people have shown you solutions regarding string 
 concatenation. Are you going to address that or you just going 
 to ignore them?

 -Alexander


Pfff, it was just an EXAMPLE of how some insignificant string 
concatenation code may eventually be a problem in any GC language 
even if it's done only once per frame.

I've never said that this is something smart to do. I'm just 
saying that this code can perfectly be executed once in a C++ 
game frame without having to worry for a game freeze, because the 
string buffer deallocation is done once per frame too.

While with many GC languages, you actually DON'T KNOW when all 
those unused string buffers will be claimed.

This ignorance is, in my opinion, the root of this "phoebia".

If you disagree with me, fine. No problem. Maybe I'm wrong.

But this is my opinion. Please feel free to ignore it.
Jul 06 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 06, 2018 at 08:16:36PM +0000, Ecstatic Coder via
Digitalmars-d-announce wrote:
[...]

 I've never said that this is something smart to do. I'm just saying
 that this code can perfectly be executed once in a C++ game frame
 without having to worry for a game freeze, because the string buffer
 deallocation is done once per frame too.
 
 While with many GC languages, you actually DON'T KNOW when all those
 unused string buffers will be claimed.


[...]

As I've already repeated twice, this is not true in D. You *can* predict
precisely when the GC runs a collection cycle by calling GC.disable and
then calling GC.collect according to *your* own schedule.  This is not
just a theoretical thing.  I have actually done this in my own projects,
and it does work.

Of course, for someone looking for an excuse not to use D, they will
always find another reason why this is not sufficient. But that only
strengthens the point that the GC is just a convenient excuse not to use
D. Solve that problem, and they will just move on to the next excuse,
because the GC is not the real reason; the real reason is probably
non-technical. Like good ole inertia: people are lazy and set in their
ways, and resist changing what they've grown comfortable with. But
actually admitting this would make them look bad, so it is easier to
find a convenient excuse like the GC (or whatever else is different from
the status quo).


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose
Bierce
Jul 06 2018
next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
  Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:

 On Fri, Jul 06, 2018 at 08:16:36PM +0000, Ecstatic Coder via 
 Digitalmars-d-announce wrote: [...]

 I've never said that this is something smart to do. I'm just 
 saying that this code can perfectly be executed once in a C++ 
 game frame without having to worry for a game freeze, because 
 the string buffer deallocation is done once per frame too.
 
 While with many GC languages, you actually DON'T KNOW when all 
 those unused string buffers will be claimed.


 [...]

 As I've already repeated twice, this is not true in D. You 
 *can* predict precisely when the GC runs a collection cycle by 
 calling GC.disable and then calling GC.collect according to 
 *your* own schedule.  This is not just a theoretical thing.  I 
 have actually done this in my own projects, and it does work.

 Of course, for someone looking for an excuse not to use D, they 
 will always find another reason why this is not sufficient. But 
 that only strengthens the point that the GC is just a 
 convenient excuse not to use D. Solve that problem, and they 
 will just move on to the next excuse, because the GC is not the 
 real reason; the real reason is probably non-technical. Like 
 good ole inertia: people are lazy and set in their ways, and 
 resist changing what they've grown comfortable with. But 
 actually admitting this would make them look bad, so it is 
 easier to find a convenient excuse like the GC (or whatever 
 else is different from the status quo).


 T


+1
Jul 06 2018
prev sibling next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
 As I've already repeated twice, this is not true in D. You 
 *can* predict precisely when the GC runs a collection cycle by 
 calling GC.disable and then calling GC.collect according to 
 *your* own schedule.  This is not just a theoretical thing.  I 
 have actually done this in my own projects, and it does work.


Sorry, can you help me with this?

Eg.
void doit()
{
     int[] x;
     x.length = 1024 * 1024 * 128;
}

void main()
{
     import core.memory : GC;
     import core.thread;
     GC.disable;

     doit; //alloc +- 500mb inside the func.
     Thread.sleep(5.seconds); //500mb still in use.
     GC.collect; //hmmm still there
     Thread.sleep(5.seconds); //same
}
Jul 10 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jul 10, 2018 at 04:07:01PM +0000, SrMordred via Digitalmars-d-announce
wrote:

 As I've already repeated twice, this is not true in D. You *can*
 predict precisely when the GC runs a collection cycle by calling
 GC.disable and then calling GC.collect according to *your* own
 schedule.  This is not just a theoretical thing.  I have actually
 done this in my own projects, and it does work.


 
 Sorry, can you help me with this?
 
 Eg.
 void doit()
 {
     int[] x;
     x.length = 1024 * 1024 * 128;
 }
 
 void main()
 {
     import core.memory : GC;
     import core.thread;
     GC.disable;
 
     doit; //alloc +- 500mb inside the func.
     Thread.sleep(5.seconds); //500mb still in use.
     GC.collect; //hmmm still there
     Thread.sleep(5.seconds); //same
 }


[...]

AFAIK, the current GC does not release memory back to the OS. So you
won't see the memory footprint decrease.  However, it does free up
memory for subsequent allocations.


T

-- 
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and intoxicate. It
is the old things that are young. -- G.K. Chesterton
Jul 10 2018
parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Tuesday, 10 July 2018 at 17:03:01 UTC, H. S. Teoh wrote:

 AFAIK, the current GC does not release memory back to the OS. 
 So you won't see the memory footprint decrease.  However, it 
 does free up memory for subsequent allocations.


 T


if you put another
int[] x;
x.length = 1024 * 1024 * 128;

After the GC.collect you now get 1GB of memory usage.

My point is, this type of control is not enough control for 
anyone coming from a non-GC language, so they will point out GC 
as a problem. And in my opinion with reason.

I´m using my own lib on D with nogc container and other utilities 
to avoid completly the GC.

Altought I know that is completly possible to use GC and have 
good performance, I dont think the arguments for it are enough to 
convince most people.

I find D awesome (and probably will never look at C++ again), but 
for me you can remove GC completly from the language and it will 
continue to be aswesome.

(For me, i'm hoping to compile everything that I have with 
-betterC in the future. Waiting for some bugs related to betterC 
to be solved)
Jul 10 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote:

 After the GC.collect you now get 1GB of memory usage.


http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html
Jul 10 2018
parent SrMordred <patric.dexheimer gmail.com> writes:
On Tuesday, 10 July 2018 at 17:44:59 UTC, Adam D. Ruppe wrote:

 On Tuesday, 10 July 2018 at 17:39:06 UTC, SrMordred wrote:

 After the GC.collect you now get 1GB of memory usage.


 http://dpldocs.info/experimental-docs/core.memory.GC.minimize.html


yeah I was looking to this right now on the docs, thks :)

But still, all this knowledge about GC and all this calls to put 
the memory where you want, will happen automatically most of the 
time with the old scoped resources/RAII(and 
unique_ptr/shared_ptr, that D also have).


GC tradeoffs never really paid well for me. (or my mindset is 
very stuck in the old ways :P)
Jul 10 2018
prev sibling parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:

 On Fri, Jul 06, 2018 at 08:16:36PM +0000, Ecstatic Coder via 
 Digitalmars-d-announce wrote: [...]

 I've never said that this is something smart to do. I'm just 
 saying that this code can perfectly be executed once in a C++ 
 game frame without having to worry for a game freeze, because 
 the string buffer deallocation is done once per frame too.
 
 While with many GC languages, you actually DON'T KNOW when all 
 those unused string buffers will be claimed.


 [...]

 Of course, for someone looking for an excuse not to use D, they 
 will always find another reason why this is not sufficient. But 
 that only strengthens the point that the GC is just a 
 convenient excuse not to use D.


Not a good excuse to not fix GC, though.


 Solve that problem, and they will just move on to the next 
 excuse, because the GC is not the real reason; the real reason 
 is probably non-technical. Like good ole inertia: people are 
 lazy and set in their ways, and resist changing what they've 
 grown comfortable with. But actually admitting this would make 
 them look bad, so it is easier to find a convenient excuse like 
 the GC (or whatever else is different from the status quo).


If that's the case, then we are doom. We might just as well 
forget about getting popular, and instead spend time making the 
language better.

Like fixing the GC.

(Although I don't quite agree with you. Some people DO resist 
change, that's why some decades old languages are still popular. 
But look at the popularity of new languages like Go, and Rust, 
and the ever-change landscape of front-end development. There're 
tons of people who adapt certain technology just because it is 
new, why can't that happen to D?)


 T
Jul 10 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jul 10, 2018 at 05:25:11PM +0000, Yuxuan Shui via
Digitalmars-d-announce wrote:

 On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:


[...]

 Of course, for someone looking for an excuse not to use D, they will
 always find another reason why this is not sufficient. But that only
 strengthens the point that the GC is just a convenient excuse not to
 use D.


 
 Not a good excuse to not fix GC, though.


Of course.  The current GC, while decent, does leave lots of room for
improvement.  Unfortunately, while much talked about, not many people
are willing to actually put in the work to improve it.  So I'm not
really interested in generating more talk, as opposed to action.



 Solve that problem, and they will just move on to the next excuse,
 because the GC is not the real reason; the real reason is probably
 non-technical. Like good ole inertia: people are lazy and set in
 their ways, and resist changing what they've grown comfortable with.
 But actually admitting this would make them look bad, so it is
 easier to find a convenient excuse like the GC (or whatever else is
 different from the status quo).


 
 If that's the case, then we are doom. We might just as well forget
 about getting popular, and instead spend time making the language
 better.


I have always been skeptical of popularity.  It is neither a necessary
nor sufficient condition for improved language quality.  That's not to
say we should not invest effort in marketing D... but popularity does
not imply technical superiority, and the only reason I'm here is because
of D's technical superiority.



 Like fixing the GC.


Nobody argues *against* fixing the GC.  But, who will actually do it? As
opposed to the crowds who are very willing to only talk about it.



 (Although I don't quite agree with you. Some people DO resist change,
 that's why some decades old languages are still popular. But look at
 the popularity of new languages like Go, and Rust, and the ever-change
 landscape of front-end development. There're tons of people who adapt
 certain technology just because it is new, why can't that happen to
 D?)


[...]

Those who adapt technology merely because it's new, are what I call the
bandwagon jumpers. They will flock to the next brand new thing, and then
just as readily leave in droves once the novelty has worn off. They are
unreliable customers, and I wouldn't build a business based on their
continuing support.  Again, popularity is orthogonal to technical
excellence.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL
Jul 10 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Tuesday, 10 July 2018 at 18:20:27 UTC, H. S. Teoh wrote:

 On Tue, Jul 10, 2018 at 05:25:11PM +0000, Yuxuan Shui via 
 Digitalmars-d-announce wrote:

 On Friday, 6 July 2018 at 21:15:46 UTC, H. S. Teoh wrote:


 [...]

 Of course, for someone looking for an excuse not to use D, 
 they will always find another reason why this is not 
 sufficient. But that only strengthens the point that the GC 
 is just a convenient excuse not to use D.


 
 Not a good excuse to not fix GC, though.


 Of course.  The current GC, while decent, does leave lots of 
 room for improvement.  Unfortunately, while much talked about, 
 not many people are willing to actually put in the work to 
 improve it.  So I'm not really interested in generating more 
 talk, as opposed to action.



 Solve that problem, and they will just move on to the next 
 excuse, because the GC is not the real reason; the real 
 reason is probably non-technical. Like good ole inertia: 
 people are lazy and set in their ways, and resist changing 
 what they've grown comfortable with. But actually admitting 
 this would make them look bad, so it is easier to find a 
 convenient excuse like the GC (or whatever else is different 
 from the status quo).


 
 If that's the case, then we are doom. We might just as well 
 forget about getting popular, and instead spend time making 
 the language better.


 I have always been skeptical of popularity.  It is neither a 
 necessary nor sufficient condition for improved language 
 quality.  That's not to say we should not invest effort in 
 marketing D... but popularity does not imply technical 
 superiority, and the only reason I'm here is because of D's 
 technical superiority.



 Like fixing the GC.


 Nobody argues *against* fixing the GC.  But, who will actually 
 do it? As opposed to the crowds who are very willing to only 
 talk about it.



 (Although I don't quite agree with you. Some people DO resist 
 change, that's why some decades old languages are still 
 popular. But look at the popularity of new languages like Go, 
 and Rust, and the ever-change landscape of front-end 
 development. There're tons of people who adapt certain 
 technology just because it is new, why can't that happen to D?)


 [...]

 Those who adapt technology merely because it's new, are what I 
 call the bandwagon jumpers. They will flock to the next brand 
 new thing, and then just as readily leave in droves once the 
 novelty has worn off. They are unreliable customers, and I 
 wouldn't build a business based on their continuing support.  
 Again, popularity is orthogonal to technical excellence.


 T


Except for Crystal, I think that D is superior to many languages 
in *ease of use* and *expressivity*, and I really like it a lot 
for that.

But for technical aspect like performance, very honestly I'm 
still not sure of its technical superiority over similar 
languages.

For instance, I'm personally convinced that a Go web server can 
often beat its vibe.d equivalent in technical aspects like raw 
performance, memory consumption, multi-core usage, etc.

And even if benchmarks are always to be interpreted cautiously, 
when several of them lead to exactly the same conclusion as my 
own tests, and with such big margins, it's very hard to 
completely ignore them.

Just have a look at this one, which is quite famous :

https://www.techempower.com/benchmarks/

I know that many people here will simply tell me that all those 
personal et external benchmarks are all wrong, etc.

Maybe you are right.

But in terms of communication, wouldn't it be much more effective 
that the D experts of this forum simply fix the open source code 
of those benchmarks to make D's technical superiority much more 
obvious, so that the decision makers of software development 
companies, which stupidly use the informations of such benchmarks 
when investigating alternative technologies, can more easily 
suggest to their leadership to switch to D ?
Jul 11 2018
next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
 But for technical aspect like performance, very honestly I'm 
 still not sure of its technical superiority over similar 
 languages.



 Just have a look at this one, which is quite famous :

 https://www.techempower.com/benchmarks/

 I know that many people here will simply tell me that all those 
 personal et external benchmarks are all wrong, etc.

 Maybe you are right.

 But in terms of communication, wouldn't it be much more 
 effective that the D experts of this forum simply fix the open 
 source code of those benchmarks to make D's technical 
 superiority much more obvious, so that the decision makers of 
 software development companies, which stupidly use the 
 informations of such benchmarks when investigating alternative 
 technologies, can more easily suggest to their leadership to 
 switch to D ?


I' quite sure that D can achieve performance equivalence with any 
other language. I don´t see any reason not to.

About that specific benchmark, not sure vibe.d had some updates 
since the first time I saw because I remembered people arguing 
here about why it was not that good on performance. Maybe now it 
will make better results.

And I agree about the communication part. Altough i like to see 
benchmarks and like to see the competition part of it their 
objective is just to point out that "we can do as much as these 
other guys can".

When benchmarks go slow people say that "benchmark is not 
everything or are wrong somehow".

But then when D get the fastest regex parser of the world, is all 
proud :)

But again, I believe that D can be performance competitive in any 
case.
Jul 11 2018
parent Greatsam4sure <greatsam4sure gmail.com> writes:
On Wednesday, 11 July 2018 at 13:57:45 UTC, SrMordred wrote:

 But for technical aspect like performance, very honestly I'm 
 still not sure of its technical superiority over similar 
 languages.



 Just have a look at this one, which is quite famous :

 https://www.techempower.com/benchmarks/

 I know that many people here will simply tell me that all 
 those personal et external benchmarks are all wrong, etc.

 Maybe you are right.

 But in terms of communication, wouldn't it be much more 
 effective that the D experts of this forum simply fix the open 
 source code of those benchmarks to make D's technical 
 superiority much more obvious, so that the decision makers of 
 software development companies, which stupidly use the 
 informations of such benchmarks when investigating alternative 
 technologies, can more easily suggest to their leadership to 
 switch to D ?


 I' quite sure that D can achieve performance equivalence with 
 any other language. I don´t see any reason not to.

 About that specific benchmark, not sure vibe.d had some updates 
 since the first time I saw because I remembered people arguing 
 here about why it was not that good on performance. Maybe now 
 it will make better results.

 And I agree about the communication part. Altough i like to see 
 benchmarks and like to see the competition part of it their 
 objective is just to point out that "we can do as much as these 
 other guys can".

 When benchmarks go slow people say that "benchmark is not 
 everything or are wrong somehow".

 But then when D get the fastest regex parser of the world, is 
 all proud :)

 But again, I believe that D can be performance competitive in 
 any case.


Sincerely speaking D language does not merit all these criticism. 
The magnitude of criticism on D language does not really make 
sense to me. I am yet to see a language so user friendly as D 
with such power and strength.I trust one day the world will see 
and know that D is a language build for programmers for great 
productivity and not just another money making machine
Jul 11 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jul 11, 2018 at 09:36:25AM +0000, Ecstatic Coder via
Digitalmars-d-announce wrote:
[...]

 Except for Crystal, I think that D is superior to many languages in
 *ease of use* and *expressivity*, and I really like it a lot for that.
 
 But for technical aspect like performance, very honestly I'm still not
 sure of its technical superiority over similar languages.
 
 For instance, I'm personally convinced that a Go web server can often
 beat its vibe.d equivalent in technical aspects like raw performance,
 memory consumption, multi-core usage, etc.


Recently, it has been openly acknowledged that vibe.d is not the most
efficient for certain use cases.  I don't know if the problem has been
solved yet, but I assume somebody's working on it.



 And even if benchmarks are always to be interpreted cautiously, when
 several of them lead to exactly the same conclusion as my own tests,
 and with such big margins, it's very hard to completely ignore them.


It's true that benchmarks results should always be taken with a grain of
salt, but that doesn't mean D is already flawless and we don't need to
improve things.  On the contrary, I think there's lots of room for
improvement, which is one of the things that draws me to D, because
here's a chance to contribute something meaningful to a powerful, easy
to use language.  That's the advantage of a true open source project,
where money isn't the driving factor, but people solving real problems
and honing it to be something excellent -- and anyone can participate if
they choose to.


[...]

 But in terms of communication, wouldn't it be much more effective that
 the D experts of this forum simply fix the open source code of those
 benchmarks to make D's technical superiority much more obvious, so
 that the decision makers of software development companies, which
 stupidly use the informations of such benchmarks when investigating
 alternative technologies, can more easily suggest to their leadership
 to switch to D ?


This is one of the things about open source / volunteer projects that
may or may not be a good thing (it can be argued both ways).  Since
people aren't getting paid to do grunt work, if nobody steps up to the
plate to fix an issue, it will either just sit there forever, or it will
fall upon Walter and Andrei to get to it, which, given how much is
already on their plate, will take a very, very long time.  And people
will just work on whatever interests them.  Happy D users who don't find
any problems (for THEIR use case) won't have much motivation to
contribute to something that doesn't directly benefit them (or they
don't even use it).  Unhappy D users who *do* find a problem will either
step up and fix it and contribute it so that the rest of the community
benefits, or they will choose not to participate, in which case nothing
happens.

I'm not trying to justify this situation, but having observed how things
work around here for the past many years, that's just the way things
work.  Either somebody gets ticked off enough to actually do something
about an issue, resulting in all-round benefits, or they just do
nothing, and nothing happens. (Complaining in the forums doesn't count,
since it has been proven time and time again that this almost never
leads to any actual change.)  This is unlike how most commercially
driven projects work, for obvious reasons, and for better or for worse,
that's what we have to deal with. (Personally I think this is actually a
good thing, but I'm guessing many people will disagree.)

So saying "wouldn't it be much more effective that the D experts of this
forum simply fix the open source code" ultimately won't lead to much
change, for better or for worse.  *Somebody* has to step up to do it.
Expecting somebody else to spend their unpaid volunteer time to work on
something that may not really interest them is, to say the least,
unrealistic.  The solution, as Walter says, is to "be the change you
want to see".


T

-- 
When solving a problem, take care that you do not become part of the problem.
Jul 11 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 This is one of the things about open source / volunteer 
 projects that may or may not be a good thing (it can be argued 
 both ways).  Since people aren't getting paid to do grunt work, 
 if nobody steps up to the plate to fix an issue, it will either 
 just sit there forever, or it will fall upon Walter and Andrei 
 to get to it, which, given how much is already on their plate, 
 will take a very, very long time.  And people will just work on 
 whatever interests them.  Happy D users who don't find any 
 problems (for THEIR use case) won't have much motivation to 
 contribute to something that doesn't directly benefit them (or 
 they don't even use it).  Unhappy D users who *do* find a 
 problem will either step up and fix it and contribute it so 
 that the rest of the community benefits, or they will choose 
 not to participate, in which case nothing happens.

 I'm not trying to justify this situation, but having observed 
 how things work around here for the past many years, that's 
 just the way things work.  Either somebody gets ticked off 
 enough to actually do something about an issue, resulting in 
 all-round benefits, or they just do nothing, and nothing 
 happens. (Complaining in the forums doesn't count, since it has 
 been proven time and time again that this almost never leads to 
 any actual change.)  This is unlike how most commercially 
 driven projects work, for obvious reasons, and for better or 
 for worse, that's what we have to deal with. (Personally I 
 think this is actually a good thing, but I'm guessing many 
 people will disagree.)

 So saying "wouldn't it be much more effective that the D 
 experts of this forum simply fix the open source code" 
 ultimately won't lead to much change, for better or for worse.  
 *Somebody* has to step up to do it. Expecting somebody else to 
 spend their unpaid volunteer time to work on something that may 
 not really interest them is, to say the least, unrealistic.  
 The solution, as Walter says, is to "be the change you want to 
 see".


I agree. And I must admit that from that point of view I'm indeed 
part of the problem...
Jul 11 2018
parent reply RhyS <sale rhysoft.com> writes:
On Wednesday, 11 July 2018 at 21:19:18 UTC, Ecstatic Coder wrote:

 I agree. And I must admit that from that point of view I'm 
 indeed part of the problem...


Its a problem every open source project faces. No matter if its D 
or Crystal or ...

The main issue is that many people in those open source project 
forget, that the people who come to their project/language are 
only looking to use it for their work. They are not looking to 
spend x amount of time on open source development because they 
have their own projects or work.

Is it unfair that the mass benefits from the work of the few. 
Sure. But putting the blame on the people who use the tools and 
see them as problems is kind of ironic.

If the goal is to get a successful language, those type of blame 
attitudes are only counter productive. For most people its easy 
to switch languages when they have little invested and complain 
about issues.

Its the same with the donations. I stated before that D as a 
organisation with its financing feels very mysterious. You do not 
see where the money goes and people are not motivated to donate 
to a organisation when they feel their complains are not taken 
serious.

A lot of open source project simply forget that its all about 
marketing and community creation. If you fail at one of them, 
like being semi aggressive when new users complain, it simply 
cuts into your own pockets.


D has a massive increased in downloads but has a hard time 
actually keeping the people interested who download the D 
compiler. That normally needs to be a wake up call for any 
community.

I think a larger issue is that a lot of older community members 
have been with the D language for years upon years and they are 
tired of people complaining on issues. It also does not help that 
D simply keeps getting more features that few people care about 
outside a very small group of programmers. BetterC ... your not 
going to convert a lot of C developers. D as a C++ replacement, 
C++ 14/17 keeps improving, why change over to D with less 
resources.

In my personal opinion Crystal is gaining more momentum then D 
despite that D has a much more active blog/communication.

Part of that is simply that people come to D looking for a easy 
language and discover the over focus on C/C++ and run into the 
issues. Add a bit of semi-aggressive forum members when complains 
show up and there goes your new user looking at Go or another 
language.
Jul 12 2018
parent reply bachmeier <no spam.net> writes:
On Thursday, 12 July 2018 at 11:36:15 UTC, RhyS wrote:


 Its the same with the donations. I stated before that D as a 
 organisation with its financing feels very mysterious. You do 
 not see where the money goes


I've raised this issue elsewhere. I think there would be more 
incentive to donate if the money were used to do the boring 
things that are needed to make the language more usable. AFAICT, 
the money goes to internal compiler work to add new features to 
the language in order to appeal to C++ users. The work is done in 
secret (well, unless you want to go through Github threads) and 
there is not much communication even after it's done.


 I think a larger issue is that a lot of older community members 
 have been with the D language for years upon years and they are 
 tired of people complaining on issues.


Actually, they are the ones that do most of the complaining. They 
do get upset when others make false arguments though.


 Part of that is simply that people come to D looking for a easy 
 language and discover the over focus on C/C++ and run into the 
 issues.


True. Lately all official communications about D are about memory 
management, making the language as complicated and boring as 
Rust. That's not the fault of the D leadership though. It 
reflects the lack of effort on the part of others that want to 
use the language for something other than a C++ replacement. 
There is nothing stopping anyone from building up a community 
that is not connected to the core language developers. That is 
actually how it works with any successful language. If you think 
you could do a better job dealing with the rough edges, just go 
ahead and do it. You don't need permission. That's how open 
source works, and indeed, the fact that you don't need permission 
is the point of open source.
Jul 12 2018
parent Mark <smarksc gmail.com> writes:
On Thursday, 12 July 2018 at 14:49:14 UTC, bachmeier wrote:

 AFAICT, the money goes to internal compiler work to add new 
 features to the language in order to appeal to C++ users.


Well, there's also the redesign of the Phobos collections.

I don't know if attracting C++ users is currently a specific goal 
of the D Foundation, but if it is, I suggest listening to the 
complaints that C++ users make (about C++, not D), e.g. [1]. 
Ironically, some of the common complaints, like incomprehensible 
error messages (for templates, anyway), are also common 
complaints about D.

[1] 
https://www.reddit.com/r/cpp/comments/7lvteh/what_are_the_weakest_points_of_c_in_your_opinion/
Jul 15 2018
prev sibling parent reply wjoe <none example.com> writes:
On Tuesday, 10 July 2018 at 17:25:11 UTC, Yuxuan Shui wrote:

 (Although I don't quite agree with you. Some people DO resist 
 change, that's why some decades old languages are still 
 popular. But look at the popularity of new languages like Go, 
 and Rust, and the ever-change landscape of front-end 
 development. There're tons of people who adapt certain 
 technology just because it is new, why can't that happen to D?)


Because they are humans.
Because the masses fly to hip stuff like moths to light.
Because people make decisions out of a mood or because of peer 
pressure and based on opinion rather than facts.
Because a lot of people use it so it can't be bad !?

You can see that phenomenon in Hardware and end user software and 
really every other aspect of life, too, by the way. It's almost 
always the hyped shh-stuff that gets wide spread use.

How many of these people are using it because they want to ? How 
many are happy with the language, rather than just being part of 
the flock ? To be able to call oneself hip ? To be part of the 
group ?

Whether or not rust, go, etc. are just as or more popular than 
C++ or Java in 30 years remains to be seen.
Jul 12 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Thursday, 12 July 2018 at 12:07:55 UTC, wjoe wrote:

 On Tuesday, 10 July 2018 at 17:25:11 UTC, Yuxuan Shui wrote:
 Whether or not rust, go, etc. are just as or more popular than 
 C++ or Java in 30 years remains to be seen.


Rust and Go have their strengths, but also suffer from serious 
usability flaws, so I'm not sure they can become as predominant 
as C++ in the years to come.

At the moment, developing in Rust can be quite painful because of 
too much focus on its borrow checker, as the reference counting 
system is just a side feature, which is not deeply integrated 
into the language.

And Go suffers from its own problems, mainly related to the 
excessive limitation of the language features (no genericity, 
"fake" class inheritance, etc).

De facto they are already making room for another language to 
ultimately fill those gaps...

This may be Crystal, D or another yet to come language...
Jul 13 2018
parent reply RhyS <sale rhysoft.com> writes:
On Friday, 13 July 2018 at 13:15:07 UTC, Ecstatic Coder wrote:

 At the moment, developing in Rust can be quite painful because 
 of too much focus on its borrow checker, as the reference 
 counting system is just a side feature, which is not deeply 
 integrated into the language.

 And Go suffers from its own problems, mainly related to the 
 excessive limitation of the language features (no genericity, 
 "fake" class inheritance, etc).


Those are are big items but its the small stuff that more 
frustrates. Just deal with some database result fetching. In 
dynamic languages that is maybe a 5 line of code, Go makes it 4 
or 5 times as big. Its just a bit too unwieldy.


 De facto they are already making room for another language to 
 ultimately fill those gaps...

 This may be Crystal, D or another yet to come language...


Crystal maybe ... but the link Ruby / RoR does create a bit of a 
artificial barrier. I do notice that Ruby ( not Rails ) is 
getting more recognition these days.

D ... i am being honest but i do not see it. D really has a lot 
going for it but frankly, the missing default HTTP server is just 
silly these days. And no, again, Vibe.D is not a  good 
alternative when it breaks on just about every D release or does 
not perform multi thread correctly ( look up the documentation. 
Out of date and full of unused information ).

What i personally miss is a compile language that simply gets the 
job done.

Take PHP for instance, horrible issues ( a lot less as they 
cleaned up a lot over the years ) but its most redeeming feature 
is it gets the job done. It does not force you into a specific 
pattern, its fast go get visual results, its backward 
compatability is impressive ( hint hint D ), it just works out of 
the box with ease.

Javascript ( the newer ES version + Node ) also match this more.

D looks usable at first for people coming from dynamic languages 
but they are quickly overwhelmed with the whole C/C++ focus.

Crystal is bridging that gap but its still more or less Ruby. So 
it needs to deal with some of the reputation issues.

Where is our Java / C like alternative. Swift? Unfortunately 
Apple has no interest outside of its own platform and Linux 
support is spotty.

Kotlin/Native? Its moving fast and most people do not realize 
this. But a long time from finished.

Zig? Kind of a C alternative.


If there is a language out there that gaps that C/Java/dynamic 
fast and easy feel, and offers the ability to compile down with 
ease. I have not seen it.
Jul 13 2018
next sibling parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote:

 On Friday, 13 July 2018 at 13:15:07 UTC, Ecstatic Coder wrote:

 At the moment, developing in Rust can be quite painful because 
 of too much focus on its borrow checker, as the reference 
 counting system is just a side feature, which is not deeply 
 integrated into the language.

 And Go suffers from its own problems, mainly related to the 
 excessive limitation of the language features (no genericity, 
 "fake" class inheritance, etc).


 Those are are big items but its the small stuff that more 
 frustrates. Just deal with some database result fetching. In 
 dynamic languages that is maybe a 5 line of code, Go makes it 4 
 or 5 times as big. Its just a bit too unwieldy.


 De facto they are already making room for another language to 
 ultimately fill those gaps...

 This may be Crystal, D or another yet to come language...


 Crystal maybe ... but the link Ruby / RoR does create a bit of 
 a artificial barrier. I do notice that Ruby ( not Rails ) is 
 getting more recognition these days.

 D ... i am being honest but i do not see it. D really has a lot 
 going for it but frankly, the missing default HTTP server is 
 just silly these days. And no, again, Vibe.D is not a  good 
 alternative when it breaks on just about every D release or 
 does not perform multi thread correctly ( look up the 
 documentation. Out of date and full of unused information ).

 What i personally miss is a compile language that simply gets 
 the job done.

 Take PHP for instance, horrible issues ( a lot less as they 
 cleaned up a lot over the years ) but its most redeeming 
 feature is it gets the job done. It does not force you into a 
 specific pattern, its fast go get visual results, its backward 
 compatability is impressive ( hint hint D ), it just works out 
 of the box with ease.

 Javascript ( the newer ES version + Node ) also match this more.

 D looks usable at first for people coming from dynamic 
 languages but they are quickly overwhelmed with the whole C/C++ 
 focus.

 Crystal is bridging that gap but its still more or less Ruby. 
 So it needs to deal with some of the reputation issues.

 Where is our Java / C like alternative. Swift? Unfortunately 
 Apple has no interest outside of its own platform and Linux 
 support is spotty.

 Kotlin/Native? Its moving fast and most people do not realize 
 this. But a long time from finished.

 Zig? Kind of a C alternative.


 If there is a language out there that gaps that C/Java/dynamic 
 fast and easy feel, and offers the ability to compile down with 
 ease. I have not seen it.


Indeed Kotlin/Native is becoming VERY impressive these days, as 
it will be usable both for server-side and client-side 
development, including to develop mobile applications for iOS and 
Android.

https://github.com/jetbrains/kotlinconf-spinner

One other very promising language, which almost nobody knows, is 
Crack, as it's quite performant and could be used to implement 
practically anything (web servers, games, etc), as it uses 
automatic reference counting instead of garbage collection.

Sad it has absolutely no community (45 Github stars, including 
mine), and thus will probably stagnate in its current unfinished 
state (no weak references, fibers, channels, etc).
Jul 13 2018
prev sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote:

 If there is a language out there that gaps that C/Java/dynamic 
 fast and easy feel, and offers the ability to compile down with 
 ease. I have not seen it.


There's no silver bullet, you can choose from what exists or 
create your own. Recently we got a CI service that tests some 
packages from dub, that should deal with regressions.
Jul 16 2018
parent Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Monday, 16 July 2018 at 07:49:33 UTC, Kagamin wrote:

 On Friday, 13 July 2018 at 19:30:07 UTC, RhyS wrote:

 If there is a language out there that gaps that C/Java/dynamic 
 fast and easy feel, and offers the ability to compile down 
 with ease. I have not seen it.


 There's no silver bullet, you can choose from what exists or 
 create your own.


If D could be used with automatic reference counting (with native 
weak references with OPTIONAL automatic cycle collection), while 
remaining easy to interoperate with C++, that could be a good 
candidate...

I mean having something like that :

T* pointer on any type (scalar, struct, class)
T strong reference on a class
T^ weak reference on a class

And have --arc and --acc as compiler options.

PS: I know this won't happen unless I implement it myself, I got 
the message... ;)
Jul 16 2018
prev sibling parent reply RhyS <sale rhysoft.com> writes:
On Friday, 6 July 2018 at 20:16:36 UTC, Ecstatic Coder wrote:

 Pfff, it was just an EXAMPLE of how some insignificant string 
 concatenation code may eventually be a problem in any GC 
 language even if it's done only once per frame.


It does not matter that your point is a example. People will rip 
it apart a dozen times.  "the only winning move is not to play."

D will never be a industry accepted game engine replacement 
language ( beyond the few hard core people ). The whole GC is 
irrelevant from the start. Without GC D is barely a better C. 
With GC your forced to do more work to avoid the GC issues ( 
compared to C++ ). D has almost no resources for game developer. 
Few qualified D developers. Let alone the resource that are 
required. And the issues.

No company in their right mind will ever pick D for developing a 
**high performance** game engine. D barely keeps up with there 
own internal issues. So this idea that D has any hope as a Game 
Engine language ( beyond hobby projects and the oneof company 
with some D die hards ), is just ridiculous.

There is simply more change for a new language with more public 
traction to be picked for game engines in the future if C++ dies 
out, then D. That is a fact.

And a person does not need to be a troll to dare say this. D has 
a limited growth and its easy to see...

Just 6 days ago i posted this here:


 Total 1336 packages found.
 3359 total shards


D has had a major release.
Crystal has had a minor release.


 Total 1339 packages
 3382 total shards


D has gained 3 packages. Crystal has gained 23 packages.

Lets trow from a different angle. Updates: Crystal has 37 shard 
updates in 24 hours. D has 7 packages updates in the same time.

If a 16 year old language that pushes itself as a C++ replacement 
language can not keep up with a newcomer like language. And dare 
i mention Go, Rust, ...

I see a lot of people talking on the D forum. But few actually do 
a lot. I see few people talking on Crystal forums but a lot of 
people actually busy coding. Different mindset?

If i can be frank, even if the D community magically solves a lot 
of their internal issues, its hard to make a comeback in this 
industry. Its like Pascal has a change to become popular again. 
And i am sure that Pascal people will defend their languages just 
as much as the D people, pointing out more downloads and more 
activity.
Jul 06 2018
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote:

 Total 1336 packages found.
 3359 total shards


 D has had a major release.
 Crystal has had a minor release.


 Total 1339 packages
 3382 total shards




This is a really weak point, because it doesn't show the quality 
of the packages.

Just look at npm.
Jul 10 2018
parent RhyS <sale rhysoft.com> writes:
On Tuesday, 10 July 2018 at 10:48:30 UTC, bauss wrote:

 On Friday, 6 July 2018 at 23:27:57 UTC, RhyS wrote:

 Total 1336 packages found.
 3359 total shards


 D has had a major release.
 Crystal has had a minor release.


 Total 1339 packages
 3382 total shards




 This is a really weak point, because it doesn't show the 
 quality of the packages.

 Just look at npm.


That is a straw man argument.

I challenge you to see the packages and compare:

https://crystalshards.xyz/?sort=updated&page=1
https://code.dlang.org/?sort=updated

And then tell about the quality.
Jul 12 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jul 06, 2018 at 05:16:54PM +0000, Ecstatic Coder via
Digitalmars-d-announce wrote:

 Are you seriously going to ignore video games that are entirely

 ISSUE IF YOU KNOW WHAT YOU ARE DOING!
 
 -Alexander


 
 +1
 
 Indeed ABSOLUTELY NO garbage collection will happen during the game
 loop is 100% of your GC-language code doesn't make any string
 concatenation, object allocation, etc.


[...]

	import core.memory;
	GC.disable();
	string s;
	foreach (i; 0 .. 1_000_000) {
		s ~= "look ma! no GC collection happens!";
	}
	...
	GC.collect();	// GC collection happens here
	...
	GC.enable();	// go back to "default" GC behaviour


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Jul 06 2018
prev sibling next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 14:52:46 UTC, 12345swordy wrote:

 On Friday, 6 July 2018 at 14:11:05 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 13:50:37 UTC, 12345swordy wrote:

 [...]


 +1

 Just one silly question.

 Can the following "naive" D code trigger a garbage collection 
 stall ?

 score.Text = point_count.to!string() ~ " POINTS";


 The correct answer is: I don't know, as I don't know what 
 "point_count" is in the first place, as it never been defined.

 -Alex


 Actually you answer was right even if the point count was not 
 stored as an integer ;)

 For C++, the answer is : never.

 Two small memory blocks will have to be allocated from the 
 memory pool, which is not smart, obviously, but apart of that, 
 nothing to worry about.

 Because there is no garbage collector in C++, memory has to be 
 allocated and deallocated in a continuous manner...



https://www.dotnetperls.com/string-join function as it simpler 
and faster.
There is no reason why we can't have the function equivalent in D.

-Alexander
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:

 the https://www.dotnetperls.com/string-join function as it 
 simpler and faster.
 There is no reason why we can't have the function equivalent in 
 D.

 -Alexander


Yeah I know, this code was DELIBERATLY naive.

That was the whole point of it.
Jul 06 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 17:04:37 UTC, Ecstatic Coder wrote:


 the https://www.dotnetperls.com/string-join function as it 
 simpler and faster.
 There is no reason why we can't have the function equivalent 
 in D.

 -Alexander


 Yeah I know, this code was DELIBERATLY naive.

 That was the whole point of it.


Misuse of tools is not an argument against the tools themselves. 
Blaming the GC for your "naive" code, is equivalent to a 
carpenter blaming his hammer for his error when the hammer is in 
fine shape.

As I said before, the GC is not an issue if you know what you are 
doing.

-Alexander
Jul 06 2018
prev sibling parent Kagamin <spam here.lot> writes:
On Friday, 6 July 2018 at 15:19:33 UTC, Ecstatic Coder wrote:

 Actually you answer was right even if the point count was not 
 stored as an integer ;)

 For C++, the answer is : never.

 Two small memory blocks will have to be allocated from the 
 memory pool, which is not smart, obviously, but apart of that, 
 nothing to worry about.

 Because there is no garbage collector in C++, memory has to be 
 allocated and deallocated in a continuous manner...


Recently it got somewhat pushed by Electron applications :)
Jul 11 2018
prev sibling parent reply wjoe <none example.com> writes:
On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 Just by curiosity, can you tell me how many successful 
 commercial games based on a D game engine are released each 
 year ?


Just out of curiosity, how many games have been released based on 
a C++ game engine in 1998 ?


The original Unreal engine was almost completely written in asm, 
back in the late 90ies.

The first C++ game engine I found was the Object Oriented 
Graphical Redering Engine, started some time around 2001.

Carmack resisted C++ for a longer time and I believe I read 
something about the engine was  ported to C++ when they developed 
Id Tech 4 around 2004.
Jul 06 2018
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
On Friday, 6 July 2018 at 15:07:41 UTC, wjoe wrote:

 On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote:

 Just by curiosity, can you tell me how many successful 
 commercial games based on a D game engine are released each 
 year ?


 Just out of curiosity, how many games have been released based 
 on a C++ game engine in 1998 ?


 The original Unreal engine was almost completely written in 
 asm, back in the late 90ies.

 The first C++ game engine I found was the Object Oriented 
 Graphical Redering Engine, started some time around 2001.

 Carmack resisted C++ for a longer time and I believe I read 
 something about the engine was  ported to C++ when they 
 developed Id Tech 4 around 2004.


Actually, as I said, even today many game engines are still 
written in a C-inspired manner, i.e. C + classes, templates and 
polymorphism, mainly for performance reasons (cache friendly data 
oriented designs, etc).
Jul 06 2018
parent wjoe <none example.com> writes:
On Friday, 6 July 2018 at 15:30:22 UTC, Ecstatic Coder wrote:

 On Friday, 6 July 2018 at 15:07:41 UTC, wjoe wrote:

 [...]


 Actually, as I said, even today many game engines are still 
 written in a C-inspired manner, i.e. C + classes, templates and 
 polymorphism, mainly for performance reasons (cache friendly 
 data oriented designs, etc).


You can do that in D.
Jul 06 2018
prev sibling parent reply Maksim Fomin <mxfm protonmail.com> writes:
On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote:

 I never ever (I think) did something provocative, something to 
 finally see:
...<rest text is skipped>


My 5 cents inspired by experimenting with D some years ago.

1. Programming became niche oriented and quite diverse. Writing 
new language requires significant manpower.
2. D manpower is not sufficient for finishing language in low 
level niche. AFAIK Walter estimated manpower around 2013 to be 
equivalent of bus factor of 10. This is not enough to deliver 
stable language, it will always be "tasted as raw" comparing with 
c++.
3. D strategic mistake is ad-hoc design. Some features are added 
or extended and because of complexity result in corner cases 
(this is exacerbated because sometimes backward compatibility is 
preserved and sometimes not). Fixing corner cases sometimes 
produces more questions. As a result language has some mess which 
is unlikely to be fixed coherently (c++ is at least a documented 
mess).
4a. Limited developers' efforts are consumed by fixes and 
internal code optimization rather than important issues.
4b. Dips (related to language design) mostly fail because 
proposal authors do not write code and developers are busy.
5. My view of D future. Walter and developers will continue to 
improve and develop D but at low pace. Low-level niche will be 
dominated by c++ as a common denominator. D and some alternative 
languages would compete for different parts of this niche. In 
long-term low-level niche will be broken into smaller niches with 
languages specializing in them. Being "just low level" would be 
wrong as "just language". This would raise questions what D goal 
is.

I am from area of economic, financial and scientific calculations 
used in decision making. It is dominated by python, c++ and 
statistical software. In most cases it does not require absolute 
speed (except financial markets rt trading, big data processing 
or some hard mathematical problems which are relevant for 
researchers in top institutions with supercomputers). It is hard 
for me to provide arguments for using D (meaning from 
professional area view) because c++ can be used for performance 
and D is poor in statistical libraries. Because it is applied 
area nobody cares whether exceptions have root class or whether 
virtual is default.
Jul 04 2018
parent bachmeier <no spam.net> writes:
On Wednesday, 4 July 2018 at 20:17:59 UTC, Maksim Fomin wrote:


 I am from area of economic, financial and scientific 
 calculations used in decision making.


So am I.


 It is hard for me to provide arguments for using D (meaning 
 from professional area view) because c++ can be used for 
 performance and D is poor in statistical libraries. Because it 
 is applied area nobody cares whether exceptions have root class 
 or whether virtual is default.


What statistical libraries do you need? I can embed an R 
interpreter inside a D program, so D provides all R 
functionality. Furthermore, any compiled code for which there is 
an R interface also has a D interface. There are various C 
libraries that are easy enough to call from D. At least for the 
things I do, I have not run into any constraints librarywise, 
though sometimes I have to do a little work to call into existing 
libraries.
Jul 06 2018