June 29, 2020
On Monday, 29 June 2020 at 22:44:51 UTC, IGotD- wrote:
> On Monday, 29 June 2020 at 22:23:57 UTC, Guillaume Piolat wrote:
>>
>> In reality you can actually disable the GC and still use:
>> - classes
>> - associative arrays (dplug:core)
>> - dynamic arrays if you manage their lifetime
>>
>
> Honestly, a guide how to do this would be very helpful.

Yes, the answers are complex but I think it could be recap in a nice table (features vs level of GC avoidance).
June 30, 2020
On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
> On Mon, 2020-06-29 at 10:31 +0000, IGotD- via Digitalmars-d-announce wrote:
>> 
>
> On the other hand people are stopping using C++ in favour of Go, Rust, Python, but it seems not D.

This isn't a fact by the way, there are many people using D, including folks I never expected. We could use more PR though.

In D's case, its PR, its what I'm looking to do something about.
June 30, 2020
On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:

> Sometimes there is only one way to find out why it behaves like it does: to ask in this forum. And you may not like the answers. D has transitive const, but what if I should lazy evaluate/cache a value or use a mutex? If I shouldn't use const, how should I emphasize the intention to pass a pointer only for reading? How can I be sure that my class invariant is not compromised? Also, there is the shared attribute, but it isn't designed nor implemented well. Lots of questions, no solutions. D is intended to be a C++ replacement, but it doesn't explain to C++ programmers how to change their way of thinking. I'd appreciate if there was a document that explains typical tasks and ways to get them done in D for the C++ dummies, like me.

This calls for a D-idioms for C++ folks. Its overlooked but I believe its very important to have. Folks who know the language might overlook this but can be of great help for new recruits. Considering that's the goal...at least my goal :)

It requires someone with C++ knowledge to start, then we'll take care of driving in more idioms. Like a GitHub wiki or something. The D wiki more appropriately for centralization.

Anyone up for it?

June 30, 2020
On Monday, 29 June 2020 at 15:54:36 UTC, Adam D. Ruppe wrote:
> On Monday, 29 June 2020 at 15:45:48 UTC, Dagmar wrote:
>> D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else.
>
> You just have to construct them with a function instead of with the built-in `new` operator. (Well, associative array will need a library solution picked too, but the rest work build in if you construct them differently.)
>
> It is very easy to do, just perhaps not well documented.

Ditto. Hence the need for documenting them.
June 30, 2020
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
> On 6/29/20 8:45 AM, Dagmar wrote:

> > If I shouldn't use
> > const, how should I emphasize the intention to pass a pointer
> only for
> > reading? How can I be sure that my class invariant is not
> compromised?
> > Also, there is the shared attribute, but it isn't designed nor
> > implemented well. Lots of questions, no solutions. D is
> intended to be a
> > C++ replacement, but it doesn't explain to C++ programmers
> how to change
> > their way of thinking.
>
> There is this dated document:

>  https://dlang.org/articles/cpptod.html

Ali, how you answered the questions is how I think one would want to find a document for C++ folks moving to D. The outdated doc I believed focused mostly on the syntactic differences which I agree we now need someone to help get it up to date with more coverage.

But a document with answers to common practical questions like just liked the above... const, shared, GC, etc doesn't seem to fit in the that doc. I believe you've pretty much said some things that we can work on to get things documented. I'm sure there's more similar questions.

So a D-idioms-like kind of doc/wiki might do. Of course, in addition to the cpptod.html one.

https://p0nce.github.io/d-idioms/
July 01, 2020
On Mon, 2020-06-29 at 20:41 +0000, Paulo Pinto via Digitalmars-d-announce
wrote:
[…]
> 
> Rust has only standardized part of the async/await story, the
> asynchronous
> runtime is not part of the standard library, so currently it is
> impossible to write code that works flawlessly across the
> existing runtimes.
[…]

Actually this is a good thing in that I can write Rust async/await code and have it run on the GTK event loop. Here we have a case of multiple vendor implementations of a single standard interface. The problems tend to be in the implementations of the event loops not the bit that is effectively (de facto rather than de jure) standardised.

[…]
> The typical scenarios where we would use GPGPU shaders, iDevices, Android and Windows drivers, Arduino, SYCL, DPC++, Unreal, XBox/PS/Switch SDKs, ...

Not my area, but my guess is that there is sufficient pre-existing code base
that it is not feasible to switch languages, staying with the languages of the
pre-existing codebase is the sensible thing to do unless someone comes along
with a big pot of money.

[…]
> Java has a standard to guide for, updated for each language release.
> 
> So it doesn't need to be ISO, can be ECMA, or some other formal writen  specification, with multiple vendor implementations.

Java is really standardised by the implementaion of OpenJDK. There is no standard agreed by any formal body other than the JCP executive committee. There are three maybe four implementations, the one everyone uses, and the other you have to pay for.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



July 01, 2020
On Mon, 2020-06-29 at 15:44 +0000, Patrick Schluter via Digitalmars-d-announce wrote:
> 
[…]
> And that is completely wrong headed. Internet is not always directly accessible. There are a lot of companies that restrict access to the Internet for their security sensible servers,
> 
[…]
> No, Internet is not always as easy peasy and having a language that can live alone and provide quite a lot of features without always calling home is a good thing.
> 
[…]

So that is Java out then as a language to use for corporate software development activity.

Way back when I was running a company or two, I put in place "you can't access the internet directly for dependencies" system, more to lower bandwidth use than security it has to be said. So we bought another disc and mirrored the repository – but not slavishly, just the bits we needed and with various scans and tests to try and stop any rogue software. This seemed to be the standard sort of behaviour back then. Perhaps this is not what happens now?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



July 02, 2020
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
> Then don't turn it off. :)
>
> I understand there are programs where an undeterministic delay in processing is unacceptable but those programs all run on real-time operating systems anyway, right? ;)
I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures.

> OOPS: :) I fail to find a reference table that explains implicitly or explicitly deleted or defaulted fundamental C++ operations like the copy constructor.
I agree, C++ is overcomplicated. That's the reason why I look at other languages.

> Yeah, accepting that kind of complexity but rejecting the GC is interesting. (I am not directing this to you but to most C++ programmers.)
Not manual memory management is the main problem in modern C++, but its excessive complexity with thousands of nuances that simply do not allow you to write a program without hidden issues. TBH, I don't suffer bc I have to deal with memory management at all. I understand the point of GC advocates, but among other things, people choose C++ because it gives them more control. A good language should provide the ability to easily ADD a garbage collector, not the ability to cut it off, losing a half of the language features and its standard library.

> That may be true for many languages but when it comes to getting things done I find D much more productive, manageable, easier, etc. etc. compared to C++. C++ has only one thing over D: Many smart people are already using C++.
D has lots of really interesting features and it's more productive than C++, but I find it hard to use in real projects.

> Although I agree that transitive const is the correct feature, I too find it difficult.
Well, I agree that transitive const is a good feature for some use cases. For instance, a function may return a pointer to a constant linked-list node. In the case of non-transitive const you can reach and modify other list nodes through this "constant" pointer, which is not good at all. But introducing transitive const without showing a way to implement caching, using mutexes, etc is not a good idea either. Imagine a class, that protects its data with a mutex. How should I implement a getter function (const) that locks the mutex? The only way that comes into my mind is introducing a global mutex-manager entity that works with mutex handles (integers). Any class that requires a mutex would call this manager to create a new mutex and remembers its handle. This way it can pass this handle to the manager when the mutex should be locked/unlocked. But obviously, this is such a horrible scheme.

> There is this dated document:
>
>   https://dlang.org/articles/cpptod.html
>
> Although dated, that document should be sufficient to jump to D from C++. :)
Not at all. It's not so hard to learn the syntax and other details of a new language. It's hard to adopt it to my needs. This document tells nothing about typical issues that C++ programmers encounter with when trying to do a real work with D.
July 02, 2020
On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:
> To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust.

I think that's a misinterpretation of what was said.  Compatibility is not a reason for success -- but the _absence_ of sufficient compatibility will always lead to failure.

I can't speak for Go, but Rust's compatibility is clearly adequate given how Mozilla is able to fit it inside the (mostly C++) Firefox codebase.
July 02, 2020
On Thursday, 2 July 2020 at 10:13:02 UTC, Dagmar wrote:
> On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
>> Then don't turn it off. :)
>>
>> I understand there are programs where an undeterministic delay in processing is unacceptable but those programs all run on real-time operating systems anyway, right? ;)
> I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures.

If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute.

The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway.

You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use.

Also see this...

https://github.com/AuburnSounds/Dplug