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...

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

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

> 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.

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?

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

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...

> 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.

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.

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.