What an absolute bunch of nonsense.

If that’s were your performance problems come from, you are either a junior developer yourself or using some PHP-quality framework written by juniors.

I can see the point that too many program elements get too much color, but:

Suggesting to not color keywords and use a single color for the names of top-level elements at the same time simply doesn’t mesh well.

I’m coloring keywords exactly because I do not want to invent a new color for each individual top-level element name or require backtracking from the (in his proposal) highlighted name to the (in his proposal) non-highlighted keyword preceding it.

Looking at the code example here I’d be open to have less things highlighted, but where to start? I guess parameter names, but apart from that?

I’m working on Core whose primary design goal is to not invent any new features, but implement existing things correctly.

The grammar is implemented with recursive-descent, one could define an equivalent EBNF, but I haven’t found the need to do so yet.

Working on my programming language, and improving some blog posts of mine. :-)

It’s interesting to me, because I wrote an article giving an overview of the possible combinations mentioned in his blog post a few years ago.

😂

Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-)

(Not to mention that would require the paper to have reproducible artifacts first.)

This is one of the rules I religiously follow in the design of my language.

It’s one of the reasons

• why I removed unary operators like ! and ~ and made -foo.bar parse as (-foo).bar;
• why the order of elements in a type or function definition is the way it is; and
• why I use an OOP-style value.member design instead of piping syntax like |>.

Kinda nice that they are adding Algol68 unions to C#!

Looks like they finally broke the 200-keywords barrier with this release. 🤣

Removing let-else is the whole point of the linked article series:

Being able to do to everything Rust does, but without Rust’s zoo of if-then-else, match, if-let, let-else etc.

Thanks for your reply, some replies below!

requiring positional args to use the assignment syntax

Not sure, maybe my wording isn’t clear enough. What I intended to say is that arguments can be named, not that they have to. In any case, the order of arguments must match the order of parameters, named or not.

But you’re also missing one use of the impl keyword: fn func() -> impl Trait.

That removal could actually happen, so I didn’t list it. (Rust started requiring dyn and disallowed naked trait returns with edition 2018. So dropping the impl in that position might not be completely impossible like the other uses of impl.)

Are you suggesting using keywords/methods [for array and slice syntax] instead?

Yes, just methods.

I can understand someone preferring the PartialEq/PartialOrd behavior

You can have both – that’s what’s being made possible by them not being in a hierarchy.

I think if-let makes sense, but don’t expand it.

It’s a bit late for that, isn’t it? ;-)

Why? What value does -> () provide? Why not elide that?

What value is provided by keeping it? Why a syntactic special-case for exactly that type and not any other random type?

languages w/o them feel awkward since you’re generally limited to one statement per line

Then fixing that might make sense. :-)

I don’t think the alternative to let-else is too bad.

I went the “only let introduces bindings” route, and I’m pretty happy so far:

if (left.next(), right.next())
... is (Some(let l), Some(let r)) { /* use l and r */ }
... is (Some(let l), None       ) { /* use l       */ }
... is (None,        Some(let r)) { /* use r       */ }
... is (None,        None       ) { /* use nothing */ }
}

Some of the earlier ones remind me of C#'s records. Were they inspired from them?

No, that stuff is much much older.

Named parameters are problematic because of parameter names becoming significant to the API. See Python’s * and / in parameter lists (like def foo(a, *, b) for example).

I think the name problem is overblown, you can always have an annotation to facilitate name changes.

In addition to that, I have my own list of things Rust should not have shipped with, but did.

This. I’d rather have fewer, better working features.

This exactly what I described in 2021, so I’m pretty happy seeing other languages also going this route.

Sadly, they also don’t have a solution for the follow-up question that naturally falls out if this approach – how to “unbox” generic types such that they can be used directly and don’t need some additional type to hold it, i.e.

union Option[T] of T, None // None defined elsewhere

instead of

union Option[T] of Some[T], None // Some & None defined elsewhere

Rust devs sometimes seem to be an incredibly insecure and angry crowd.

I mentioned elsewhere how I had very good outcomes from looking at Rust and asking “how can this be done, but simpler?” in my language, listing a few examples … and they were absolutely livid about it.

I would be deeply uncomfortable to work in an environment where one couldn’t ask the author of a change for insights or rationale, because the author let some machine write it and therefore lacks any deeper understanding.