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
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)... So this C# pal comes and says like I offered him a drink with sandwich (for free!!) and he doesn’t like it - vegetarian(!). Okay: - I want async and await and async function and ALL of thay stuff from C# in D language ( I wait for a few moments to “compose” myself!) - So you want D to succeed (I mean C# is there and you seem to 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
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 drivers, often faster than Java, C#, Dart, etc) despite it lacks several core feature many developers need (generics, etc). Once Crystal integrates parallelism (at 1.0), it should become de facto one of the best alternative to Go, Java, C#, 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. Nim disqualifies itself because contrarily to D and C# for 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
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
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
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
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. # A very basic HTTP server require "http/server" server = HTTP::Server.new do |context| context.response.content_type = "text/plain" context.response.print "Hello world, got #{context.request.path}!" 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
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.

 # A very basic HTTP server
 require "http/server"

 server = HTTP::Server.new do |context|
   context.response.content_type = "text/plain"
   context.response.print "Hello world, got 
 #{context.request.path}!"
 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
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
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
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
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 
 de facto one of the best alternative to Go, Java, C#, 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.
Jun 29
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 
 de facto one of the best alternative to Go, Java, C#, 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.
Jun 29
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 
 become de facto one of the best alternative to Go, Java, C#, 
 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
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 
 become de facto one of the best alternative to Go, Java, C#, 
 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
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, 
 C#, 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.
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
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, 
 C#, 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.
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
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
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
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
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
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
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
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
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
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 C++ instead of Java/C#/Go/etc, there is a reason for that. 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 languages (Go/Java/C#/etc) can be convinced to switch to D, 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 OBVIOUSLY CAN'T BE CONVINCED that marketing D as a Go/Java/C# 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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: #!/usr/bin/env dub /+ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 
model is actually superior to C#'s, and while it's not 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 
forming, and I have some concern they'll go down the C# route 
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
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 
 fiber model is actually superior to C#'s, and while it's not 
 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 
 forming, and I have some concern they'll go down the C# route 
 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
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
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 
 fiber model is actually superior to C#'s, and while it's not 
 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 
 forming, and I have some concern they'll go down the C# route 
 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
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
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
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
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. Plenty of games are made in C#, too. 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
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
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
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. Look at C#, Java, Javascript. They have GC, do people complain 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
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. Plenty of games are made in C#, too. 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
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
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
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. Plenty of games are made in C#, too.
+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
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
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
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
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
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". Which would be the #1 problem for me, because "standard" D is perfect to me, as much as "standard" C++ is nice to me. That's my point.
Jul 06
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".

 Which would be the #1 problem for me, because "standard" D is 
 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
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
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
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
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
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
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
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
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
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
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 do, for example Java can't do, C# can partially do that 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.
Jul 06
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 can do, for example Java can't do, C# can partially do that 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
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
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 loop in a garbage collected language like Java, C#, etc, and not 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
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
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
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
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
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
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
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 implemented in GC focus language such as C#/java?! The GC is NOT AN ISSUE IF YOU KNOW WHAT YOU ARE DOING! -Alexander
Jul 06
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Are you seriously going to ignore video games that are entirely 
 implemented in GC focus language such as C#/java?! The GC is 
 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
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 
 entirely implemented in GC focus language such as C#/java?! 
 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
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 
 entirely implemented in GC focus language such as C#/java?! 
 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
 implemented in GC focus language such as C#/java?! The GC is 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.
[...] 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
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...
Also if your concatenate string in a loop in c# then you use 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
Jul 06
parent reply Ecstatic Coder <ecstatic.coder gmail.com> writes:
 Also if your concatenate string in a loop in c# then you use 
 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
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 6 July 2018 at 17:04:37 UTC, Ecstatic Coder wrote:
 Also if your concatenate string in a loop in c# then you use 
 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
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
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
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
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
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
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