superamadeus

Most likely for Docker/container users using Alpine Linux or similar.

This is really neat, thank you for sharing!

I had the same initial reaction, but it turns out that if you have at least one private member, even with the same signature, it works as the parent comment suggests.

For example, these two classes are distinct to TypeScript:

    class Name {
        constructor(private value: string) {}

        getValue() {
            return this.value;
        }
    }

    class Email {
        constructor(private value: string) {}

        getValue() {
            return this.value;
        }
    }

    const email: Email = new Name(“Tim”); // Error: (paraphrasing) conflicting private declaration of “value”.

Oh, fantastic. Thank you!

Is there any discussion or in-depth explanation of the syntax choices? I understand that a goal was context free unambiguous parsing. But there are some things that surprise me.

For example, string interpolation:

    "Hello, (msg)$!\n"

Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?

The results described in the article talk about weight loss mostly in overweight and obese individuals. The other health benefits are improved blood sugar regulation and insulin sensitivity when eating in the morning rather than at night.

The book “How Not to Diet” by Dr. Michael Greger has a section about this, referencing similar studies.

  I do like the ideas of webapps - that webapps can connect other services together or able to create 1 platform for "every" device.

Ah, The Platform.

The web development ecosystem is constantly evolving because The Platform is also constantly evolving.

I’m not saying that all of the churn is strictly necessary or what it’s not overwhelming, especially to beginners, and especially in hindsight.

The churn is in response to the fact that managing a development ecosystem for The Platform is a hard and impermanent problem to solve.

New solutions come about to address the complexity, but those have their own complexity that will eventually be addressed by another new solution. This can be frameworks and libraries, languages and tools, or alternative “platforms” altogether.

The reality is, most of the solutions available today are fine in their own respects. Plenty of real, production software is built on these technologies, even the “outdated” ones.

Try out some solutions. Pick one that clicks with you. Build your thing. You’ll learn valuable concepts. A lot of it will be transferable or analogous to other solutions you encounter in the future.