11–20 of 58 posts
As a sidenote, does anyone else find the language identification terms cringey? Rustacean, gopher, pythonista... just atrocious.
As a sidenote, does anyone else find the language identification terms cringey? Rustacean, gopher, pythonista... just atrocious.
Earlier quoted context omitted.
As someone who mostly writes Rust these days, I find it really nice that I can always (as long as I don't use wildcard imports) use intra-file search to find either the definition or the file that contains the definition. Whenever I have to touch Go code (for reading and debugging) it's really annoying to just end up going "okay, I've got the folder, now what". Or, even more annoyingly, I've just got an interface and…
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.
Working IDEs do, but Go's PLS doesn't, and that's part of the GP's complaints:
> Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.
As a sidenote, does anyone else find the language identification terms cringey? Rustacean, gopher, pythonista... just atrocious.
I wouldn't say that it is cringey, but I agree with the sentiment. It always seemed kind of weird that programmers would attach themselves and identify with a programming language tribe, even though they are very well capable of learning other languages and frequently do.
Earlier quoted context omitted.
`mod shard; use shard::*;` doesn't seem too bad IMO. Unlike Go, the compiler won't just parse all files in the source directory, but rather it'll build a tree of modules from the entry point and parse those.
Yes, but then you introduce new scope. If shard1::Foo depends on shard2::Foo, you then end up with a murder of import statements at the top of every file. Not to mention, splitting along the lines of inter-dependency does not necessarily correlate with splitting by readability/relevancy.
Wait, what? Import statements are recursive in Rust, if shard1::Foo depends on shard2::Foo, you just need to manually import shard1::Foo.
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…
// Only compile this code if the “foo” Cargo feature is enabled.
#[cfg(feature = "foo")]
pub mod foo;
// Platform-specific stuff, as with std::os.
pub mod os {
#[cfg(windows)]
pub mod windows;
#[cfg(unix)]
pub mod unix;
}
// You can even choose which file to load the module from.
#[cfg_attr(windows, path = "windows/mod.rs")]
#[cfg_attr(unix, path = "unix/mod.rs")]
#[cfg_attr(not(any(windows, unix)), path = "null/mod.rs")]
mod platform_impl;
As a sidenote, does anyone else find the language identification terms cringey? Rustacean, gopher, pythonista... just atrocious.
I wouldn't say that it is cringey, but I agree with the sentiment. It always seemed kind of weird that programmers would attach themselves and identify with a programming language tribe, even though they are very well capable of learning other languages and frequently do.
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.
> Dont most IDEs solve this. Working IDEs do, but Go's PLS doesn't, and that's part of the GP's complaints: > Of course, that wouldn't be so bad if pls was actually usable and helpful. But at the moment it would be hard to call it either of those things.
Sure its a bit sluggish in comparison (well only when indexing really), but finally i do not have to worry about not finding something or import-completion breaking every 2 weeks etc.
Just switch, you will stop thinking about your setup and just work instead.
Earlier quoted context omitted.
Yes, but then you introduce new scope. If shard1::Foo depends on shard2::Foo, you then end up with a murder of import statements at the top of every file. Not to mention, splitting along the lines of inter-dependency does not necessarily correlate with splitting by readability/relevancy.
> Yes, but then you introduce new scope. If shard1::Foo depends on shard2::Foo, you then end up with a murder of import statements at the top of every file. Wait, what? Import statements are recursive in Rust, if shard1::Foo depends on shard2::Foo , you just need to manually import shard1::Foo .
And with most imports in Rust being unqualified (that seems to be the idiomatic approach), I then find it difficult to differentiate types that are from a sibling, internal module from types that are important from external crates. Especially at site of use of the type.
Go's “local package names unqualified, everything else qualified” makes it much easier for me to read code without first having to parse all the import statements.
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…
As someone who mostly writes Rust these days, I find it really nice that I can always (as long as I don't use wildcard imports) use intra-file search to find either the definition or the file that contains the definition. Whenever I have to touch Go code (for reading and debugging) it's really annoying to just end up going "okay, I've got the folder, now what". Or, even more annoyingly, I've just got an interface and…
Depending on the case, this may have practical implications or not, but architecturally speaking, it's not good form.
A practical side effect is that having a lot of data structures is going to clutter the outline view in the IDE.