Hacker News Reader

Comment by wyldfire | Hacker News Reader

> Effectively, without support for build tools, modules are effectively dead in the water.

...

> "We'll make the build systems understand".

This seems to be a critical point that I agree with: you can't divorce these two, their fates must be bound to one another. Hopefully the build systems can be easily modified to accommodate.

Rust community folks might be wrong about c++ but they're right about Rust. Rust had the luxury of not being bound to any legacy specifications and it wasn't unreasonable for them to write their own build+dependency/package management tool. The net effect of them having done that means that independent of all the other great things Rust brings, much of the tedium of developing with C/C++ is gone.

Make no mistake, C++ standard committee: the bar is high and Rust has set the bar.

View on HN

> the bar is high and Rust has set the bar.

Modules were introduced in the 70's as concept, Mesa being one of the first languages to use them, followed by CLU and ML....

The issue with lack of modules in C++, was that Bjarne had the compromise C++ should fit into C toolchains used by AT&T, and later all C shops.

EDIT: I get Rust is quite cool, but maybe a bit of programming language research is also welcomed.

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.

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.

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.

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.

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++?

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?

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....

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

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

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.

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 bar is high and Rust has set the bar

I don't think Rust deserves much praise for its module system. It is widely regarded as being extremely confusing even for pros. There are efforts underway to make it saner:

https://withoutboats.github.io/blog/rust/2017/01/04/the-rust...

https://github.com/rust-lang/rfcs/pull/2126

> It is widely regarded as being extremely confusing even for pros.

No, it's mostly considered to be unintuitive, not confusing for people who know it. You're unlikely to "just get" how it works, but once you learn it it's perfectly reasonable.

Edit: Note that the RFCs don't actually change how the module system works, just the syntax

I would like modules to fix the issues with the header inclusion model and hundreds of thousand lines long translation units.

Anything else is mission creep at this point and risk delaying the effort further. Let's fix a problem at a time.

Weren't modules created by Herb Sutter at Microsoft to improve the VS201x IDe and compiler? If this is the case, it seems a big player in the tooling world is already on board.

No, Apple designed them for Objective-C initially, so some support was added to clang for all C languages, based on module maps.

Google improved that implementation for C++ and has a private implementation of it in use.

Gabriel dos Reis picked up some ideas from a former work he did together with Bjarne for MSVC++.

The ongoing C++ Modules TS is to merge the ideas from both sides into what will become C++ Modules.

Hmm, I suppose I was talking about the specific work to integrate modules in to the C++ standard. I recall hearing from Bjarne at a STAC talk he gave a year (or so) ago that he and Herb had been coordinating effort between MS and MSFT to use Modules in the Microsoft toolset to improve compiler performance.

The history of modules you provided is helpful though, thanks.

C++ has taken new features like auto and static if from D, not from Rust.

I would say for the C++ standard committee the bar is high and D has already set the bar.

Reply on news.ycombinator.com