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.

[ubuntulove74]

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!

[arQon]

I find it incredible how easy it is to trigger Rust fans.

No kidding. But wait til you see the next article about some tiny piece of GNOME. :P

> I've never seen a language be held on an immaculate pedestal that to the extent that Rust is.

You must be new. Welcome.
We did this in another thread just recently. Off the top of my head, for recent-ish ones only: Java, Ruby, C#/Mono/.NET, Dart, Go, and I'm sure I missed a few.

[arQon]

There has been a plethora of analyses of why Rust is a poor imitation of C++, my favourite one is from Drew DeVault

Thanks. That's certainly my favortie one now too, but for other reasons.

I mentioned just yesterday that the constant dishonesty of Rust advocates was hurting acceptance of the language as much as the idiot fanboys. DeVault, by being uniformly honest there, and insightful on some points, *but wrong* on others, has unquestionably done more to convince me to give it a chance than all the mouth-frothing and toy project rewrites combined. :P

[mdedetrich]

This post has a kernel programming context because inclusion of Rust into GCC is motivated politically -- as a requirement to allow Rust in Linux kernel. There is no other reason.

As for safe/unsafe code in kernels -- your point has architectural sense only if the whole of the kernel is written in Rust. Linux kernel is not and thinking that it is going to be fully rewritten in Rust is delusional.

You should lay off the conspiracy theory kool aid

[ssokolow]

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.

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.

Rust is the worst, you have two statements, both mod and use, not just one statement.

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.

It also has many variants such as use crate::foo, and I think use this::foo, or use base::foo, or something like that.

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};

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.

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

[uid313]

What do you mean with rustfmt has no options?

https://rust-lang.github.io/rustfmt

btw the idea of having a uniform code style across a whole language is asinine at best.
Of course projects should have uniform styles, but enforcing 1 true style for some alleged ecosystem benefit makes no sense to me.
If only because if I can't bring myself to like this one true style I'll just avoid using this formatter, defeating its purpose.
eg: I can't work with 2 space indentation. If indentation size can't be configured (dartfmt sucks) I'll avoid the formatter and won't allow it near any code I'm managing...

My bad, rustfmt actually does have options, I wasn't even aware of that.
I still like though that Rust comes with cargo which comes with rustfmt and that you can run rustfmt without any configuration and it will still work, it is dead easy.
Many other languages don't come with a formatter, and then people use none, or bunch of different ones with a bunch of different options and there is no standard on consensus, it is just the wild west. With Rust pretty much everyone uses rustfmt and most people do so with the default options.
If a few people really feel they want to use their own formatting options, I guess they can do so.

Personally, I prefer 4 space indention, but I can whatever the community does, I prefer there is a style guide that I can follow and a formatter then I can use even if I might personally disagree with some choices, because then its still better if things are consistent. Especially if the whole community can put their egos aside and agree to use something.

Huh. I didn't realize I was imagining the effects of putting use_small_heuristics = "Max" in rustfmt.toml to optimize for reading my code on non-portrait-oriented monitors.

My bad, I guess it is possible to configure rustfmt, still I really like that Rust comes with cargo which comes with rustfmt and that it works even without a configuration.

If it helps, you can think of mod as mount and use as ln -s.

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.

They're working on the async functions in traits thing but, given the constraints of the stability promise, they have to get it right the first time if they put it into the compiler itself, so you may want to subscribe to updates on the stabilization of GATs as the basis for doing it.

Yeah, I really look forward to this.

For checking for package updates, the number-one third-party Cargo plugin is cargo-outdated, there's a built-in cargo update for updating Cargo.lock in a non-semver-breaking way, and cargo-edit (from which cargo add recently got merged into mainline Cargo) provides cargo upgrade for semver-breaking updates to Cargo.toml.

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.

Interesting, could you elaborate more? I find the module system completely intuitive, but that might also be due to already having learned about its warts from OCaml.

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.

cargo upgrade --dry-run

Upgrade isn't part of Cargo. I just found out it is a third-party Cargo plugin. I wish it was part of core Cargo and worked out-of-the-box without any plugins like npm does in the JavaScript world.

Yeah, it is, just like the C++ compilen. Fortunately, there is "cargo check" which you can use to check your code for errors, it basically tells the compiler to stop right before the (slow) code generation.

Thanks I wasn't aware of this. It is still slow to compile the whole program which I need to do test things.

I usually just use "cargo update" for minor and patch upgrades, and deps.rs for majors and CVE issues. Works fine.

Oh this deps.rs only works on hosted stuff, not on local stuff on the machine.

[Ironmask]

A more rational approach would be making operator overloading explicit. For example, "abc == xyz" for variables of the exact same type, and "abc $== xyz" if they are different types.

Not great but I'd accept that compromise.

An even better solution would be to just let anything be an operator, like OCaml/F#. Every function can already do anything, why not just let any arbitrary set of non-alphanumeric characters do anything as well? I see that get used a great deal in ML family languages for really clever syntax.

An even better talking point is to just look at how operator overloading is seen in the wild and see that it... is not a problem in the first place. Look at C#'s community, they have operator overloading, and their community is very organized and follows a lot of good practices. Look up any StackOverflow article about operator overloading in C# and they will very sternly say you should make the operator do only what you expect and to do it cleanly and quickly. It's outright not an issue, it makes everything smoother.

There are two different ways to distrust a programmer. The first way is to agree with the programmer's distrust of themselves, like a borrow checker. You can override/bypass it if you absolutely understand what you're doing, but it's largely there to remind you that you yourself may not fully know what you're doing, and should try to see things from it's perspective. Garbage Collection is similar, you can't shut it off, but, everything would break if you could anyway.
The second way to distrust a programmer is to tell them right out of the gate they're stupid, they will always be stupid, and they will never be smart until they believe the things the creator of the language/library believes. This is where being against operator overloading comes in. It's not dangerous to you, the creator just doesn't trust you and thinks you're just too stupid to override operators properly, and then totally ignores the issue by just making you type a function name instead of an operator anyway. This is not how the real world works, programmers are not useless morons who need to be kept on a leash by their tools, they need to use good tools that inform them of how to make good decisions, which can only happen with a strong community built around those tools. A programming language is still a language, it's made by people for people to communicate with each other. The fact that that a programming language can turn into a program is just a happy side-effect. Trying to mechanically limit them in pointless ways just causes ugly artifacts to appear, like putting ".equals()" or ".is_greater()" everywhere. It doesn't look good, it doesn't flow syntactically, it's cumbersome and irritating to both read and write. A far cry from what languages like OCaml do with their composition operators. I always assumed this is why Zig users always seemed so obnoxious, Zig doesn't really innovate anything, it's just a new way to try to tell people what to do in their own time.

I get really passionate about operator overloading.

[billyswong]

... But actually as a side tangent, That's actually a reason I, personally, do not like Zig, because it deliberately doesn't allow operator overloading, because "it's hidden side-effects". Functions are hidden side-effects. Let me write in a language, not in code. I need shortcuts, I need to be able to write code that looks like English, not like spaghetti they use as stock photos for news articles about hackers. I equally hate this about Java and JavaScript and having to write ".equals(...)" everywhere is ugly and infuriating where there's a perfectly serviceable and largely unused "==" operator right there, and it's not like ".equals()" is any more predictable about what's under the hood of that method than an operator. It makes zero sense. But that's just me, obviously people like Zig and I don't have a problem with that.

A more rational approach would be making operator overloading explicit. For example, "abc == xyz" for variables of the exact same type, and "abc $== xyz" if they are different types.

[Ironmask]

I don't understand this argument at all.

I like Rust because I don't have to deal with confusing crashes because I, in my human fallibility, forgot a number or pointer or some other tiny syntactic or mathematical error I made because I was tired from living the rest of my life.
I like other languages, I like C#, OCaml, Erlang, I put up with Lua and Python. I'm not being a zealot about it, Rust has genuinely improved my life and made me more productive and improved my skills quite a bit. It doesn't hide anything from me, it's just a bunch of shortcuts to make efficient but low-level programs.

If wanting a better life makes me a blind zealot then I guess maybe I'm just gaslighting myself.
Like I know people find language arguments silly (they're not, languages are real-world issues that cause real-world problems) but getting mad at Rust solely because it's popular is beyond infantile. You gain absolutely nothing. Nothing. Not a single thing about your life or the world improves. Nothing. You are slowly dying this very moment reading this. I decided to sacrifice some of that time as an appeal to human dignity, rather than telling people the thing they like is actually a thing they should not like, if only they weren't lying to themselves through malicious stupidity. Every moment you get mad at something for being popular and decide to crusade against it, you're electing to kill yourself.

... But actually as a side tangent, That's actually a reason I, personally, do not like Zig, because it deliberately doesn't allow operator overloading, because "it's hidden side-effects". Functions are hidden side-effects. Let me write in a language, not in code. I need shortcuts, I need to be able to write code that looks like English, not like spaghetti they use as stock photos for news articles about hackers. I equally hate this about Java and JavaScript and having to write ".equals(...)" everywhere is ugly and infuriating where there's a perfectly serviceable and largely unused "==" operator right there, and it's not like ".equals()" is any more predictable about what's under the hood of that method than an operator. It makes zero sense. But that's just me, obviously people like Zig and I don't have a problem with that.