GCC Rust Approved By Steering Committee, Likely To Land For GCC 13

[uid313]

Rust's module system isn't strictly tied to the filesystem layout for two reasons:

1. Modules are the unit of public/private access control, so it's very valuable to be able to use an inline module without a separate file by going mod foo { ... }.
2. Being able to annotate mod foo; with #[path="some/path/to/the/file.rs"] helps with exposing a clean API for programmatically generated code like bindings.

That mod foo { ... } thing is another thing I dislike and find confusing.

mod foo; is equivalent to something like import foo in Python while use is equivalent to FROB = foo.MyEnum.FROB but without the whole "global-scope declarations and function definitions are still assignments executed at runtime" thing Python has... and yes, use can pull variant names of enums out of their namespaces. That's why you don't have to type Result::Ok or Option::Some in your returns.

Yeah, it is nice to be able to return just Ok() instead of Result::Ok().

The ones I'm familiar with are:

• use ::foo::bar; (Absolutely rooted. Equivalent to filesystem paths beginning with / )
• use crate::foo::bar; (Crate-relative without having to duplicate the crate's name throughout the codebase. If the current crate is named frob, equivalent to use ::frob::foo::bar; )
• use super::foo::bar; (Parent-relative. Mainly used for situations where you'll either have a mod test { ... } annotated with #[cfg(test)] for conditional compilation or for inside a mod foo { ... } that exists within the same file purely as a public/private access boundary.)

There's also a self keyword that's used for things like collapsing use std:ath; and use::std:ath::PathBuf; into use std:ath::{self, PathBuf};

Yeah that all is pretty overwhelming and overly complicated to me. Other languages dont have that, it's so much easier in other languages.
Other languages just have namespaces, then you import that namespace, super easy.

Originally, Rust simply required you to have foo/mod.rs if you wanted mod foo; to have submodules, similar to foo/__init__.py in Python, but people complained about too many mod.rs tabs in their Vim and about having to git mv foo.rs foo/mod.rs to add children, so they added the option to put a foo.rs beside foo/ instead of a mod.rs inside it.

Overall, they just decided that it was more consistent and had fewer weird edge cases if they required you to manually declare the structure using the mod keyword. Various Rust devs do stuff like "Type mod foo; then click the rust-analyzer/VSCode assist to create and open the referenced file".

Yeah, I heard that there is a new way and that the old way is mod.rs, but I still see the old way widely used when I look inside crates with VS Code.
Also this new way might be better than the old way, but I still don't like it. It is still confusing and awkward to have to put a filename with the same name as the folder and have it outside the folder. I want everything that relates to that folder to be inside that folder and not have a file outside.
Very awkward. This is a big fail for the Rust language, because so many other languages do this so much easier.

[Ironmask]

I find it incredible how easy it is to trigger Rust fans. I've never seen a language be held on an immaculate pedestal that to the extent that Rust is.

I'm not sure what world you're from, but I've only seen Rust users act pretty chill. It's when you mention Rust do other people come frothing at the mouth that people get angry for no reason. I've even trolled around a few times by blindly saying "they should rewrite it in Rust" and watched the thread explode into gore.
Oh yeah, not to mention that every post in favor of Rust just talks about it's features, and every post against it can largely be summed up as "look at these angry cultists using this new gimmick language I don't understand, see how many tantrums they throw? obviously nobody should use it" which is, embarrassing.

[ssokolow]

Yeah that all is pretty overwhelming and overly complicated to me. Other languages dont have that, it's so much easier in other languages.
Other languages just have namespaces, then you import that namespace, super easy.

Python has:

• import mod1.mod2, mod3
• from mod1 import ident1, ident2
• from mod1 import *
• from . import ident1
• from .. import ident1

For mod1 to be considered a package so you can import mod1.mod2, it must contain __init__.py. ...__init__.py may be empty, but it must exist. Also, if you're writing a compiled extension for Python in C/C++/Rust/etc., you cannot create submodules, so you must do import mod1 and then mod3 = mod1.mod2.mod3. They also have __main__.py which is what gets run when you python -m mod1.mod2.mod3, despite it seeming more consistent to just allow it to invoke __init__.py with the pre-existing if __name__ == '__main__': trick.

...and there are rules for when from . and from .. are allowed that'll trip you up, so they recommend not using them, despite them being only added around the time of Python 3.x IIRC.

If you want to import something from a path, such as to make a plugin system, you have to dig through the manual and figure out how to rebuild the relevant parts of the import system from component pieces because all the obvious stuff indirects through the global search path and doesn't take filesystem paths.

I'm sure there are other examples, but Python is my big area of prior expertise.

(eg. C will trip you up if you don't write include guards or use #pragma once and PHP requires you to know the difference between include, include_once, require, and require_once.)

Yeah, I heard that there is a new way and that the old way is mod.rs, but I still see the old way widely used when I look inside crates with VS Code.
Also this new way might be better than the old way, but I still don't like it. It is still confusing and awkward to have to put a filename with the same name as the folder and have it outside the folder. I want everything that relates to that folder to be inside that folder and not have a file outside.
Very awkward. This is a big fail for the Rust language, because so many other languages do this so much easier.

"Old" does not mean "deprecated". In fact, Clippy has lints to prefer/require/reject either. (mod_module_files and self_named_module_files)

[ssokolow]

Thanks to everyone who brought up Drew DeVault in the comments and talked about his new programming language (hare lang)that I had never heard of so I was curious to look it up and see what it was and after a while I saw that This is the same language that I made in my mind a long time ago!
This made me seriously consider it and migrate to it from Rust!

It always makes me happy to see people getting what they want without having to duplicate effort.

[jacob]

Yeah that all is pretty overwhelming and overly complicated to me. Other languages dont have that, it's so much easier in other languages.
Other languages just have namespaces, then you import that namespace, super easy.

Frankly I find that the module system is probably one of the worst parts of Rust. It's very confusing and complicated and yet, as you say, ultimately it's nothing more than namespaces. I wish Rust had generic modules like Ada or OCaml (but those languages it's still easier and more intuitive than what Rust does today).

[uid313]

Python has:

• import mod1.mod2, mod3
• from mod1 import ident1, ident2
• from mod1 import *
• from . import ident1
• from .. import ident1

For mod1 to be considered a package so you can import mod1.mod2, it must contain __init__.py. ...__init__.py may be empty, but it must exist. Also, if you're writing a compiled extension for Python in C/C++/Rust/etc., you cannot create submodules, so you must do import mod1 and then mod3 = mod1.mod2.mod3. They also have __main__.py which is what gets run when you python -m mod1.mod2.mod3, despite it seeming more consistent to just allow it to invoke __init__.py with the pre-existing if __name__ == '__main__': trick.

...and there are rules for when from . and from .. are allowed that'll trip you up, so they recommend not using them, despite them being only added around the time of Python 3.x IIRC.

If you want to import something from a path, such as to make a plugin system, you have to dig through the manual and figure out how to rebuild the relevant parts of the import system from component pieces because all the obvious stuff indirects through the global search path and doesn't take filesystem paths.

I'm sure there are other examples, but Python is my big area of prior expertise.

You're right, maybe Python is a bad comparision if I want to make a point that other languages are easier, the Python module system is pretty shitty too.

(eg. C will trip you up if you don't write include guards or use #pragma once and PHP requires you to know the difference between include, include_once, require, and require_once.)

Yeah, now that I think of it, PHP could be confusing too, because as you mentioned there those, so its a couple.
In modern PHP when you use namespaces and configured an autoloader it could be quite nice tho with just using a use statement, but yeah that's only as long as an autoloader is configured.

"Old" does not mean "deprecated". In fact, Clippy has lints to prefer/require/reject either. (mod_module_files and self_named_module_files)

Yeah, but if mod.rs is the old way, then I rather want to get away from it, and move to something easier and more modern, not be stuck in the past.

Frankly I find that the module system is probably one of the worst parts of Rust. It's very confusing and complicated and yet, as you say, ultimately it's nothing more than namespaces. I wish Rust had generic modules like Ada or OCaml (but those languages it's still easier and more intuitive than what Rust does today).

Yeah, overall I like Rust, there are so many great things about it, so many things they did right. Just the module system is a source of confusion for me.

[ssokolow]

Yeah, but if mod.rs is the old way, then I rather want to get away from it, and move to something easier and more modern, not be stuck in the past.

It's old in the sense that it's the first one they thought of. Shirking something purely because it's old takes you down the road to spending all your time buying As Seen on TV junk purely because it's new.

They're both equally valid ways to lay out a project with their own strengths and weaknesses.

[archkde]

I still find the module system tricky.
Other languages like in C#/.NET, Java or PHP you just use "using Foo.Bar.Baz;" (C#) or "use Foo\Bar\Baz;" (PHP) which is much easier.
In JavaScript you have to do "import { foo, bar, baz } from Baz" so its a little bit trickier, and it also has some other "import * from Baz" syntax so it is a bit trickier but still easier than Rust.
In PHP the modules are scoped relatively to the folders they are in, so its a bit trickier C#, Java and PHP but still easier than Rust.

Rust is the worst, you have two statements, both mod and use, not just one statement. It also has many variants such as use crate::foo, and I think use this::foo, or use base::foo, or something like that. Then you have to do weird things like if you have a folder named foo then you also need to put a file named foo.rs outside that folder that have to declare pub mod line for each file in the folder. It is just awkward.

Actually, using modules is not that different from the other languages you mentioned, except that "using" or "import" is called "use". "mod" is a bit awkward at first, but it has a number of advantages over a module structure solely determined by the filesystem layout (for example, modules can be defined inline or compiled conditionally).

Thanks, I didn't know about this.
I wish this was easier and worked out-of-the-box without having to install some third party Cargo plugin.
In the JavaScript world this is much easier with npm since npm already has an outdated command option without any third-party plugins.

Ah, I totally forgot about it being a third-party plugin, because cargo has such a great plugin integration

[uid313]

Actually, using modules is not that different from the other languages you mentioned, except that "using" or "import" is called "use". "mod" is a bit awkward at first, but it has a number of advantages over a module structure solely determined by the filesystem layout (for example, modules can be defined inline or compiled conditionally).



Ah, I totally forgot about it being a third-party plugin, because cargo has such a great plugin integration

I don't like inline-defined modules.

[Developer12]

Or you could port LLVM to these architectures, which might turn out to me be less effort and have more benefit in the end.

Linux supports more than just x86, arm, and RISC-V. There are quite literally dozens and dozens of architectures supported by linux and not LLVM. Many of them are old and not worth porting to LLVM at all, but are still required support by linux.

It's a fuck of a lot easier to port one frontend than to port dozens of backends. Especially when backends require intimate architectural knowledge.