...yeah, that's really unfortunate. Part of why I said "in principle".

That would be helpful! Thank you.

Sorry, what project is this? GCC?

I didn't know about gitdm; that's a handy tool! Looks like those are just based on the domain of the email addresses used for commits, so it doesn't necessarily indicate whether the company employees people specifically to work on GCC. But I think you're right, that does indicate quite a lot of corporate support for the project.

Of course hardware vendors have a vested interested in GCC support, and of course there are a lot of people paid to work on GCC! But the claim above was that GCC and Linux are "mostly" maintained by people paid to work on them. I don't actually know how to measure that (I thought I might be able to find a quick answer by googling, but no such luck), but even if it's true now, I seriously doubt it's been true for the majority of GCC's very long history.

I also specifically didn't mention LLVM because it's very closely associated with both Apple and Google.

The other claim was that fewer Rust maintainers are paid to work on Rust. But there are in fact quite a few people paid to work on Rust full time, and there have been throughout its history; most obviously at Mozilla, but even though Mozilla has since let go of its Rust language team, Amazon has a significant team of Rust maintainers (several of them from Mozilla), and I believe Facebook, Microsoft, Intel, and possibly Google do as well.

So as far as I can tell, (early) GCC, Linux, and Rust all have a mix of paid and unpaid maintainers.

I don't know, but historically, for GCC at least, I wouldn't expect so, because it's so ideologically anti-corporate.

You agree with me so strongly that you started designing your own language?? Then why didn't you lead with that, since the post was asking for neolang recommendations??

Not unless you consider Go a "bigger" language than Rust. The blog post means "smaller" in terms of what the user has to learn and think about, rather than smaller in implementation size or resulting binary.

I do want to learn Haskell some day, but it seems like it has a whole different set of reasons why it's tricky to learn; and I hear enough about the more complex features (e.g. arrow notation) having compiler bugs that I think it really doesn't sound like a "smaller" or "simpler" language than Rust.

That said, yeah, it definitely meets the criteria of having strong typing, a functional style, a garbage collector, and pretty good performance.

"Faster/easier/less mental overhead" is indeed exactly what I mean by "convenient".

Maintainability is very different from "convenience", and I think we're both in agreement that Rust makes the correct tradeoff by favoring maintainability over convenience. But that doesn't mean that maintainability implies convenience!

I strongly prefer to write Rust versus "convenient" languages such as Python, Ruby, and (my least favorite, but the one I use most often professionally) Go. But that doesn't stop me from appreciating the benefits of "convenience"; and I think that there is room in the language design space for a slightly different tradeoff: something that isn't usable everywhere Rust is (e.g. it presumably wouldn't ever be a candidate for inclusion in the Linux kernel) but still has many of the same maintainability advantages.

Is there usually less parsing? I haven't participated in previous years. (I guess I can just check the previous years' problems, but there are a lot of those.)

Mac OS is also a big tech OS and arguably doesn't respect the user.

Linux is nice but often not an option for devs for circumstantial reasons, such as needing to use a corporate-provided machine for work.