October 09, 2021

On Saturday, 9 October 2021 at 12:11:51 UTC, Paulo Pinto wrote:

>

On Saturday, 9 October 2021 at 07:31:02 UTC, Imperatorn wrote:

>

On Saturday, 9 October 2021 at 06:50:19 UTC, Paulo Pinto wrote:

>

[...]

Omg my eyes. Don't rough up C#, use D instead 😅

Maybe like 5% of the C# community even uses structs and of them 0.5% would do ref struct and 0.1% would try to scope guard something, but nice experiment ofc 💕

Sure when D's ecosystem catches up.

Soon (tm) dreaming

Although, in real life I will just use C# meanwhile, so I'm a hypocrite

October 09, 2021

On Saturday, 9 October 2021 at 12:11:51 UTC, Paulo Pinto wrote:

>

Sure when D's ecosystem catches up.

It'd definitely be a nice surprise if the leadership announced some sort of plan of action on tackling this issue, because without structured guidance I don't see this being possible.

e.g.

"What we need:

  • de-facto standard event loop
  • de-facto standard web server
  • de-facto standard json library
  • de-facto standard yaml library
  • de-facto standard logging library
  • de-facto standard database abstraction
  • de-facto standard whatever

We'll do this by creating a list of requirements these libraries should meet, yada yada.

We'll setup/use an official github org to organise these under, so they're not just random repos with random owners yada yada.

Maybe even give them simple names on dub, literally "yaml", or "eventloop".

The leadership will work together with the community to yada yada.
"

I'm obviously a very naive person, but would something like the above even be feasible, if useful at all?

Because at the moment all I see is:

"Person A ports/writes a library/binding. 1 year later it has 3 total downloads and is completely dead."

"Person B does the exact same thing, and suffers the exact same fate".

I wonder what it is about D that makes such coordination seemingly so difficult.

Because when we used to have the Vision documents, it'd include things like "Get a new std.json library with X Y Z features", but they never came to fruition.

It was more like a wishlist rather than a plan of action.

October 09, 2021

On Saturday, 9 October 2021 at 20:42:25 UTC, SealabJaster wrote:

>

...

I guess a point I wanted to drive home is that these would be official things, not community-led things.

These would be a core part of D's ecosystem rather than a hobby project one or two people have control over.

This is definitely more difficult when D is almost purely volunteer based, and I'm sure there's a bunch more issues I wouldn't even be able to think of on my own.

October 09, 2021

On Saturday, 9 October 2021 at 07:13:38 UTC, Paulo Pinto wrote:

>

On Saturday, 9 October 2021 at 00:23:00 UTC, russhy wrote:

>

Why do you guys compare D to C#, if there is one language you should compare D is with
(actually 3) Go/Rust/Zig

C# appeals to Java people, it's not a native system language, it compiles to IL and requires a massive runtime

The more you look at C#, the faster you'll miss the biggest agendas of tomorrow, C# just like Java are slowing meeting with the graveyard of old and irrelevant tech

So much disinformation.

Here the native code compilers for C#.

https://docs.microsoft.com/en-us/windows/uwp/dotnet-native/

https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator

https://github.com/dotnet/designs/blob/main/accepted/2020/form-factors.md#native-aot-form-factors

https://docs.microsoft.com/en-us/xamarin/mac/internals/aot

https://docs.unity3d.com/Manual/IL2CPP.html

Running on production embedded hardware,

https://www.wildernesslabs.co

Apparently the majority of the games running in that Nintendo toy, that has broken all sale records, happen to use Unity in about 30% of their titles.

https://www.kelltontech.com/kellton-tech-blog/reasons-develop-nintendo-switch-games-in-unity-game-engine

Another graveyard irrelevant technology that besides Nintendo, is the tier 1 for Sony, Google and Microsoft gaming systems and AR/VR platforms, alongside Unreal.

Looks pretty much alive to me.

D also compiles to LDC bitcode and GCC gimple, and has a runtime.

Should we also consider it not a systems language then?

Don't let the hatred and lack of knowledge for other stacks cloud your judgement.

It steers people away from D when false statements are being done about the ecosystems they know quite well, turning on their defences and thus stop listening on what D is actually supposed to be better on.

vibe-d and hunt helped compete with asp.net and spring, it's a known fact, the GC helps D web servers handle terabytes of heap memory and millions of transactions per seconds, also a known fact..

it also helped compete with the simplicity of go net/http, a very known fact, obviously

you are looking at the past, when you want to be relevant tomorrow, you look forward

comparing to C# with what strengths?

there is not JIT and no low latency GC, you'll be forever a worst version of C# if you keep that argument

and anyways, comparing with other languages is a little bit offtopic

what are out strenghts, and what problems can we solve?

i make a game with D, what are you guys doing with D?

October 09, 2021

On Saturday, 9 October 2021 at 20:42:25 UTC, SealabJaster wrote:

>

On Saturday, 9 October 2021 at 12:11:51 UTC, Paulo Pinto wrote:

>

[...]

It'd definitely be a nice surprise if the leadership announced some sort of plan of action on tackling this issue, because without structured guidance I don't see this being possible.

[...]

Agreed. Would be nice if you could streamline stuff a bit more

October 10, 2021

On Monday, 4 October 2021 at 13:23:40 UTC, Paul Backus wrote:

>

[...]

D is all about choice.

Many people feel frustrated with D: @safe, @live, @nogc, betterC, etc - what/when to use? They ultimately feel lost. But it's not a language thing.

D lets the programmer make the choices and helps him stay true to what he has chosen. D is like C - it trusts the programmer, but it also has the necessary mechanisms to ensure that the programmer does not stray from the path chosen.

Want to avoid the GC? Put @nogc at the top of your file. Do you want your code to be safe? @safe - is the way to go. Such mechanisms ensure you don't get lazy and start using the features you set to avoid.

Unlike Rust, D does not enforce anything upon the programmer. There is no path, schema, plan. You are your own boss. You decide.

D is all about choice. Every time we start a new project, we need to decide what D subset to use. I find D similar to Gentoo philosophy-wise. Systemd vs OpenRC? Etc.

I believe we need to somehow communicate this to the public to clarify all this confusion involved with D features.

October 10, 2021

On Saturday, 9 October 2021 at 06:50:19 UTC, Paulo Pinto wrote:

>

You can simulate scope(exit) with an helper struct.

[snip]

Naturally D's scope(exist) is cleaner to write.

Lol, I haven't done this put my C# definitely shows I wish I had a D compiler (and understand C# a bit poorly). This is a somewhat outdated C# compiler, not all of the newest tricks are available:

public struct Ui
{   //...
}

// elsewhere

abstract class Panel
{   // ...
    public Ui[] uiState;
    // ...
}

The story behind that array is that I wanted a reference to the struct. Later on I came up with a less hackish way to achieve the same:

//Intended for the same as C standard library div_t: result of division.
public struct DivInt
{   public int quot;
    public int rem;
}

public class Ref<Struct>
{   public Struct value;
    public Ref(){}
    public Ref(Struct val){value = val;}
}

Other examples of my programming:

public static class Utility
{   //Because Debug.Assert message does not pop up on web page
    [System.Diagnostics.Conditional("DEBUG")]
    public static void Assert (bool condition)
    {   Assert(condition, "Program in illegal state. Exiting.");
    }

    [System.Diagnostics.Conditional("DEBUG")]
    public static void Assert (bool condition, string message)
    {   if (!condition)
        {   Window.Alert(message);
            throw new InvalidOperationException();
        }
    }

    public static void Swap<T>(ref T a, ref T b)
    {   var temp = a;
        a = b;
        b = temp;
    }

    //don't use to add many elements sequentially in a loop, as that's inefficient.
    public static void Append<T>(ref T[] array, T what)
    {   var oldLength = array.Length;
        Array.Resize(ref array, oldLength + 1);
        array[oldLength] = what;
    }

     //always rounds down, also when negative.
    public static DivInt Div(this int dividee, int divisor)
    {   int quot;
        int rem;
        // Could this be assigned directly to the result value?
        quot = Math.DivRem(dividee, divisor, out rem);

        if(rem < 0)
        {   quot--;
            rem += divisor;
        }
        return new DivInt{quot = quot, rem = rem};
    }

    public static void Each<T>(this IEnumerable<T> range, Action<T> todo)
    {   foreach(T el in range) todo(el);
    }

    public static IEnumerable<Sequence<T, int>> Enumerate<T>(this IEnumerable<T> range, int startValue)
    {   return range.Zip(Enumerable.Range(startValue, int.MaxValue), (x, y) => new Sequence<T, int>(x, y));
    }

    public static IEnumerable<Sequence<T, int>> Enumerate<T>(this IEnumerable<T> range)
    {   return range.Enumerate(0);
    }
}

My way of serializing and deserializing data to/from files would probably get red pen marks from fairly much everything. Representive deserialization here, struct data is commented in real life but not here because didn't bother to translate:

public struct PillarInstallation
{   public Slab pillar;
    public Vector3D gap;
    public float angle;
    public Ref<StoneCutType>[] sideCutTypes

    // other member functions...

public static PillarInstallation Deserialize
    (   byte[] from,
        int fromI,
        YhkVersion yhkVersion,
        int pillarI,
        Dictionary<string, int> textureChecker
    )
    {   int fromIAtStart = fromI;
        PillarInstallation result = new PillarInstallation();

        result.pillar = Slab.Deserialize(from, fromI, textureChecker);
        fromI += Slab.serializedSize;

        result.gap = Vector3D.Deserialize(from, fromI);
        fromI += Vector3D.serializedSize;

        if (yhkVersion.Encompasses(new YhkVersion(8)))
        {   result.angle = Utility.DeserializeFloat(from, fromI);
            fromI += 4;
        } else result.angle = 0;

        result.sideCutTypes = new Ref<StoneCutType>[2];
        if (yhkVersion.Encompasses(new YhkVersion(12)))
        {   for(int i=0; i<result.sideCutTypes.Length; i++) if(from[fromI+i]!=255)
            {   var refVar = new Ref<StoneCutType>();
                refVar.value = (StoneCutType)from[fromI+i];
                result.sideCutTypes[i] = refVar;
            }
        } else
        {   bool interfaceSawed = Utility.DeserializeInt(from, fromI) % 2 > 0;
            if (interfaceSawed)
            {   var refVar = new Ref<StoneCutType>(StoneCutType.sawed);
                result.sideCutTypes[pillarI^1] = refVar;
            }
        }


        fromI += 4;

        Utility.Assert(fromIAtStart + GetSerializedSize(yhkVersion) == fromI, "read " + (fromI - fromIAtStart) + " bytes, should have read " + GetSerializedSize(yhkVersion));
        return result;
    }
}
October 10, 2021

On Sunday, 10 October 2021 at 13:13:21 UTC, Dukc wrote:

>

I haven't done this put my C# definitely shows I wish I had a D compiler

"but" intended, not "put".

October 10, 2021

On Thursday, 7 October 2021 at 22:07:13 UTC, Guillaume Piolat wrote:

>

On Thursday, 7 October 2021 at 20:12:49 UTC, Dukc wrote:

>

Wow, are modern C++ compilers crashy when compared to D? I definitely agree that D compilers nowadays are more than stable enough for production, but do they really rival the most common C++ ones?

LDC rivals clang of course. On what metric do you think it wouldn't?

I was thinking about the frontend. Some C++ frontends are so widely used that I'd think they have less bugs.

OTOH C++ frontends are more complex to get right and they are not written in D (except DMC), so I would not except a C++ frontend of similar maturity to be as reliable. But something lice g++ is so incredibly common that it sounds like a bigger factor than the relative simplicity of D.

>

Yes really, it is very difficult to keep up with the C++ changes even if you were a full-time C++ programmer. And you need to since people start to use the new stuff when available. It is very likely that when the next standard comes out, you would have barely assimilated the one from 10 years ago. C++ needs a cast of "explainers" like Scott Meyers.

Ouch. They would do well to be more conservative and leave accumulating features for extensions and younger languages. They cannot match newer languages in elegance whatever they do, so it'd make more sense to make life easy for existing codebases instead.

But I'm probably missing something here. I don't think the C++ standard committee is stupid after all.

October 10, 2021

On Sunday, 10 October 2021 at 17:07:04 UTC, Dukc wrote:

>

On Thursday, 7 October 2021 at 22:07:13 UTC, Guillaume Piolat wrote:

>

[...]

I was thinking about the frontend. Some C++ frontends are so widely used that I'd think they have less bugs.

OTOH C++ frontends are more complex to get right and they are not written in D (except DMC), so I would not except a C++ frontend of similar maturity to be as reliable. But something lice g++ is so incredibly common that it sounds like a bigger factor than the relative simplicity of D.

>

[...]

Ouch. They would do well to be more conservative and leave accumulating features for extensions and younger languages. They cannot match newer languages in elegance whatever they do, so it'd make more sense to make life easy for existing codebases instead.

But I'm probably missing something here. I don't think the C++ standard committee is stupid after all.

C++ has hypernormalized a very language-lawyery way of programming. The committee isn't stupid but the road to hell is paved with good intentions, as they say.

Any decision than make can be inverted and justified just as easily, from what I have read.