Just trying to compile a sample basic gtk-d project (including the libraries themselves) using ldc2 and optimization "-Os" and seeing how much time this takes, I want to ask if the benchmarks found here about ldc2 are real. Again seeing the gtk-d project taking so much time, It's hard to believe that ldc2 compiles faster that tcc and go. However, this test probably doesn't use optimizations but still.... Ayn thoughts?

On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

You can see how recent they are, and yeah they're real, but it's a very specific artificial benchmark and there's a lot more to say about compilation speeds about the various languages. That D can compile amazingly fast can be shown just by building dmd itself. But unlike go, D also gives you a bunch of tools that you can use to make compile times take a lot longer. Likewise you could say that D can make just as careful use of memory as a C program, but that D unlike C also gives you a bunch of tools that you can put towards much less careful use of memory.

On Monday, 30 August 2021 at 15:34:13 UTC, jfondren wrote:

Yeah I checked the last commit which was 11 July so yeah they are very resent. My only complain about D's memory management is that the Garbage collector is used in the Phobos so I cannot mark my whole project with @nogc. I think the library is a specific thing and probably we could get away doing manual memory management and also being bug-free but I don't take it on me. I may be wrong

On Monday, 30 August 2021 at 15:34:13 UTC, jfondren wrote:

One definite flaw I've had with D's ecosystem, is these issues aren't made CLEAR. Like if you dare import regex and use a single regex match, your compile time explodes by 10-15 seconds on my i3 chromebook (from ~3 seconds to over 15!).

There are a lot of gotchas in D. Anything that "can" explode your program in terms of memory leaks, or run / compile-time performance should be clearly documented.

And the barrier-to-entry is annoying even to fix documentation. I went to a D page, clicked "improve this page" and I have to... fork the repo, and then submit a pull request. Even if if's just to correct a typo. Is that kind of lock-and-key audited security over edits to documentation... really necessary? If it takes more than 10 seconds, most people aren't even going to bother.

On Tuesday, 31 August 2021 at 08:27:30 UTC, Chris Katko wrote:

That all happens on github. Even the editing. You never have to leave the browser. The whole point of that is that you don't have to fork manually from the command line. I'm not sure how it could be easier. Care to elaborate?

Anyway, if that's too much, then you can always submit an issue on Bugzilla.

On Tuesday, 31 August 2021 at 08:27:30 UTC, Chris Katko wrote:

That's standard for pretty much all open-source documentations.

See examples below:

MDN Uses Github for their documentation: https://github.com/mdn/content/blob/main/files/en-us/web/html/element/input/index.html

Rust: https://prev.rust-lang.org/en-US/contribute-docs.html

Visual C++: https://github.com/MicrosoftDocs/cpp-docs/blob/master/CONTRIBUTING.md

And the list goes on.

It's the most liable method of having documentation that can be contributed to by others.

What would your alternative be? There HAS to be someway of audited security, otherwise people WILL insert whatever into the documentation such as malicious content and the malicious content may not even be discoverable because it could be hidden to a page's user.