Hacker News Reader

Comment by matheusmoreira | Hacker News Reader

> textual requires and module system could’ve been much cleaner

This irritated me a lot when I was a ruby programmer. Ruby's require is analogous to C's #include: modules are just files that get evaluated in order to add stuff to a global interpreter state.

It got to the point I went around asking people on IRC what they thought the perfect module system looked like. Studied long forgotten languages to see how they did it. To this day I'm obsessed with this. I feel like it's one of those things you just have to get right since day one because it's gonna be impossible to change it later.

View on HN

It mostly comes from the intentional design of open classes, thus the namespace organisation is fundamentally decoupled from the filesystem: any Ruby file has to be able to contain any class/module, otherwise one can't add to an open class/module†!

There are a bunch of issues about this upstream about this, e.g: https://bugs.ruby-lang.org/issues/14982

My exploratory take on it: https://github.com/lloeki/package-ruby

I'm currently drafting a proposal and planning to open another one, more focused on a specific aspect and a different angle, and thus with a couple of comparative PoCs that'll be a bit different from my above exploratory attempt.

† ... via `class` and `module` keywords, as one could always include/extend/prepend or use `module_eval`/`class_eval`/`instance_eval`.

At first glance that makes a lot of sense given Ruby's open classes and extreme dynamism. On closer examination though I conclude open classes are not mutually exclusive with a proper modules system.

Ruby's classes are reified as normal objects. A module system manages names, symbols, references to those objects. To modify a class we just need its object, which name it comes from doesn't really matter. We'd be able to modify classes even if Ruby had a real modules system. All we need to do is get a reference to that class object, probably by importing it from somewhere into the current namespace.

Ruby does exactly that already. Every class just happens to get stored as a constant of the Object class. So creating a class A just stores the new Class instance in ::Object::A which is totally weird when I think about it. And when programmers write A, Ruby looks up the constant in current scopes and eventually finds ::Object::A which contains the Class instance. A proper modules system would allow programmers to define where that object ends up or gets pulled from.

I was mostly outlining where it came from, as in, what is the original design. Doesn't mean it can't do other things.

And actually it can, which is part of my initial proposal with the linked repo, and goes much more in depth in my pending, non-public draft.

JavaScript’s modules only changed because the toolchain rapidly iterated several times over the course of a decade. Most languages don’t see this kind of churn. Even then the migration is at best partial.

I've been fighting JS/TS because I went with ESM over CJS for one of my new projects. It's an endless minefield of configuration issues, crappy-to-none support from widely used libraries and half-baked tooling. There's also generally no (up to date at least) documentation, so most knowledge comes from random Github issues with magical incantations to copy-paste into your configs. I must have wasted weeks worth of time on this busywork and there's no end in sight since any new library might accidentally trigger some new edge case.

So yeah, I'd agree with saying the migration is partial at best.

> Ruby's require is analogous to C's #include: modules are just files that get evaluated in order to add stuff to a global interpreter state.

What's the theoretical alternative? Adding stuff to a global interpreter state is the goal.

The weird part of #include, to me, is not that it ends up modifying the global interpreter state. That's the point of calling it! The weird part, what C libraries tie themselves into endless knots to work around, is that when you #include something in more than one place, it will execute more than once.

There's at least a few? E.g.

* Lexical scoped imports a-la python

* Pass state to modules explicitly, which I think is what newspeak was doing (i.e there's no global state)

Either way you'd lose ruby's "let's add methods to Kernel and have them pop up everywhere" so it's a trade off.

Worth nothing: there are a few proposals around to have some sort of namespaces in Ruby, but it's unclear they'll ever happen.

E.g.

https://bugs.ruby-lang.org/issues/19744

> Lexical scoped imports a-la python

How is this an alternative to modifying the global interpreter state?

Before I do any imports, I can type this:

    os.getcwd()

and the interpreter will crash, telling me that "os" doesn't mean anything.

But if I do this:

    import os

then, later, I can type exactly the same thing:

    os.getcwd()

and the interpreter will call the function and return a string.

In order for the interpreter's behavior to be different when presented with exactly the same input, it's necessary that the state of the interpreter has changed. What's the alternative?

And since this is the entire purpose of a module system -- causing the global interpreter to recognize names that it otherwise wouldn't have -- it follows immediately that all module systems will operate by making changes to a global interpreter state.

The reason Python's module system is better than C's has nothing to do with whether or not either system modifies a global interpreter state, since that doesn't differ between the systems. The reason is that Python allows you to specify what you want those modifications to be. If I have two Python libraries named os, I can import them like so:

    from lib1 import os
    from lib2 import os as os2

and now they don't conflict. As far as I know, C has no such facility.

> it follows immediately that all module systems will operate by making changes to a global interpreter state.

No, it doesn't?

    def print_sysinfo():
        import sys, os
        print (f'{sys.platform} {sys.version}, current dir is {os.getcwd()}'

    os.getcwd()  # throws NameError, because os is not a thing there.

Now, you may argue that the 'os' module is still loaded after a call to print_sysinfo() and while it's true, it didn't have to be so: Python could as well had have semantics of unloading modules that have zero references to them, and re-loading them anew every time they are imported again.

A language can have locally-scoped module semantics, it just that most of the time the static/global scope is much more convenient.

What happens here?

    ---main.c----
    void f(void);

    int main(void) {
      int a = 0;
      f();
      return a;
    }

    void f(void) {
    #include aux.c
    }

    ---aux.c-----
    int a = 1;

By your argument, #include doesn't make changes to global interpreter state either. Is there a sense in which the #include preprocessor directive works by making changes to the state of the global interpreter, but Python's import mechanics don't work by doing the same thing?

There's only one interpreter and your goal is to make a change to its state. Hence, "global interpreter state". The change you make can affect behavior in, in principle, any context in which the interpreter is used. Could be inside the definition of `f()`. Could be outside the definition of `f()`. There's no difference in the mechanics.

At that point everything is "a change to global interpreter state", even a locally created object allocates memory from a global allocator. So clearly this distinction as you present it doesn't matter.

What matters is language (not interpreter) semantics, here it's about variable scoping. In C, if I include "a.h" and then "b.h", "b.h" will have access to definitions from "a.h", even though lexically they were never brought into scope in that file. This is an actual problem that C/C++ developers have to deal with, since it makes it hard to create isolated headers.

In Python, the code in each module is evaluated in an isolated context, and returned as an object, so this isn't a problem. Edge cases like monkey patching don't really matter for >99% of usecases.

> At that point everything is "a change to global interpreter state", even a locally created object allocates memory from a global allocator.

Why is that a change to the interpreter state? Consider some more C:

    {
      int a = 1;
      a = 2;
      a = 3;
    }

The line declaring `a` makes a change to the interpreter state; `a` becomes a reference to something. Without line 1, lines 2 and 3 are invalid.

The two lines after that, manipulating the value of `a`, don't make any such change. If you delete line 2, line 3 will be handled in exactly the same way as otherwise.

The reassignments to `a` make changes to the program's runtime state, but they have no effect on the interpreter. The braces, which I guess I have to call lines 0 and 4, are the opposite - they're very relevant to the interpreter, but it's hard to give them a runtime interpretation.

You have a very specific idea of what an "interpreter" is that I don't think matches the standard usage. The debate would be better served if we spoke in more concrete terms such as local/global scope, parser, analyser, AST or runtime library.

I've taken the word from the comment I responded to. It appears to refer to the part of the process that is responsible for determining what a line of code written by the programmer is supposed to do.

The particular task of resolving references isn't necessarily handled by anything you mentioned - it is the job of the parser to determine that a reference is being made, but not whether that reference goes anywhere. Similarly, this information is not included in the abstract syntax tree, which is fundamentally the same thing as the parser. It's perfectly possible to form a syntax tree that calls for the invocation of a function that doesn't exist, or assignment to a variable that doesn't exist.

In C writing an invocation of a function that doesn't exist will give you a compiler error, but in Python it won't; you'll get working code that trusts that whenever it happens to be invoked, the function will exist. And if, at invocation time, it doesn't, you'll get a runtime error instead.

Since this is the problem being addressed by the "interpreter", it appears to be the case that the interpreter in C exists at a different point of the compilation-execution pipeline than the interpreter in Python. The logical steps of determining what a program does need not coincide with the physical steps that are taken to convert the program into an executable artifact - or more fastidiously, they don't need to occur in the same order from program to program, and might be bundled with different other steps.

But what I've claimed is that the import facility, whatever it might be, is responsible for making changes to the state of the interpreter, wherever the interpreter might be active. It makes the difference between "the programmer has specified doing something meaningless" and "the programmer has specified doing something meaningful", and the meaning that it provides gets loaded into the state of the interpreter. It is not strictly necessary that this occur at the top level of the program, the global scope, but it is almost always the case because that is the scope where programmers almost always want imported code to be available to them.

> In C, if I include "a.h" and then "b.h", "b.h" will have access to definitions from "a.h", even though lexically they were never brought into scope in that file.

This actually appears to be the opposite of the normal concern with lexical scope. Lexical scope allows names defined at a higher scope to be accessed from a lower scope, but that's precisely what you're trying to prevent here.

It's worth noting that b.c is compiled without any knowledge of a.h or a.c (assuming it doesn't itself #include a.h, which would make the problem you mention something intentional instead of a pitfall). "libb" doesn't suffer any problems from being #included after "liba". The problem occurs in your code, where you have access to definitions from both header files, which is what you wanted when you #included both of them.

> There's only one interpreter and your goal is to make a change to its state. Hence, "global interpreter state"

There is only one memory space in the process hence no variables are local. Well, this is true, in a sense, but I don't think it's a particularly useful perspective. Also, see the sibling comment.

I expect _global_ here refers to the language-level semantics, not internal interpreter semantics.

Python's module system results in no implicit modifications to Python-level state between modules — at least, for a well-developed module. Since Python is so dynamic, you can of course jerry-rig all sorts of global consequences if you really want to. But without dynamic magic, all state is namespaced to the imported module, and must be explicitly given names within the importer, with no global consequences for parallel modules.

In your os.getcwd() example, the state is scoped to the importer module, so it's not an example of global interpreter state.

I don't know what Ruby's module system looks like, so I don't know for sure if that is the point the GP is making. It seems to me that you are in agreement, just disagree with the meaning of "global" in this context.

Ruby's modules are namespaces (well objects that are deeply similar to class objects, but not identical), but Ruby files aren't modules, they are executed in the global environment, and may (or may not) define (or redefine, modules are mutable) modules, and any such modules may or may not have any relationship to the file name and relative path location.

But by this interpretation, the description of #include is incorrect, and `require` wouldn't be analogous to `#include`. That #included code appears at the highest scope in a file is a coding convention, not a fact about the preprocessor. That's just the place where people like to put their #include directives.

The reason they do that, of course, is that they want to be able to access #included code from the highest scope in their file. But once that's the requirement, we're back to saying that this is the goal of all module systems, and all of them will modify the global namespace in this way.

> all state is namespaced to the imported module, and must be explicitly given names within the importer, with no global consequences for parallel modules.

This is just false; state appears within the interpreter in the form of registering the imported module under the provided name. You are free to register a name that's already in use, in which case you will lose the ability to refer to the module that was registered with the same name earlier. Becoming unreachable is ordinarily considered a "consequence"; you can find people complaining that this has happened to them.

Why does the problem arise? Because importing means making changes to the state of the interpreter.

>In order for the interpreter's behavior to be different when presented with exactly the same input, it's necessary that the state of the interpreter has changed. What's the alternative?

I guess that scoped changes is an option, that is you ask to alter the interpreter behavior only in a lexical scoped.

Ruby has refinement in this spirit, though it’s not exactly operating at the same level as a require.

Here is a related discussion that arised in Crystal community a few years ago: https://github.com/crystal-lang/crystal/issues/4439

If you qualify imports transitive dependencies won’t pollute your scope. It also naturally deals better with name conflicts, allows cherry picking exports etc.

OK, where's the part of this where we're not modifying a global interpreter state?

You’re taking the use of the word “state” too literally. The original comment was complaining about how Ruby `require` adds names (constants) to a global namespace; Python `import` only binds names in the local scope.

By that definition I would not say any language has modules. Even compiled ones

I think I expressed myself poorly. You're correct that the ultimate result of all useful code is changes to interpreter state. Even a simple variable assignment creates an object in memory and a mapping from the variable to that object.

I meant to allude to the fact Ruby has a single global namespace that all Ruby code adds bindings to. In Ruby we have to manually namespace stuff just like we add prefixes to functions in C. Python on the other hand creates isolated namespaces for each module which makes it impossible for them to clobber each other. Import creates links between those isolated namespaces.

There's another big difference between Python and C (and I don't know how Ruby does it):

When a module is imported, the file is evaluated once, then stored in memory as a stateful object. Further imports of the same module, even from other files, reference the object in memory instead of evaluating the module again.

The dict used for this is accessible in sys.modules

The alternative is isolated namespaces. Every module maintains an independent symbol table.

OK, so now we load the module, it maintains its own independent symbol table, and we have no way to access that table. Our code is unable to use the module, but at least we can content ourselves that it's loaded. (On the other hand, why bother giving it a symbol table at all?)

What if I want to write some code that will use the module I've loaded?

> and we have no way to access that table

Correct. We must create such mechanisms. The aptly named import mechanism seems to be the most common solution to that problem.

There's a heap with objects floating freely around, and two tables of symbols and the objects they point to. The sets of symbols in each table may intersect freely: both tables might have an "X" symbol without clashing with one another. On the other hand, there's no intersection between the sets of objects they point to at first. They start out fully isolated and their values are unreachable from the outside.

As you noted, this is of limited usefulness to programmers. There's no point in collecting symbols into a module if the values those symbols point to are unreachable. We need access to foreign symbols in order to make use of abstraction. To that end, the implementation may provide a symbol importing mechanism. It could be as simple as setting a symbol on the current table to the object pointed to by a symbol of the other table. In fact that's exactly how I implemented it in my language.

So this "imports" the symbol from another table to the current one. Both tables were completely isolated at first but now there are explicit links from one table to the other: there's two symbols from two separate modules pointing to the same object in memory, linking one module to the other. That object is most likely a function and importing it allows the programmer to call it.

> On the other hand, why bother giving it a symbol table at all?

Because symbol tables are how variables are implemented. They're literal hash tables mapping symbols to arbitrary values, symbols are just unique strings. If you don't give modules a symbol table, you are unable to set variables at the module level.

> As you noted, this is of limited usefulness to programmers. There's no point in collecting symbols into a module if the values those symbols point to are unreachable. We need access to foreign symbols in order to make use of abstraction. To that end, the implementation may provide a symbol importing mechanism. It could be as simple as setting a symbol on the current table to the object pointed to by a symbol of the other table. In fact that's exactly how I implemented it in my language.

> So this "imports" the symbol from another table to the current one.

So in this terminology, we can "load" a module and this has absolutely no benefits, except that we can subsequently "import" the same module and importing gets us what we want, the ability to refer to the imported code.

We accomplish the import by making a change to the global symbol table, inserting references to objects within the module.

Is this different from what I've been saying above? The entire purpose of loading a module is to add things to the global interpreter state. Why is this an "alternative" to adding things to the global state?

I think I expressed myself poorly in my original post. You're correct that the ultimate result of all useful code produces changes in the interpreter's internal state. Even a simple variable assignment creates an object in memory and a mapping from the variable to that object.

> So in this terminology, we can "load" a module and this has absolutely no benefits, except that we can subsequently "import" the same module and importing gets us what we want, the ability to refer to the imported code.

Yes. We load modules, and we import symbols from already loaded modules. In most if not all languages I've learned, importing symbols loads the referenced module implicitly but it most definitely is a distinct operation.

Loading means reading the module's code from somewhere, usually the file system, and placing it into memory, then evaluating the code to obtain the resulting bindings, code like:

  module xf
  x = 10
  f = (y) { y + 10 }
  z = x + f(80)

The result of loading a module is just a hash table binding variables to their values, just like Javascript's require.

  modules["xf"] = {
    name: "xf",
    bindings: {
      x: 10,
      z: 100,
      f: {
        type: function,
        arguments: ["y"],
        code: "y + 10"
      }
    }
  }

This is also true of native modules like ELF libraries, they contain the exact same table of symbols, the only difference is this evaluation is done ahead of time by the compiler. This hash table is almost always cached by the implementation so that it does not need to be loaded again.

Importing essentially does this:

  xf = modules["xf"]
  bindings = xf["bindings"]

  x = bindings["x"]
  f = bindings["f"]
  z = bindings["z"]

Naturally, the modules object must contain a "xf" key pointing to a module object containing the bindings for "x" and "f" and "z". Loading a module puts the module object in the modules cache.

So loading a module without importing their symbols could present benefits. In most languages, they are lazily loaded, work is done only when they are referenced. You might prefer to load everything up front while the program is starting up though. I went through quite the adventure to embed lisp code into an ELF binary in such a way that Linux would automatically map the code in before the program even started executing. Having my interpreter import the symbols from the embedded modules which are already in memory was relatively trivial.

> The entire purpose of loading a module is to add things to the global interpreter state. Why is this an "alternative" to adding things to the global state?

Yes. The interpreter could maintain one namespace and make it so that all code modifies that namespace. It could also maintain a separate namespace for each logical module. In the latter case, changes are local rather than global, even though they're all part of the global state of an interpreter program.

It's analogous to git repositories being local and distributed even though everyone is using the same git implementation to operate on them.

> What's the theoretical alternative? Adding stuff to a global interpreter state is the goal.

This is the right way to do it but it suffers from a lack of correct tooling. The Self[0] programming environment assigns a "module" to each "slot" (class methods in Ruby land); an object may be composed from multiple modules at once. If Ruby had this kind of granularity in its inclusion system I believe that a lot of the confusion around where a particular method comes from would disappear.

[0]: https://selflanguage.org/

Waitwhat, surely it's not GLOBAL state, but "module global" or something?

In Ruby, it really is global. Imports can (and do) modify the behavior of the stdlib, and any other libraries' namespaces in the same way that they would manipulate their "own" code and data.

I mean, sure, the monkey patching/extending is a thing. But if you import "foo" in one ruby file, surely it doesn't pollute the namespace of all other ruby files loaded after with that symbol in their global scope?

Any results from your research? That seems interesting.

Research is a bit too strong a word for it but I'll summarize my conclusions.

Most people I talked with seemed used to and very happy with the Python model: modules are distinct namespaces for symbols and their referenced objects. Pretty much everyone I talked to had no difficulty understanding modules, it's always the package management that makes things complex no matter which language it is.

Something I spent quite a bit of time thinking about was whether it was worth reifying that model into the language as first class objects. In other words, should import be a special keyword that makes the interpreter magically bind symbols or a function which returns a regular everyday normal object? At the end of the day, Python's modules are just dictionaries, just like Javascript modules. Should I make that fact apparent or hide it behind language keywords? Interestingly, both languages went in the opposite directions: Python went from special import syntax to allowing you to access modules as a dictionary, while Javascript went from a require function that returns an object to an import statement. I ultimately chose a somewhat weird mix of both, powered by lisp's flexibility.

I also tried to figure out how compiled languages approached modules. So I dug up literature on Modula, Modula-2 and Oberon and tried to figure out how they represented modules. This ended up having a significant influence in my design in the form of isolated modules with export control. Each module contains its own table of symbols and their references. Importing is just setting a local symbol to the value of the other module's symbol, and only symbols in the exports list can be imported. I also liked the qualified and unqualified names: added the option to prefix the module name to the local symbol.

I also thought a lot about how to map modules to the file system. The idea of program folders from Windows has been an inspiration for a long time now. The idea is if the module itself is reachable then all of its submodules are also reachable by the loader. I also think it's important that no file escapes the package directory. Python and Ruby frequently have thing.{rb,py} scripts and thing/ directories side-by-side, I sought to eliminate that for the module's root directory only which results in a main file like thing/thing.{rb,py}.

To enable module-oriented development, I've found the most important feature of the modules and packaging system is editable libraries. Like pip's editable installs and npm link. When I develop a project, I often end up with several supporting libraries. Languages should support linking these local versions to the main project so they can be developed simultaneously.

Thanks for response. Some of these thoughts floated around in my head as well, though less ordered and well articulated.

One thought regarding the quantification element. I’ve grown to appreciate the uniformity of Go’s solution, where you always import an entire namespace, optionally aliasing it to avoid conflicts.

This small restriction makes some naming decisions simpler (for example sticking to config.Parse, and not the stuttering config.ParseConfig). Additionally it sprinkles the namespaces over the code so you get at least _some_ feel for them.

On another note, on some occasions I have thought to myself that it’s easy for the import section to get to little scrutiny on reviews, and wondered if there’s something that could make us wonder „should x depend on y?” more often.

> I’ve grown to appreciate the uniformity of Go’s solution, where you always import an entire namespace, optionally aliasing it to avoid conflicts.

That's a very good solution in general which makes everything uniform and consistent. It's only due to my personal tastes that I didn't implement it that way.

I'm obsessed with symbol management. I'm so obsessed with this I wrote my language in freestanding C just so there would be no libc and compiler cruft in the resulting ELF binary. I'd rather deal with complexity than see weird doubly underscored stuff in readelf output.

Names are everything in computer science. I have some kind of psychological need to have clean names. For that I need clean namespaces that I can shape to my will. So I absolutely wanted the ability to import only the symbols I needed in order to minimize the pollution of the namespaces. I support just importing everything as a convenience but I personally never use that feature. I also made sure I had the ability to rename imported symbols to anything I wanted just in case other programmers aren't as obsessed with names as I am.

I went so far with this I implemented basic control flow as a library of lisp macros. There are no reserved keywords or special cases, they're just normal functions that get imported like all the others. Thus they can be renamed or avoided entirely. In fact I made it so only two symbols are present in every namespace: import and export. And those can be overridden too after the programmer is done with them.

I probably have more than few screws loose or something. Go's approach is totally reasonable. Instead of importing N symbols from a module, it imports 1 symbol and nests all N symbols under it, and if there's a clash you only need to rename the module prefix. It's nice and creates single points of truth.

... Now that I think about it, the only reason I didn't implement it the Go way is I didn't want to add special syntax for nested symbols to my language. In other words, in my language "config.Parse" is a single symbol instead of a "config" + "Parse" pair. I feel like it just wouldn't be lisp anymore if I added syntax to decompose the former into the latter.

> sticking to config.Parse, and not the stuttering config.ParseConfig

Yes. I find the stuttering repetition in your latter example to be profoundly irritating and a symptom of a bad modules system. In my language I tried to prevent that by making it easy to add or remove module prefixes to the imported symbols. I also made it easy to rename symbols for good measure just in case people did it anyway.

Have you looked into the "first class modules" system used by ocaml? AFAIK it's the only language of its maturity to use something like it. It's very powerful without adding mandatory complexity. But because basically no one comes to it with prior experience in a similar approach, it's hard to gauge how powerful, or when the added complexity of using it fully is actually worth it.

I have! I didn't reflect much on it though because I'm focused on creating a dynamic language. Perhaps I did not understand it?

Another interesting concept I ran into while researching modules is parameterized modules. Essentially, modules that take their dependencies as arguments. The modular equivalent to dependency injection I suppose. Instead of a module importing by symbol a specific library as a dependency and some package manager resolving it to actual files in the load path later on, the programmer explicitly loads the library and passes it to the module as an argument.

Instead of the symbolic imports we're all used to:

  (import lib); lib imports lib2 internally

Module importing becomes analogous to function calls which construct an instance of the module given its dependencies:

  (import (lib2))
  (import (lib lib2))

This is really elegant and more or less reifies package management into the language. However, it presents serious ergonomics issues because it forces the programmer to deal with all these package management and library loading details. The truth is we want to sweep all that ugly stuff under the rug, not deal with it every single time we import a module.

The main benefit, the loose coupling that stems from the ability to substitute dependencies without having to change the importing module, can be accomplished in a declarative manner via package managers. Arch Linux packages for example may have a "provides" variable which allows multiple packages to implement an interface of sorts and be used interchangeably to satisfy dependencies. So I think parameterized modules imposed significant costs for little benefit.

So who does it right? Or at least good?

And what is your hot take on what Python does?

I think Python does it mostly right as far as dynamic languages go. Like Ruby, modules are programs which run from start to end, altering interpreter state as they go. Unlike Ruby, Python modules execute in a local context which provides isolation. Ruby libraries all share the same global namespace and can clash with each other. Python and Ruby have the same flaw in that they do not have export control. Everything that gets set also gets exported. Ruby excludes only local variables while Python relies on convention.

Javascript's system is essentially the same as Python's but with require being a function that returns normal objects instead of an import keyword which magically sets the symbols. At least it was back then, new versions of the language transitioned to a dedicated import keyword. I found the reification of modules into first class objects to be an elegant design, not sure if they discovered problems with it or if they were severe enough to justify that transition.

I think a mixture of both plus export control would be best. Syntax is friendly and good for most uses but a function that returns a reified module object is also important since it allows programmatic access to modules, allows creating plugin architectures and much more.

I wouldn't call what Ruby has a module system because it is just linear textual require.

Reply on news.ycombinator.com