www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Frameworks and libraries

reply Maximilian Naderer <maximilian.wallinger outlook.com> writes:
Hello,

I think D is a great language and a general theme is that 
everybody is complaining about the lack of libraries, frameworks 
and/or bindings to popular C/C++ libraries.

I checked the GitHub repo and so some todos, I would like to 
contribute to the language.

What popular frameworks / libraries would you like to see 
bindings for so that those could be used in D?

Best regards,
Max
Sep 13 2023
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
Naderer wrote:

 Hello,

 I think D is a great language and a general theme is that 
 everybody is complaining about the lack of libraries, 
 frameworks and/or bindings to popular C/C++ libraries.

 I checked the GitHub repo and so some todos, I would like to 
 contribute to the language.

 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?

 Best regards,
 Max


I’d propose to make an analysis of fields and community 
interested areas, but first of all choose

1) you are interested by yourself. So you will be able to support 
and maintain in future. Because abandoned library = dead library 
in D. Or maybe someone else could maintain in future if 
interested enough in a library.

2) those that make max retention and impression for newcomers. 
Some help with hot-topics like WASM would be nice, gtk4 port, c++ 
interop, obj-c in ldc… like many important things could be very 
useful.
Sep 13 2023
parent M.M. <matus email.cz> writes:
On Wednesday, 13 September 2023 at 19:01:58 UTC, Sergey wrote:

 On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
 Naderer wrote:

 ...
 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?
 ...


 2) those that make max retention and impression for newcomers. 
 Some help with hot-topics like .... gtk4 port, ... could be 
 very useful.


Yes to gtk4!
Sep 13 2023
prev sibling next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
Naderer wrote:

 Hello,

 I think D is a great language and a general theme is that 
 everybody is complaining about the lack of libraries, 
 frameworks and/or bindings to popular C/C++ libraries.

 I checked the GitHub repo and so some todos, I would like to 
 contribute to the language.

 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?

 Best regards,
 Max


Two things that might be useful:
1) Find existing D bindings that are more frequently used but 
don't have a wrapper and make a wrapper
2) Go through existing D bindings and see if the project could 
instead be built with importC. Report any importC bugs that come 
up (honestly it probably makes sense to have an importC page on 
the dlang website that summarizes the result of whether it works 
with importC or not).
Sep 13 2023
prev sibling next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
Naderer wrote:

 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?


Anything in the web services sphere would be massively helpful. 
Especially if you wanted to tackle the AWS, Azure, or GCP SDKs. I 
realize that it's interminably boring work, but getting D into 
the cloud space would be an absolutely phenomenal public lift for 
the language.

And any improvements to ImportC you can deliver along the way 
would be improve the lives of the rest of us on the same mission 
as you are. I've got my ImportC ODBC project going well, but I 
have a dream of using ImportC on the the Windows Headers and 
using DI generation to export those headers so that we can all 
use them.
Sep 13 2023
parent user548215 <user548215 gmail.com> writes:
On Thursday, 14 September 2023 at 01:57:37 UTC, Adam Wilson wrote:

 Anything in the web services sphere would be massively helpful.


Currently, I am working on 3 different web projects, all of which 
I am developing in the D programming language. I've also started 
using D for software development for my clients, and it's truly 
an amazing language. Of course, while I try to write my own 
libraries, this is not always sufficient. I wonder how it would 
be to initiate a project within the D community for library 
development?
Sep 14 2023
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
Naderer wrote:

 Hello,

 I think D is a great language and a general theme is that 
 everybody is complaining about the lack of libraries, 
 frameworks and/or bindings to popular C/C++ libraries.

 I checked the GitHub repo and so some todos, I would like to 
 contribute to the language.

 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?

 Best regards,
 Max


We have plenty of bindings, we need native stuff.

C libs will use c strings and may even require turning off the gc 
to make it behave; which means your handcapped and need to append 
null like all the time.
Sep 14 2023
parent reply user548215 <user548215 gmail.com> writes:
On Thursday, 14 September 2023 at 15:11:29 UTC, monkyyy wrote:

 We have plenty of bindings, we need native stuff.

 C libs will use c strings and may even require turning off the 
 gc to make it behave; which means your handcapped and need to 
 append null like all the time.


I predominantly opt for native coding and reserve binding for 
instances where it's absolutely necessary, such as when working 
with libraries like libpq, where binding is often the only viable 
option. If I complete the development of my web framework, I 
intend to make it publicly available. Furthermore, based on the 
discussions I've read about the Garbage Collector in the D 
programming language, I've decided to abstain from using that 
feature.
Sep 14 2023
parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 14 September 2023 at 15:40:30 UTC, user548215 wrote:

 If I complete the development of my web framework, I intend to 
 make it publicly available.


You should use the existing D things.


 based on the discussions I've read about the Garbage Collector 
 in the D programming language, I've decided to abstain from 
 using that feature.


This is a mistaken decision.
Sep 14 2023
next sibling parent reply user548215 <user548215 gmail.com> writes:
On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe 
wrote:


 This is a mistaken decision.


Can you explain why?
Sep 14 2023
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 wrote:

 On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe 
 wrote:


 This is a mistaken decision.


 Can you explain why?


Maybe because experimental.allocators broken by design?
Sep 14 2023
parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 14 September 2023 at 18:53:02 UTC, Sergey wrote:

 On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 
 wrote:

 On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe 
 wrote:


 This is a mistaken decision.


 Can you explain why?


 Maybe because experimental.allocators broken by design?


How so?
Sep 15 2023
prev sibling next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 wrote:

 Can you explain why?


Your framework is prolly gonna be more buggy and harder to use 
for no actual benefit.
Sep 14 2023
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, September 14, 2023 10:30:27 AM MDT user548215 via Digitalmars-d 
wrote:

 On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe

 wrote:

 This is a mistaken decision.


 Can you explain why?


In general, using the GC allows for code that's both safer and cleaner (in
fact,  safe is pretty much impossible for a lot of code without it). It's
also generally easier to write and maintain code that uses a GC rather than
manual memory management. And performance-wise, whether it's better or worse
very much depends on what you're doing.

In general, the GC costs very little until it needs to run a collection, at
which point, the program temporarily stops to try to collect garbage.
Depending on what your program is doing in that section of code, this either
really doesn't matter, or it could be a big problem. If it does matter, then
there are ways to mitigate the problem (e.g. disabling the collector in key
parts of the program or reusing memory so that less garbage is produced, and
there's less memory to scan). In the extreme case, you might need a thread
that doesn't use the GC at all so that you can guarantee that it never stops
(e.g. for real-time applications), but for the vast majority of programs,
you can just use the GC without worrying about it all, and then if profiling
shows that it's become a problem in a particular section of your program,
you deal with that section in whatever manner is most appropriate so that
the GC isn't a problem there. The end result is generally a much more
maintainable program than if you were using manual memory management
everywhere.

Another alternative to a GC is reference counting, which then avoids the
stop-the-world problem that comes with the GC, but the result is that the
cost of handling a collection is amortized across the program as a whole
instead of happening only at key points. So, the program avoids pauses but
is likely to be slower in the rest of the program as a result. You also then
have to worry about pointer/reference cycles in away that GC-managed code
does not (it's why some languages - e.g. python - have a hybrid approach
where they use reference counting for most stuff and then let their GC take
care of the cycles). So, whether reference counting or the GC is better very
much depends on your code, but it's certainly true that some folks prefer
reference counting simply because of a fear that GCs are slow (and they can
be slow depending on what the language or libraries are doing, but they're
not necessarily slow). A lot of the fear about GCs being slow comes from
what the situation was 30+ years ago with languages that used a GC (many of
those being functional languages, which is a very different situation from
what a language like D has).

So, whether the GC is even a problem is very program-dependent, but it
allows us to have language features that we couldn't have otherwise (e.g.
the way that dynamic arrays work in D isn't really possible without a GC;
you have to do a lot more explicit memory management with them if you avoid
using the GC, and that can get far more complex). And using the GC prevents
whole classes of bugs that come with manual memory management. So, avoiding
the GC just because you're afraid that it's going to make your program slow
is going to hamper what you can do in D for arguably minimal benefit. D does
allow you to avoid the GC when you really need to, but using the GC allows
you to write cleaner, more maintainable, less buggy programs than you get
with manual memory management.

Also, while D does allow you to write code without the GC, because it's
generally assumed that you're going to be using it (to the point that some
language features require it), trying to avoid it in your code in general is
likely to just make life harder for you, and if you really want to go that
route, it would arguably be better to just write in C++ where everything is
designed with the idea that you're unlikely to be using a GC. It's one thing
to avoid the GC in specific sections of your code in D, whereas it's quite a
bit more painful to avoid it everywhere.

- Jonathan M Davis
Sep 14 2023
prev sibling next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 wrote:

gc bad


 gc good


 Can you explain why?



 gc very very good *wall-o-text*




There is an extremely important feature of dynamic arrays; you 
sometimes get 8 chars of strings or 100 chars of string and like 
either, you have dynamic arrays or you do the c thing of null 
termination. And the null termination is just terrible.

In d rn; the dynamic arrays are gc'd and they are the only data 
structure worth a damn with the devs dragging their feet on 
adding data structures to "containeers" for some meme about 
allocators.

I don't believe in the technical merit of gc over any other 
possible solution for dynamic arrays; but you don't have all 
possible worlds, d as is, is gc'ed to hell and back and nogc is a 
bandaid to advertise its something its not.
Sep 15 2023
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

 On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 
 wrote:

gc bad


 gc good


 Can you explain why?



 gc very very good *wall-o-text*




 [snip]


But when you don't see the *wall-o-text* for a while, you miss 
it. Glad Jonathan is posting again.
Sep 15 2023
prev sibling parent reply bachmeier <no spam.net> writes:
On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

 d as is, is gc'ed to hell and back


That's why I use it.


 nogc is a bandaid to advertise its something its not.


[This is what the spec 
says](https://dlang.org/spec/function.html#nogc-functions). I 
don't see anything wrong with it. It restricts what you can do 
inside a function and that's what it's supposed to do.
Sep 15 2023
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 15 September 2023 at 16:09:44 UTC, bachmeier wrote:

 On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

 d as is, is gc'ed to hell and back


 That's why I use it.


 nogc is a bandaid to advertise its something its not.


 [This is what the spec 
 says](https://dlang.org/spec/function.html#nogc-functions). I 
 don't see anything wrong with it. It restricts what you can do 
 inside a function and that's what it's supposed to do.


a language includes its std and there's no alternative for std: 
string, algorithm, range to be nogc'ed with a nice easy-to-grab 
data structure. A betterc project is just going to be segmented 
from the rest of d and be a very different project.

If d were to start adding data structures to the std and 1 or 2 
of them happened to work ok with betterc; maybe my answer would 
change. But I really really do mean that d has one data structure 
of note, the built-in dynamic array, and adding more is obviously 
not a priority(despite that being insane).
Sep 15 2023
next sibling parent reply bachmeier <no spam.net> writes:
On Friday, 15 September 2023 at 16:40:38 UTC, monkyyy wrote:


 a language includes its std and there's no alternative for std: 
 string, algorithm, range to be nogc'ed with a nice easy-to-grab 
 data structure. A betterc project is just going to be segmented 
 from the rest of d and be a very different project.

 If d were to start adding data structures to the std and 1 or 2 
 of them happened to work ok with betterc; maybe my answer would 
 change. But I really really do mean that d has one data 
 structure of note, the built-in dynamic array, and adding more 
 is obviously not a priority(despite that being insane).


betterC and  nogc are rather different. You don't have, and 
should not want, a GC in betterC code.  nogc is useful in the 
context of a regular D program that has places you want to 
guarantee the GC won't run. betterC code is perfectly fine to add 
to a regular D project. I do that with Mir.
Sep 15 2023
parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 15 September 2023 at 17:55:49 UTC, bachmeier wrote:

 betterC and  nogc are rather different.


Maybe I'm missing something cause like; I very much don't want to 
make big complex projects I just go "import std;" and write out 
100 lines.

I see two main languges: d and ranges(that mostly just wrap [] 
cause its there), and the std; betterc, libc and manual memory 
management cause you have nothin.

Is there a *real* project that's inbetween; that are using c 
strings and finding a way to use the std anyway?
Sep 15 2023
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 15 September 2023 at 16:40:38 UTC, monkyyy wrote:

 On Friday, 15 September 2023 at 16:09:44 UTC, bachmeier wrote:

 On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

 d as is, is gc'ed to hell and back


 That's why I use it.


 nogc is a bandaid to advertise its something its not.


 [This is what the spec 
 says](https://dlang.org/spec/function.html#nogc-functions). I 
 don't see anything wrong with it. It restricts what you can do 
 inside a function and that's what it's supposed to do.


 a language includes its std and there's no alternative for std: 
 string, algorithm, range to be nogc'ed


std.string, I get, but algorithm and range are poster children 
for ` nogc`. I'm not going to claim that *nothing* in those 
packages allocates on the GC heap, but I'd be very surprised if 
there were many functions that did.

Which is good because allocating when not needed is silly, not 
because avoiding the GC is a good idea. It isn't. *If* your 
program is slow *and* you profiled *and* it's GC allocation 
that's slowing it down, then think about doing something else.
Sep 15 2023
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, September 15, 2023 2:38:12 PM MDT Atila Neves via Digitalmars-d 
wrote:

 std.string, I get, but algorithm and range are poster children
 for ` nogc`. I'm not going to claim that *nothing* in those
 packages allocates on the GC heap, but I'd be very surprised if
 there were many functions that did.


I recall complaints in the past about not being able to use  nogc with
std.algorithm and friends due to issues with lamdbas allocating closures. I
don't know that that's actually an issue at this point (and it really
shouldn't be in general), but it can also be worked around with other forms
of callables if need be. It's just more annoying than using a lambda.

But yeah, there should be _very_ little in terms of explicit allocations
occuring in std.algorithm (possibly even none). It's templated and designed
to operate on generic ranges, and very little of it does anything with
exceptions, so almost none of it should be allocating anything - though of
course, if your ranges themselves can't be  nogc for some reason, then
obviously, std.algorithm can't be either. So, I suspect that strings, for
instance, can't be  nogc with std.algorithm (at least without byCodeUnit)
due to the decoding possibly throwing. A lot of other stuff should be able
to work with std.algorithm and be  nogc with no problem though.

- Jonathan M Davis
Sep 15 2023
prev sibling next sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

 On Friday, 15 September 2023 at 16:40:38 UTC, monkyyy wrote:

 On Friday, 15 September 2023 at 16:09:44 UTC, bachmeier wrote:

 On Friday, 15 September 2023 at 14:50:27 UTC, monkyyy wrote:

 d as is, is gc'ed to hell and back


 That's why I use it.


 nogc is a bandaid to advertise its something its not.


 [This is what the spec 
 says](https://dlang.org/spec/function.html#nogc-functions). I 
 don't see anything wrong with it. It restricts what you can 
 do inside a function and that's what it's supposed to do.


 a language includes its std and there's no alternative for 
 std: string, algorithm, range to be nogc'ed


 std.string, I get, but algorithm and range are poster children 
 for ` nogc`. I'm not going to claim that *nothing* in those 
 packages allocates on the GC heap, but I'd be very surprised if 
 there were many functions that did.

 Which is good because allocating when not needed is silly, not 
 because avoiding the GC is a good idea. It isn't. *If* your 
 program is slow *and* you profiled *and* it's GC allocation 
 that's slowing it down, then think about doing something else.


I'm mostly talking about existing data structures and string 
handling(strings being probably the most important data structure)

Given my definition of language above of compiler + std, a 
betterc project is probably using libc for strings and rolling 
their own data structures; at which point they can't use my 
code(I use import std casually) I don't want to use their code 
even if it even works.

Not getting involved in your attribute debates, to use 
std.algorithm I need data structures that were designed to work 
with it(and probably tested with it), and static arrays aren't on 
the list.

I mostly rant and rave about this on discord but I've been 
complaining about this for years, but for stepovs idea of 
templates where you get n*m solutions out of n+m code you should 
attempt to balance n algorithms with m data structures, and nogc 
by disabling the one good data structure makes 100ish algorithms 
x 1 ==100 into 100x0==0 making the situation so much worse.

If you want nogc to be usable(rn if I want to make something with 
wasm I would need to write a bunch of data structures), the 
problem with data structures, in general, should be addressed.
Sep 15 2023
prev sibling next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

 std.string, I get, but algorithm and range are poster children 
 for ` nogc`. I'm not going to claim that *nothing* in those 
 packages allocates on the GC heap, but I'd be very surprised if 
 there were many functions that did.


Autodecoding and exceptions.

-Steve
Sep 15 2023
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

 std.string, I get, but algorithm and range are poster children 
 for ` nogc`. I'm not going to claim that *nothing* in those 
 packages allocates on the GC heap, but I'd be very surprised if 
 there were many functions that did.


It's not possible to `map` a range and add a variable to every 
element.

Functor predicates are the solution: 
https://github.com/CyberShadow/ae/blob/bb876371c963130dd94a0f44a9a5a2561ff053b4/utils/functor/algorithm.d#L23-L69
Sep 15 2023
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Saturday, 16 September 2023 at 05:32:19 UTC, Vladimir 
Panteleev wrote:

 On Friday, 15 September 2023 at 20:38:12 UTC, Atila Neves wrote:

 std.string, I get, but algorithm and range are poster children 
 for ` nogc`. I'm not going to claim that *nothing* in those 
 packages allocates on the GC heap, but I'd be very surprised 
 if there were many functions that did.


 It's not possible to `map` a range and add a variable to every 
 element.

 Functor predicates are the solution: 
 https://github.com/CyberShadow/ae/blob/bb876371c963130dd94a0f44a9a5a2561ff053b4/utils/functor/algorithm.d#L23-L69


I came to the same conclusion.
Sep 16 2023
prev sibling parent reply Antonio <antoniocabreraperez gmail.com> writes:
On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 wrote:

 On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe 
 wrote:


 This is a mistaken decision.


 Can you explain why?


My opinion: Don't waste your time.  Assume D is a GC language 
(Trying to kill GC is a real pain in the ass that has stopped the 
D ecosystem grow).   I'm seen real good libraries implemented in 
Node or Java for industrial environments and developers don't 
waste time arguing about the sex of angels.  "This is the 
language... this is the library for the language".


Kotlin, Typescript/Node, Python, ...).
Sep 28 2023
parent Antonio <antoniocabreraperez gmail.com> writes:
On Thursday, 28 September 2023 at 07:56:23 UTC, Antonio wrote:

 On Thursday, 14 September 2023 at 16:30:27 UTC, user548215 
 wrote:

 On Thursday, 14 September 2023 at 16:28:24 UTC, Adam D Ruppe 
 wrote:


 This is a mistaken decision.


 Can you explain why?


 My opinion: Don't waste your time.  Assume D is a GC language 
 (Trying to kill GC is a real pain in the ass that has stopped 
 the D ecosystem grow).   I'm seen real good libraries 
 implemented in Node or Java for industrial environments and 
 developers don't waste time arguing about the sex of angels.  
 "This is the language... this is the library for the language".


 Java, Kotlin, Typescript/Node, Python, ...).


I apologize for the tone used in this comment.

This is the reason that prompted me to write it:

In my company we have abandoned the use of D as an scripting 
language in favor of python (especially due to the ease of use of 
opencv and other libraries that are at your disposal with a 
simple pip install) and reading the posts in the forum I'm 
starting to feel that someone has forgotten how necessary it is 
for D to be useful on a daily basis  so that it can be taken into 
account in the big things.
Sep 28 2023
prev sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Sep 14, 2023 at 04:28:24PM +0000, Adam D Ruppe via Digitalmars-d wrote:

 On Thursday, 14 September 2023 at 15:40:30 UTC, user548215 wrote:


[...]

 based on the discussions I've read about the Garbage Collector in
 the D programming language, I've decided to abstain from using that
 feature.


 
 This is a mistaken decision.


Yeah, in 90% of the use cases, the GC actually helps much more than it
hurts.  Two of the biggest advantages:

(1) It eliminates an entire class of bugs stemming from wrong management
of allocated memory: pointer bugs, buffer overflows, double frees,
memory leaks, all those delicious things that I spend hours, days,
sometimes even months to debug at my day job. Many of these bugs only
show up after the fact, in completely unrelated code that gives you no
clue as to where the real problem is.

(2) Your APIs become so much cleaner and more maintainable: instead of
spammy APIs like:

	OwnedPointer!MyReturnType myFunction(Allocator)(Allocator alloc,
		OwnedPointer!ArgTypeA arg1, ScopedPointer!ArgTypeB arg2,
		RCPointer!ArgTypeC arg3) { ... }

with the GC it becomes simply:

	MyReturnType myFunction(ArgTypeA arg1, ArgTypeB arg2, ArgTypeC
		arg3) { ... }

Your APIs also become so much more usable; instead of:

	auto arg1 = wrapInOwnedPointer(mydata1);
	auto arg2 = wrapInScopedPointer(mydata2);
	auto arg3 = wrapInRCPointer(mydata3);
	OwnedPointer!MyReturnType value = myFunction(allocator, arg1, arg2, arg3);
	doSomethingWithValue(value);
	if (!value.isNull) value.free();
	if (!arg1.isNull) arg1.free();
	if (!arg2.isNull) arg2.free();
	if (!arg3.isNull) arg3.decrement();

with the GC it becomes simply:

	MyReturnType value = myFunction(mydata1, mydata2, mydata3);


The result is that your code is easier to write, easier to debug, and
frees up your brain from having to constantly focus on memory management
paraphrenalia, and actually think about *making progress in your problem
domain* in the first place.

Manual memory management is error-prone, verbose, hard to read, harder
to understand, and not actually necessary 90% of the time.  Using it by
default is a net minus, especially when you don't know if it's actually
necessary.


T

-- 
We've all heard that a million monkeys banging on a million typewriters will
eventually reproduce the entire works of Shakespeare.  Now, thanks to the
Internet, we know this is not true. -- Robert Wilensk
Sep 14 2023
parent reply bachmeier <no spam.net> writes:
On Thursday, 14 September 2023 at 17:32:19 UTC, H. S. Teoh wrote:

 On Thu, Sep 14, 2023 at 04:28:24PM +0000, Adam D Ruppe via 
 Digitalmars-d wrote:

 On Thursday, 14 September 2023 at 15:40:30 UTC, user548215 
 wrote:


 [...]

 based on the discussions I've read about the Garbage 
 Collector in the D programming language, I've decided to 
 abstain from using that feature.


 
 This is a mistaken decision.


 Yeah, in 90% of the use cases, the GC actually helps much more 
 than it hurts.  Two of the biggest advantages:


I'd add another disadvantage of the GC that probably won't be 
there: performance.

I don't find that avoiding the GC speeds up my code that often. 
Sometimes it helps to disable the GC if I'm reading a very large 
number of elements into an AA of AA's.

What consistently improves performance is avoiding allocation of 
large blocks of memory - and it's easier to do that correctly 
when you're using the GC. If you don't allocate, the GC will not 
run, problem solved. Completely avoiding the GC is a sensible if 
you're writing a game, but at best not that helpful if you just 
want your program to run faster.
Sep 14 2023
parent "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Sep 14, 2023 at 07:40:24PM +0000, bachmeier via Digitalmars-d wrote:

 On Thursday, 14 September 2023 at 17:32:19 UTC, H. S. Teoh wrote:


[...]

 Yeah, in 90% of the use cases, the GC actually helps much more than
 it hurts.  Two of the biggest advantages:


 
 I'd add another disadvantage of the GC that probably won't be there:
 performance.
 
 I don't find that avoiding the GC speeds up my code that often.
 Sometimes it helps to disable the GC if I'm reading a very large
 number of elements into an AA of AA's.


In one of my projects, I found that calling GC.disable and then doing my
own scheduling of when GC.collect runs, improved my performance by
40-60%.  It's another way of boosting performance while still enjoying
the benefits of having a GC.



 What consistently improves performance is avoiding allocation of large
 blocks of memory - and it's easier to do that correctly when you're
 using the GC. If you don't allocate, the GC will not run, problem
 solved.  Completely avoiding the GC is a sensible if you're writing a
 game, but at best not that helpful if you just want your program to
 run faster.


When it comes to performance issues, I have 3 pieces of advice:

1) profile
2) profile,
3) profile.

;-)  IOW, don't automatically assume the GC (or anything, really) is the
cause of your performance issues.  Use a profiler to find out the real
culprit.  If it *is* the GC, I'd venture to guess that 80% of the time
it can be managed by careful use of GC.disable, GC.collect, and
GC.enable.  Generally speaking, you do not need your entire program to
be  nogc, except in a very small number of very specific use cases.


T

-- 
A mathematician learns more and more about less and less, until he knows
everything about nothing; whereas a philospher learns less and less about more
and more, until he knows nothing about everything.
Sep 14 2023
prev sibling next sibling parent Sergey <kornburn yandex.ru> writes:
On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
Naderer wrote:

 Hello,

 I think D is a great language and a general theme is that 
 everybody is complaining about the lack of libraries, 
 frameworks and/or bindings to popular C/C++ libraries.

 I checked the GitHub repo and so some todos, I would like to 
 contribute to the language.

 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?

 Best regards,
 Max


Please also consider support of great existing libraries:
Mir framework needs new maintainer.
Archttp (performant web server from Hunt authors) is lacking of 
maintenance now.
Also the autho of Tilix (gtk application for Linux terminal) 
searched new maintainer quite a while..
Sep 18 2023
prev sibling parent Antonio <antoniocabreraperez gmail.com> writes:
On Wednesday, 13 September 2023 at 16:31:55 UTC, Maximilian 
Naderer wrote:

 Hello,

 I think D is a great language and a general theme is that 
 everybody is complaining about the lack of libraries, 
 frameworks and/or bindings to popular C/C++ libraries.

 I checked the GitHub repo and so some todos, I would like to 
 contribute to the language.

 What popular frameworks / libraries would you like to see 
 bindings for so that those could be used in D?

 Best regards,
 Max





to connect with industrial objects (or to allow communications 
with it)

This is de C implementation you can try to bind.

https://github.com/open62541/open62541

There is some other open source native implementations (not based 
on bindings) in different languages

RUST:

https://github.com/locka99/opcua

The design doc is really interesting: 
https://github.com/locka99/opcua/blob/master/docs/design.md

NODE:

https://github.com/node-opcua

This is a complete implementation in Typescript (my favourite).

This has its own "open collective": 
https://opencollective.com/node-opcua#category-BUDGET

GO:

https://github.com/gopcua/opcua




This is the actual unmaintained binding for D

https://code.dlang.org/packages/opencvd


My opinion:

* It should be perfect not only the binding library,  but the 
"easy" installation (like the python version for desktop or 
headless for server side),  **Just "dub" it !**
Sep 28 2023