www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Doesn't GC, nogc, safe, nothrown, * get in the way of getting things

reply aberba <karabutaworld gmail.com> writes:
In D we have so many programming models and I'm noticing this has 
become a problem in itself.

For a example should a new HTTP library become safe, or unsafe, 
gc or no gc? Template or no templates, reference counting?? 
 live??

So unless its a third party library deciding to go with whatever 
they want, its going to end up in an immposible to match up to 
the technical expectations of everyone.

Phobos is a mix of several models which sometimes fight against 
each other. And this never gets solved cus its impossible.

What becomes the ideal trade-off??
Jun 11
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 11/06/2020 11:28 PM, aberba wrote:
 In D we have so many programming models and I'm noticing this has become 
 a problem in itself.
 
 For a example should a new HTTP library become safe, or unsafe, gc or no 
 gc? Template or no templates, reference counting??  live??
Client or server? Each has a different answer.
Jun 11
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 11 June 2020 at 11:31:31 UTC, rikki cattermole wrote:
 On 11/06/2020 11:28 PM, aberba wrote:
 In D we have so many programming models and I'm noticing this 
 has become a problem in itself.
 
 For a example should a new HTTP library become safe, or 
 unsafe, gc or no gc? Template or no templates, reference 
 counting??  live??
Client or server?
When building an API for others to consume. HTTP is just an example.
 Each has a different answer.
Jun 11
parent ikod <geller.garry gmail.com> writes:
On Thursday, 11 June 2020 at 12:43:00 UTC, aberba wrote:
 On Thursday, 11 June 2020 at 11:31:31 UTC, rikki cattermole 
 wrote:
 On 11/06/2020 11:28 PM, aberba wrote:
 In D we have so many programming models and I'm noticing this 
 has become a problem in itself.
 
 For a example should a new HTTP library become safe, or 
 unsafe, gc or no gc? Template or no templates, reference 
 counting??  live??
Client or server?
When building an API for others to consume. HTTP is just an example.
 Each has a different answer.
I prefer my code be both nogc and safe. In case when library depend on user code (like for example hashmap or lists) I let language to infer library code properties from user-supplied objects/structs.
Jun 11
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 11 June 2020 at 11:28:07 UTC, aberba wrote:
 In D we have so many programming models and I'm noticing this 
 has become a problem in itself.

 For a example should a new HTTP library become safe, or unsafe, 
 gc or no gc? Template or no templates, reference counting?? 
  live??

 So unless its a third party library deciding to go with 
 whatever they want, its going to end up in an immposible to 
 match up to the technical expectations of everyone.

 Phobos is a mix of several models which sometimes fight against 
 each other. And this never gets solved cus its impossible.

 What becomes the ideal trade-off??
From my point of view, as I approach this in D and other managed languages. By default safe with GC, profile and optimize where required with nogc and other similar allocation free techniques. Unsafe code blocks only as last resort or dealing with OS APIs. On my case, I seldom need to do otherwise, performance is more than acceptable to meet customer requirements. I don't care about winning micro-benchmarks, rather happy customers. Your millage may vary.
Jun 11
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jun 11, 2020 at 11:28:07AM +0000, aberba via Digitalmars-d wrote:
 In D we have so many programming models and I'm noticing this has
 become a problem in itself.
 
 For a example should a new HTTP library become safe, or unsafe, gc or
 no gc?  Template or no templates, reference counting??  live??
My approach is: 1) Code minimalistically: if it's not too onerous to code without using the GC, then code for no GC. If it's possible to get by with safe, then make do with safe instead of dropping to system. If it's possible to be pure, strive to be pure. If it's possible to use const, do so. Etc. To help with (1): 2) Code defensively: assume nothing other than the most essential, indispensible assumptions to get the job done. IOW, use as few assumptions as possible for your code to get its job done. If your function can get the job done with 1 parameter and avoid the GC, then don't add extra parameters just to handle some rare special case, and don't assume the GC when it isn't absolutely necessary. Offload complexity to the caller where it makes sense: e.g., instead of including complex special-case handling inside your function, what about accepting a delegate parameter that the caller can use to encode this complexity, while your function focuses on its primary job? Coding defensively generally also leads to more reusable code. Which leads to: 3) Code generically: for the most part, avoid actually putting attributes on anything. Instead, use templates -- yes, definitely use templates, it's one of the biggest strengths of D in spite of its flaws -- and let the compiler figure out the attributes for you. Use attributes on unittests that call that function to ensure that the function body itself is pure, nogc, etc., without putting any attributes on the function itself. Why? Because then your function can be called with impure, GC, throwing, etc., arguments. Don't exclude any users if possible. 4) Code realistically: if going nogc, etc., will imply reinventing an entire infrastructure from scratch and take more effort than solving the problem domain itself, then just use the GC, use system, ... etc., to get the project off the ground. The GC is there for a reason; unless you're targeting the very specific and narrow nogc niche, there's no need to bend over backwards to please that crowd. Use what you need to get your job done (but no more than that -- see (1) and (2)).
 So unless its a third party library deciding to go with whatever they
 want, its going to end up in an immposible to match up to the
 technical expectations of everyone.
Of course it's impossible to please everyone. That's why you have to decide which audience you're targeting, and code accordingly. Writing *completely* generic code, in general, is quite hard. See Phobos for example. ;-)
 Phobos is a mix of several models which sometimes fight against each
 other.  And this never gets solved cus its impossible.
Any specific examples? In general, I find Phobos quite pleasant. (Other than some obsolete modules that I tend to avoid anyway.) Where's this "mix of several models which sometimes fight against each other"? T -- Without geometry, life would be pointless. -- VS
Jun 11
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 11 June 2020 at 15:13:39 UTC, H. S. Teoh wrote:
 Phobos is a mix of several models which sometimes fight 
 against each other.  And this never gets solved cus its 
 impossible.
Any specific examples? In general, I find Phobos quite pleasant. (Other than some obsolete modules that I tend to avoid anyway.) Where's this "mix of several models which sometimes fight against each other"?
I believe he means name clashes, for example, `std.algorithm.copy` and `std.file.copy`. Fortunately this is relatively easy to avoid with D:s powerful imports. IMO it only gets annoying if one is importing too aggressively anyway (I had that habit before).
Jun 11
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Thursday, 11 June 2020 at 11:28:07 UTC, aberba wrote:
 What becomes the ideal trade-off??
In my opinion, in principle almost everything should be ` safe` and `pure`. With ` safe`, it's mainly the interfaces to other languages and some low-level memory handling or typecasting that needs to be ` system`. This applies even to system programming: If you look at the source of Powernex, surprisingly large parts of it are ` safe` even when it's obviously very low level stuff. With `pure`, IO is the main thing that can't be pure, pretty much everything else should be. You usually should not need global variables, so you should not need impurity either. In practice, though, the annotations tend to be leaved off because some library function being called does not use the attributes. In case of ` safe`, one can work around this with ` trusted`, but doing `pure` interface to such a library might require too dirty hacks to be worth it. With `nothrow` and ` nogc` it's more situation and taste dependant. A general rule of thumb is that the lower level the code, the more likely you want to use them. Also the return of investment with these attributes isn't as high as with the first two. They might not be worth the effort for a typical application if they require any significant rethinking, even if the function should in principle have the attributes.
Jun 11
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 11 June 2020 at 11:28:07 UTC, aberba wrote:
 In D we have so many programming models and I'm noticing this 
 has become a problem in itself.
Yes, chances are you can't use a library because you are using a particular subset. On the plus side, being limited in 23rd-party deps is good for debt control.
 So unless its a third party library deciding to go with 
 whatever they want, its going to end up in an impossible to 
 match up to the technical expectations of everyone.
 What becomes the ideal trade-off??
For a while it has been: ignore pure, ignore shared, ignore nothrow, avoid const, ignore safe... and then you can actually get things done in D. D needs to keep being appealing to practical minds and remove stuff that isn't bringing enough value, quickly. Anytime I say this, someone says "but pure has practical applications" but I strongly dispute the validity of the afore-mentionned features, they are just feelgood features that (for a few) occasionally found a bug or two. If people came to D for being able to think about their problem domain, then less cruft is going to make D an even clearer language.
Jun 12
parent aberba <karabutaworld gmail.com> writes:
On Friday, 12 June 2020 at 12:21:24 UTC, Guillaume Piolat wrote:
 On Thursday, 11 June 2020 at 11:28:07 UTC, aberba wrote:
 [...]
Yes, chances are you can't use a library because you are using a particular subset. On the plus side, being limited in 23rd-party deps is good for debt control. [...]
I honestly didn't expect you to say this. Interesting to see this. +1
Jun 12