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