On Sunday, 7 January 2024 at 11:54:16 UTC, bomat wrote:

I'd much rather Adam put his time into a fork, rather than the more common approach where he'd post here under various names, make ridiculous claims, and vandalize the discussions. If you're new, you may not have seen the many posts from someone that doesn't like private at the module level.

Whether there are useful insights from this or any other fork will depend on what they do with it. If there's too much incompatibility of code, due to breaking changes, it won't have much effect. There's already Nim, Rust, Go, Zig, etc., to compare with and the forks will in each case be just another language.

Not really. Those things come after the userbase gets large. I was using Python in the 1990s and I can assure you that the growth did not come because of good tooling, documentation, or code samples. Similarly, I was using R when you used Emacs or a plain text editor, the documentation was similar to Linux man pages, and you asked questions on a mailing list with Brian Ripley. Only after it took off did they build RStudio. What both languages had was a small, dedicated group of users that were willing and able to build useful things with the language.

On Sunday, 7 January 2024 at 11:54:16 UTC, bomat wrote:

I'll do it for you, d is a c++ killer not a c killer, zig will probably win the c killer race because it has a ton and different platforms and is working on a new libc, meaning zig and basically no one else can make breaking changes to fundamental things.

And d is a template hell with the most features and fastest compile time, but doesnt actually ship a completed data structures and algorithms project and honestly copies too many of stl's mistakes.

On Sunday, 7 January 2024 at 11:54:16 UTC, bomat wrote:

I said nothing about good tooling, documentation, etc. Of course those are necessary for something to be "good", which I'd point out, was my definition of "good", as "My opinions, of course" was intended to convey.

It all depends on how you define "successful". If you define success as having a huge user community, then your paragraph above applies. I would argue that there are alternative ways to measure success. Is Scheme a success? OpenBSD? JS Bach? I say emphatically "yes" (especially regarding Bach) and yet all of them have user communities orders of magnitude smaller than their most popular competitors.

On Sunday, 7 January 2024 at 09:04:16 UTC, Walter Bright wrote:

db.execi(i"INSERT INTO sample VALUES ($(id), $(name))");

db.execi(xxx!(i"INSERT INTO sample VALUES ($(id), $(name))"));

where `xxx` is the thoroughly unimaginative name of the

...

So 1027 is equivalently good in this aspect as long as programmers are conscientious in their definition and use of a typing convention?

Unless 1036e is believed to be very difficult to implement correctly, or has nasty cross dependencies that could cause problems later, this would seem to be a bad trade (hypothetical? simplification of implementation in exchange for making things harder for users).

On Sunday, 7 January 2024 at 18:51:40 UTC, Walter Bright wrote:

It seems you have a fundamental misunderstanding of what DIP1036 is, so here's a quick explanation: i"$​(str) has $​(num) items." becomes

AliasSeq!(
    InterpolationHeader(),
    InterpolatedExpression!"str",
    str,
    InterpolatedLiteral!" has ",
    InterpolatedExpression!"num",
    num,
    InterpolatedLiteral!" items.";
    InterpolationFooter(),
)

InterpolationHeader, InterpolatedExpression, InterpolatedLiteral, and InterpolationFooter are defined in core.interpolation, which doesn't need to be imported in order to use interpolated strings.

Not arsd.sqlite, nor any other library, defines their own interpolated strings. Importing a library does not and cannot change the behavior of interpolated strings, that is a misunderstanding. Library functions simple take in the interpolated string using a vararg template and do literally whatever they want with it, since they're given all the information about the interpolated string, including the evaluated expressions that were inside the string.