Yes, that is true but I think there’s a compounding effect on complexity which means complexity at all levels is important to minimise. As an example, a more complex language requires more complex tools and more attempts at getting the tools right, which leads to the proliferation you mention. Some features can instead lead to proliferation of libraries (Smart pointers or regular pointers? Which of fifteen flavours of strings? Macros or regular functions? Etc.)

Putting languages aside, isn’t it the same kind of disregard for complexity in all other areas (protocols, APIs, libraries etc.) that ultimately results in unwieldy ecosystems?

We tend to underestimate how small bits of complexity compound and snowball, I think.

I strongly agree with this. Coming from Clojure on the JVM, I found it much more difficult to work on a project written in ClojureScript (supposedly the “same” language on a different runtime) than it was to learn Mirah (completely different language on the JVM).

Of course there are other factors like completely different paradigms that come out of left field (logic programming, category theory, etc) to make things difficult, but other than that, once you’ve got thee or four languages under your belt, learning a new one is much easier than learning a new runtime.

My Erlang is super rusty so I’m a bit fuzzy on this, but it looks to me like “forms” in this context basically means what other languages call statements; is that accurate?

It’s refreshing to see someone admitting their mistakes so openly.

Very few major projects are considered minimalist. The knock on effect of this is that steers the imagination away from minimalism. From a maximalist viewpoint, PLs such as Lisp, Smalltalk, or ML look like toys because there seemingly isn’t enough stuff to learn.

It’s often a question of choosing where to put complexity. In Verona, we’d really like to have Smalltalk-like user-defined flow control (though with static typing so that it can all be inlined in an ahead-of-time compiler with no overhead), where a match expression and a function call / lambda, and (checked) exception throwing / catching are the only things in the language and everything else is part of the standard library. This is a great thing for having a minimal language and also means that complex control flow constructs such as a range-based for loop for iterating over every other element of a collection in reverse order are as first-class as while loops.

We pushed quite a long way on this, but in a language that has linear types they add a huge amount of complexity in the type system. For example, consider this trivial case:

var x : iso; // Linear pointer to the entry point of a region.
if (a)
{
  doSomethingWith(x);
}
else
{
  doSomethingDifferentWith(x);
}

The two lambdas (braces are used to define zero-argument lambdas in Verona) both need to capture x, but x is a linear type and so they can’t both capture it. There are some details here around the fact that else is actually an infix operator applied to the result of if here that I’m going to ignore for now but even without that, we need to be able to express in the type system that:

• The if...else construct takes two lambda that take zero arguments.
• Each lambda must be callable once.
• We don’t need to be able to call both lambdas together and so it’s fine for calling one to implicitly invalidate the other.
• The construct will definitely call one or the other, and so any properties that are true at the end of both (e.g. that x is still valid and was not consumed) can be assumed for type checking the surrounding block.

This is incredibly complex to make work at all, making it work and be something that mere mortals can use is basically impossible, so we’ve punted on it for our MVP and will build some control-flow constructs into the language.

Glad you mentioned COM there.

I believe it’s time has almost come (again). The amount of resources squandered on writing yet another HTTP library is probably enormous.

Yes and no. On the one hand I like that approach and on the other hand stuff like the whole TS -> JS transpile (please excuse the vagueness, I don’t want to discuss it anymore) is a huge part of what people don’t like.

So I guess it still kinda depends on which runtime/intermediate you use and how the tooling reacts. Maybe the JS ecosystem is an outlier here because everything was a big ball of whatever anyway and then people also started writing stuff in another language (although coffeescript.. I don’t remember there being such a fuss over it not being direct JS…).