On 10/27/22 15:11, Ola Fosheim Grøstad wrote:

> No. The argument was whether it makes sense to use Rust for building the
> core engine of Firefox or not.

No. Your argument was about GC not being usable for such applications.

> The position I argued against was that
> you could just as well do it with a standard freeze-the-world GC or Go
> with full GC. The argument isn't strictly related to D, that is
> something you brought to the table.

I did not bring D to the table.

This thread is titled "A D vs. Rust example" where people are trying to convince the OP that their real-world experience is false because browsers support realtime applications as well.

> 99% of all languages use some kind of GC, most of the programs written
> are done using some kind of GC. Having automatic memory management is
> the norm, not the outlier.

Everybody knows that.

> That does not mean that non-GC applications can be replaced with a
> run-of-the-mill GC solution and be competitive.

Everybody would agree with that.

How does that point make any sense in this discussion though? Who was arguing doing any of that? If you are referring to the claim that some percentage of languages (including D) cannot be used to write a browser, that is simply false. Because my claim is different: Many programming languages (including D) can be written to write a browser. There...

> It makes sense to use
> languages like Rust for even mundane things like cloud web services
> where you want to conserve memory.

What are you saying? Who would ever not want to conserve memory?

> I am not a Rust user at this point, but I also don't assume that people
> who use it don't understand the tradeoffs.

Some people do understand the tradeoffs but many others just follow the tide.

>> Now, to break your logic, I present Weka.IO, world's fastest file
>> system, written in D. Period.
>
> Do they use the regular D GC all the way?

None whatsoever.

>> As I've shown above, it is possible and workable.
>
> I have absolutely no idea what you are referring to here.

I was quoting you. You said "It is possible, but not workable."

But now I see: You were using the niche application of "realtime applications in the browser" to prove that a run-of-the-mill GC cannot be used for it.

Fine with me as long as you don't argue that a run-of-the-mill GC (e.g. the one in D) cannot be used to write a browser.

Ali

On 10/28/22 00:25, Ola Fosheim Grøstad wrote:
> On Thursday, 27 October 2022 at 23:40:11 UTC, Walter Bright wrote:
>> The fact that D's GC is what enables advanced CTFE programming is
>> often overlooked. It's a killer feature enabling a killer feature.
>
> It is clearly better to use high level code in CTFE than system-like
> code.

Yes, high level code is always better.

> Maybe you could consider adding more high level features such a
> comprehensions and generators for the purpose of improved CTFE?

I want to ask comprehensions and generators as seen in the context of Python but you could not have meant it because Python does not have CTFE.

D uses range algorithms for comprehensions and generators. For example, the following program instantiates a struct template with a value computed from a generator:

struct S(size_t N) {
    float[N] arr;
}

void main() {
    import std.algorithm : map, sum;
    import std.range : iota;

    auto s = S!(iota(10).sum)();  // <-- Generator used in CTFE
    pragma(msg, s.arr.length);
}

Ali

On 10/28/2022 2:07 AM, Dukc wrote:
>   - No string handling function needs to throw anything. The could all be `nothrow`.
>   - If two string handling functions that need to decode are chained to each other, they don't need to both reduntantly check for invalid UTF-8.
>   - You don't accidently forget to check for invalid UTF-8, or recheck an already checked string.

I've discovered that:

1. throwing on invalid UTF-8 is the wrong solution. Phobos' autodecode does that. It was a huge mistake, but is a problem with Phobos, not D itself.

2. very, very few string algorithms have any need to decode the UTF-8. String copying, searching, hashing, etc., all have no need to decode. I've fixed a lot of the algorithms in Phobos to not decode.

3. detecting bad UTF-8 encodings only happens when decoding is needed. It costs nothing extra, as it falls out of the decoding logic. Then, one can decide to safely ignore it, or use the Replacement Char.

It works fine. There just is no need to purify the strings.

On Sunday, 30 October 2022 at 02:29:36 UTC, Walter Bright wrote:

>
> 3. detecting bad UTF-8 encodings only happens when decoding is needed. It costs nothing extra, as it falls out of the decoding logic. Then, one can decide to safely ignore it, or use the Replacement Char.

If the algorithm does not throw on invalid UTF, I guess so.

>
> It works fine. There just is no need to purify the strings.

No need, but a bit of benefit since some bugs could be catched at compile time.

Then again, it'd be catching only one class of errors of the countess one that are possible. Rust's solution would still be of no help if we're excepting letters but receive numbers instead and forget to check. So maybe complexity-to-benefit ratio of it is still unfavourable. Someone with experience with Rust string handling could maybe judge it.