Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust from a Gopher – Lessons 7, 8 and 9

levpaul.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Rust from a Gopher – Lessons 7, 8 and 9

#51

Post by ReactiveJelly »

pornel wrote: post #43
pizza234 wrote: post #3

What's the rationale for making files modules? Modules being namespaces, and namespaces being collections, it's not desirable to have a file being a (large) collection of code. The feature that gives mixed feelings to the author (Re-exporting Imports) is indeed a workaround to this; since each file would externally generate one extra namespacing level, one reexports data structures in order to remove that level. This…

Files aren't modules. Modules are defined in the source code the same way as any named "item" in the language, like structs and functions. The only difference is that content of `{}` following the definition of a module can be read from another file. You can have a module without a file: mod foo { fn function_in_foo() {} mod bar { // this is crate::foo::bar module! } } but if you omit {}: mod foo; Rust will look for…

That's not how I understand it.

Every file is a module, but not every module is a file.

If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?

Re: Rust from a Gopher – Lessons 7, 8 and 9

#52

Post by ReactiveJelly »

golergka wrote: post #39
st1x7 wrote: post #17

Earlier quoted context omitted.

The terms also emerge for certain languages with a specific type of community around them. For example, I don't know if C++ developers really care enough to give themselves these kinds of labels.

Most don't love the language that much. I'm not implying that it's a bad language though. Like Java, it's a very widely used language in enterprise and industry, and I think that most of the programmers in those languages view programming as just a 9-to-5, white collar job that puts food on the table. Nothing wrong with this view either, but it's not the kind of environment that would create memes or inside jokes. Ru…

That makes sense.

My enthusiasm for Rust is _because_ it lets me escape from C++. It's probably the same for Python and Go users.

Re: Rust from a Gopher – Lessons 7, 8 and 9

#53

Post by kd5bjo »

ReactiveJelly wrote: post #51
pornel wrote: post #43

Earlier quoted context omitted.

Files aren't modules. Modules are defined in the source code the same way as any named "item" in the language, like structs and functions. The only difference is that content of `{}` following the definition of a module can be read from another file. You can have a module without a file: mod foo { fn function_in_foo() {} mod bar { // this is crate::foo::bar module! } } but if you omit {}: mod foo; Rust will look for…

That's not how I understand it. Every file is a module, but not every module is a file. If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?

> If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?

There’s also the `include!` macro which can read a source file without making it a module and the `#[path=...]` directive which can let you use the same source file for several modules.

Re: Rust from a Gopher – Lessons 7, 8 and 9

#56

Post by st1x7 »

okareaman wrote: post #55
st1x7 wrote: post #2

As a sidenote, does anyone else find the language identification terms cringey? Rustacean, gopher, pythonista... just atrocious.

What do you propose as an alternative? "I am an aficionado of _____?"

> aficionado

Just as I thought that it couldn't get worse.

The alternative is to say that you're a developer in a given language or a user of the language. You don't have to create a whole tribe around it.

Re: Rust from a Gopher – Lessons 7, 8 and 9

#57

Post by pcein »

ReactiveJelly wrote: post #50
LandR wrote: post #10

Earlier quoted context omitted.

Dont most IDEs solve this. I do C# for my day job, if I have an interface I put cursor on it and hit a key and go to the definition, whatever file it's in. Another key will cycle the usages of the interface. This has been solved for years. More recently we've had things like Peek as well.

But if you have to rely on an IDE, it's hard to innovate in language design. Rust does have rust-analyzer, but it uses piles of RAM and often just doesn't work. I'll periodically try it for a few days and give up on it again. Maybe it's a bug in Kate's LSP support.

I have been using rust-analyzer with vscode (on small programs) and it has been working reliably for me.

Re: Rust from a Gopher – Lessons 7, 8 and 9

#58

Post by pornel »

ReactiveJelly wrote: post #51
pornel wrote: post #43

Earlier quoted context omitted.

Files aren't modules. Modules are defined in the source code the same way as any named "item" in the language, like structs and functions. The only difference is that content of `{}` following the definition of a module can be read from another file. You can have a module without a file: mod foo { fn function_in_foo() {} mod bar { // this is crate::foo::bar module! } } but if you omit {}: mod foo; Rust will look for…

That's not how I understand it. Every file is a module, but not every module is a file. If `mod foo;` is the only way to make sure a file's code gets compiled, then at some point every file gets its own module, right?

If you want to, you can easily make a project comprised of many modules and using only one file (or zero files)

Creating a single module from many files is also possible. It can be done with clumsy C-style includes, or more idiomatically composed from `pub use` of items from private modules. `impl` blocks can be anywhere.

The point is, files and modules are decoupled. Files just happen to be a convenient default for modules, but they aren't semantically special in Rust. There's no syntax or privacy boundary specific to files.

) Cargo.toml with `[lib] path = "/dev/stdin"` + `echo 'fn main() {}' | cargo build` happens to work :)

Post reply on HN