I’ll answer what I think is the more interesting topic first (i.e. licensing is discussed at the bottom):

To start, for Rust to a larger degree than Scala, I certainly don’t think the language lacks merit. I am convinced the hype around Rust and its momentum in conversation did it a tremendous favor as it was coming up to 1.0 and as it went through ~2021. I do have some serious technical issues with choices Rust as a programming language made, but while I believe a change in direction for Rust would be beneficial, the ecosystem advancement and entrenchment of Rust makes it basically a non-starter as of 2025.

From a philosophical perspective (and I know I am an extreme outlier) I think, in the large, society and industry would be better served by having no ‘large’ programming languages. If every company was use to and had to invent at a minimum their own dialect of a broadly defined language types and then train employees to function within their language environment I would be thrilled.

The above would do a considerable amount to stop corporations from treating programmer like replaceable/disposable cogs in a machine. It would also end the ability of conglomerates from stealing the work of others wholesale as there wouldn’t be a single JavaScript, but a fleet of JavaScript suited to developing different classes of frontends. And hopefully, if a language was never as widespread as C, then hardware manufacturers would not be catering ISAs to fit the mythical ‘C Programmer’s’ model of how a computer works, thereby allowing for actually useful low level languages to be developed to fit the evolving features of what hardware actually does. (This point is basically a rip off of Chisnall’s “C is not a low level Language” article)

The lack of widely popular languages would also prevent the situation I see with Rust, which is really a first to market and good enough problem. I could go on at length about Rust’s commitment to the ownership semantics and its coupling with single mut XOR multi immut, but where it really hurts for me is that Rust’s pervasiveness prevents moving to a better option in the space due to moneyed interest and cultural buyin.

However, neither of the above are meant to fault Rust’s use for software engineering. It seems to be a good tool for many and is seeing acceptance at a rate that seems miraculous. My dislike of the language may result from fundamental disagreements about programming, type theory, and language “culture” but I have never said people should not build new software using Rust (although without using Cargo, info had a say).

—-

As to licensing, I agree with your general thought that I am basically tilting at windmills with my stance toward non-copyleft licensing. I think you are accurately describing the current state of affairs as well. However, a more vicious form of licensing, source broadcasting, literal viral attestation code, alteration aware self destructs, etc. I routinely refuse to give legal advice on licensing because it is such an untested and nearly unenforceable area of contract law, but I can’t help but feel there is some way to legally (or at least dangerously) put some teeth into software that is being exploited.

NB: I'm not the person you were responding to.

> I am strongly adverse to package managers

This has nothing to do with Rust the language, other than the incidental fact that cargo happens to be bundled with Rust. There are no cargo-specific concepts whatsoever in the Rust language, just like there are no Cmake-specific concepts in C++. I know you alluded to this in your post; I just want to make sure it's crystal clear to everyone reading.

Consequently, people can, and do, use Rust without Cargo. That is obviously not what the majority does, because cargo is so easy to use with rust, but it is certainly possible both in theory and in practice.

If it's a "point of pride in the community" and "idiomatic" -- who cares? Rust is a general-purpose systems programming language. You can use it however you want, without listening to what people on Twitter think about it.

This particular complaint strikes me as social/cultural rather than technical -- "people who like Rust do something I find annoying, therefore I must conclude that they're not of my tribe, and reject rust". That is very understandable human nature, but not logically justified.

As for your other two complaints, you are correct that they are fundamental to the language and will never change for at least as long as the language is called "rust".

But since these complaints are totally subjective (a reasonable person might like or dislike them), it doesn't really seem fair to bitch about a language existing and becoming popular that has these properties.

For example, I complain about Go because I think it has actual defects that make it harder to use for almost any competent programmer. I also don't like Python, but I think the tradeoffs it chose to make are at least intelligible and some people prefer the Python style, so it would make no sense for me to complain that other people use it in their projects.

> I have strong philosophical disagreements with ad-hoc polymorphism in general

What disagreements are those, if you don't mind typing more? PL design is something I'm interested in but not particularly experienced with so more perspectives are always nice to hear.

> I can not see a world where Rust adopts Haskell's position on the typeclass system being a convenient syntax sugar for a non-primitive and more explicit semantic form.

As someone who isn't familiar with Haskell, do you mind elaborating on Haskell's syntax sugar and what it reduces to?

In (2), I'm surprised to hear your description of Rust's generics as "ad-hoc polymorphism". I tend to hear that term used to describe non-trait based systems, like C++ generics (in the absence of "concepts"), which act like a compile-time version of duck typing. I think of Rust's generics as trait-based polymorphism, not ad-hoc polymorphism, and I prefer the former over the latter. To a first approximation, I see Rust's generics system as somewhat related to Haskell's. I would be interested to better understand how you see the differences.

From the way you're describing it, it sounds like you might not fundamentally object to generics in general, just to the idea of doing it through monomorphization rather than "dyn Trait"-style vtables? If so, then that's understandable. I like that Rust has both options, but I can absolutely appreciate preferring to do everything via vtables, which has both advantages (code size, one kind of conceptual simplicity) and disadvantages (more difficult to do per-implementation optimization, without doing devirtualization which amounts to monomorphization anyway).

We do have some forms of first-class "type functions" or "type constructors" or "rank-2 polymorphism", in the style of Haskell, so that you can be generic over something like `Vec`. It's a little indirect at the moment, going through traits with associated types, and I'd love to see a more direct version where you can literally write `Something<HashMap>` or `Something<BTreeMap>` and have those be type functions of one parameter (Haskell "kind" star -> star).

In any case, we have talked many many times about the idea of having more global options to say "don't monomorphize by default, do everything with trait objects". We also are likely to build a stable ABI atop trait objects and vtables eventually, so that it's possible to pass around pointers to data structures and their associated functions, without relying on the layout of the structure.

For (1), I do think we need some mechanism to integrate dependencies. I can appreciate the aversion to the default of "get things from the network". We do try to have good support for vendoring and similar, and this is critical for many projects (e.g. Rust in the Linux kernel, or Rust in CPython, are not going to allow downloading dependencies from the network). All that said, there is a tradeoff between "one first-class package manager and build system" and "lackluster support for various build systems", and Rust picked the former deliberately. We do like being able to implement things in rustc and plumb them through Cargo, so that they're available through the whole stack when that's necessary to make a feature useful. But we also have many users who need to use rustc without cargo, and who ensure that rustc features work with other build systems, notably large corporate monorepo build systems.

As for (3), fair enough, that is very much a philosophical difference between you and Rust, and Rust isn't likely to change that. I do think we're going to make ever more sophisticated ownership semantics in the future (e.g. making self-referential data structures possible), but I doubt Rust's model will stop fundamentally being based around ownership and borrowing.