I think "the bar" is talking about languages a developer might write her next application in. Mesa and CLU aren't on the list. OCaml might be, depending.

Except Rust modules (which are the subject here) are anything but innovative, there are plenty of languages since Mesa, CLU and ML came to the world with equally or better module systems.

Who invented modules first is moot when you're picking the language to write your next project in. Just like who invented the assembly line is moot when you are shopping for your next car. "The bar" for a car isn't Ford because Henry Ford was innovative. People don't really care about any of that when evaluating their next choice.

So what has Rust brought into modules to set the bar that isn't already available in other systems programming languages, with exception of C and C++?

Ok, I am bit harsh here, but for me there ARE no other systems languages except C, C++ and recently maybe Rust. I am also told, that in distant lands with strange and foreign customs, Ada is a systems language. (I don't know - no Ada missionaries have yet set foot on our shares and preached it to us.)

>no Ada missionaries have yet set foot on our shares

I'm not sure if 'shares' is a typo or not, but it fits great with my impression of why companies choose the languages they do sometimes: everyone else uses it (it's the local culture/custom), and nothing/no one has forced them to change (by lowering their profits/share value).

It was a typo, should have been "shores". However, it was a brilliant typo - the powers that be have decided on Greenhill and ClearCase. And the people who decide these things seem to be closer to the share holders than they are to us coders, so Ada missionaries on shares is maybe what it takes.

You would do yourself a favour to improve your CS skills regarding the history of computing, maybe you know, get to learn some interesting stuff.

There are YouTube videos....

A really damn good execution.

Which in my mind matters more than all this pedantry.

In what sense do Rust modules provide a better execution over Ada packages?

If we define "the bar" as "people's expectations for what a useable module system looks like" you can set it without being novel at all

Note that I didn't mention innovation or novelty or originality. I just said that Rust "set the bar." To respond to your objection I'd just clarify by qualifying it better and refer to the "systems programming" or whatever domain C/C++ and Rust both belong to.

So then check modules in Modula-2, Modula-2+, Modula-3, Ada, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Turbo Pascal.

All used in the context of systems programming.

Rust modules don't add anything new to them.

It adds an excellent packaging system and developer experience in the form of cargo, which is also a package manager for external modules. "The bar", I think, is taken to mean the combination of all of these features and their execution, not the idea of modules.

A packaging system is orthogonal to modules.

Those ideas are also present in Maven, Gradle, NuGet. All older than cargo.

And all trace back to CPAN as general concept.

I am still waiting for cargo to support binary libraries.

Rust has not brought much new in terms of modules. It just has decent modules support according to established best-practice. The innovations are primarily around the borrow-checker.

That I agree with.

There are plenty of widely-used languages that have modules and came well before rust.

You seem to be responding to a claim that Rust invented modules, but I think nobody said that.

Nothing in Rust is original from PL theory perspective. It's deliberately not a research language, but a practical one. Rust set the bar here merely by showing up and delivering a decent implementation (in a language that you can actually use today).

Rust sets the bar with the borrow checker and safer concurrency.

Everything in terms of safety and modules was present in languages like Ada and Modula-3.

The word "module" has very different meanings. When I read about 1ml [0] I stumbled upon this:

> A definition like this, where the choice of an implementation is dependent on dynamics, is entirely natural in object-oriented languages. Yet, it is not expressible with ordinary ML modules.

Here, ML modules are compared to classes (not packages or modules has defined in Java, for example). This makes me wonder how often people talk past each other without noticing, when they discuss modules.

[0] https://people.mpi-sws.org/~rossberg/1ml/1ml.pdf

True, but there is an actual definition.

https://en.wikipedia.org/wiki/Modular_programming

There are plenty CS books which offer a similar definition to Wikipedia.

For Java, class, package and (Java 9 Jigsaw) module all fit the Wikipedia definition of module.

We might have consensus about the definition, but it does not seem to be a useful precise one. The C++ working group seems to have a similar problem. Things like "compilation unit" have a precise meaning, but they cannot find consensus if it should relate to their "module" or not.

The basic concept of module is having language support for code separation, with data/code hiding, compiler type checking across modules and optimally a binary format.

I think the issue is more with some C++ devs that never used other languages, trying to grasp how modules fit into translation unit + PCH model they know.