I would like to know if I can use "use crate_name::*" without fear of increasing compilation time or if I should continue using selective import. General importation would make the code very clear, but changing the code clarity for a longer compilation time would not be good.
1 Like
Glob imports shouldn't have any significant impact on compile times, but they are not recommended because they make code less clear. It is very difficult to look something up when you don't know where it came from, and explicit imports are the way to communicate that. They also make it harder to update your dependencies if you accidentally cause an import conflict, because then you'll have to write them all out explicitly anyway to resolve it.
15 Likes
Yes, I understand that it is more communicative but what about when it comes to ffi? I have to do a lot of explicit imports and at the beginning it is quite large and it seems to me very messy. Take a look at this.
use vulkan::{VkQueueFamilyProperties, PTR_vkGetPhysicalDeviceQueueFamilyProperties, VkPhysicalDevice,
VkQueueFlags, VkQueueFlagBits_VK_QUEUE_GRAPHICS_BIT, VkQueueFlagBits_VK_QUEUE_COMPUTE_BIT,
VkQueueFlagBits_VK_QUEUE_TRANSFER_BIT, VkQueueFlagBits_VK_QUEUE_SPARSE_BINDING_BIT,
VkQueueFlagBits_VK_QUEUE_PROTECTED_BIT, PTR_vkGetPhysicalDeviceSurfaceSupportKHR,
VkBool32, VK_FALSE, VK_TRUE, VkInstance, VkDeviceQueueCreateInfo,
VkStructureType_VK_STRUCTURE_TYPE_DEVICE_QUEUE_CREATE_INFO};
1 Like
I haven't used this crate, but for imports I actually prefer something like:
use vulkan;
and then when I need something specific I do:
vulkan::VkQueueFamilyProperties
It's a little more verbose, but it tells you right at the point of use where the thing came from.
16 Likes
This is a very good solution, the names are already very verbose.
1 Like
Just remember you'll still have to bring any traits into scope individually.
3 Likes
It will have no impact on compile times because a use statement just brings a particular name into the current scope.
The basic compilation unit in C++ is the file, which means every time you want to use a header the compiler needs to re-parse and typecheck that header (and everything it includes).
On the other hand, the basic compilation unit in Rust is the crate so means every module in the entire crate gets parsed and typechecked at the same time.
13 Likes
You can also import as another name, such as use vulkan as vk if you want to save typing 4 letters: vk::VkQueueFamilyProperties
And it may be worth mentioning that crates sometimes put bulk imports into a prelude module:
use some_crate::prelude::*;
5 Likes
There's no noticeable performance impact. I have crates that do use somemodule::* with thousands of items, and it makes no difference.
From semantic point of view it's also not as bad as in C++. C++ has nested namespaces, and weird features like overloading combined with argument-dependent-lookup (ADL), which make name lookup complex and hard to follow.
In Rust use is limited to just module's scope, and it catches many cases when the imports are ambiguous.
You can use pedantic clippy to suggest replacing * with specific names you've used:
10 Likes
This strikes me as a problem for tooling. I would hope that most libraries use clear enough names that I can read the code and see function names that explain what they're doing without knowing where they're from. That is to say, knowing where something comes from should be the exception, and an IDE should provide that information. Mouseover tooltips, right-click -> show definition, whatever. Every language ecosystem I've used gives me something like that.
Plus it's entirely moot in the case of Vulkan, which is apparently prefixed with Vk everywhere anyway. 
use vulkan::* I say, and likewise any time you use more than a handful of items from a single-purpose crate (i.e. don't use std::*).
3 Likes
I don't use an IDE. I use VIM from a textmode console.
Because I use my module names as a prefix, I find my functions and types within modules can have much shorter names, eliminating a lot of redundancy where you essentially end up putting the module's name in the function or type name anyway.
9 Likes
We're deviating from the point now but... why? I use vim all the time for systems admin things, it's not like I'm not competent with it. But anything I'm putting this much thought into writing, no way. There are tools to make my life easier and I will leverage them.
(to say nothing of vim's extensibility to near-IDE levels of functionality, but I don't know how mature the rust options are at this point)
1 Like
I don't use an IDE either, and the answer is simple: it does NOT make my life easier. It just makes things different. Most of the things an IDE does for you are things that you can learn to do very quickly without it. And if you learn that stuff, choosing, configuring, updating IDEs are just needless overhead.
4 Likes
Call me old fashioned but I am happier if source code is comprehensible without syntax highlighting and all the crutches offered by IDEs. I regard the need for such things to make any progress a failure of the language design.
4 Likes
I digress, you digress, we all digress. 
I, too, have been burnt by trash IDEs that required an advanced understanding of the toolchain just to get going. 100% not my experience with Rust. Installed rustup, VS Code, the Rust extension, it gave me a one-click prompt to install RLS. Took me like ten minutes and it gives such a rich live feed of information as I'm coding that I'm pretty sure I was printing animated ASCII art to the terminal well before I ever saw my first actual compiler error.
And it tells me what all these functions and types and things are without manually grepping use lines and wandering off to find the relevant source files or doco (to tie back to the topic... almost...)
Black and white photos are comprehensible, but they still lack information that you could otherwise have. Coding without highlighting is like playing Where's Wally in black and white - doable, but it's much easier and faster with colour. Our eyes can bring in many channels of information, I leverage that the same as I leverage having both of my hands to type with. I am blessed with a wide biological IO bus, heck if I'm not going to use it.
To each their own.
6 Likes
I agree with that but at the same time more often than not I do not have the luxury of having extra information an IDE could offer. Professionally I find myself mostly staring at PRs, historical commits/diffs/patches, docs.rs/github source code -- the best I can get is syntax colour highlighting but there's no type annotation and other useful hints. Because of this we need to be able to write code that is understandable in all circumstances and think about the "black and white" case.
On a personal note, I find reading Rust PR way more difficult than C++. It might be my lack of experience but when I see a long sequence of map/ok/unwrap/filter/into/nested lambdas and all sprinkled with question marks, I feel I have to spend too much time deciphering what is going on.
Of course when I write such code in the IDE, it's much easier to comprehend it, being able to see types. And not least because I wrote it so I know what's happening.
5 Likes
What about writing that vertically and (auto) sort those imports?
I think an IDE can do a pretty job here, though I'm not that familiar with Rust IDE's:
- auto import over rightclick/key shortcut, optional selecting the item out of multiples
- auto sort imports
In Java + Intellij you don't have to think about these kinds of problems.
1 Like
This. I also use Vim, and I like the syntax highlighting and the built-in, somewhat naïve, code completion feature. I don't spend the lion's share of my time power-typing; I spend most of my time thiking about design, verifying correctness, and reading the documentation.
I don't want any IDE to eat 69 GB of my SSD, when I can have a good editor in 4.5 MB:
H2CO3@H2CO3-macbook:~
[git:master 1* 5?] 18:52:54 $ wc -c $(which vim)
4548272 /usr/bin/vim
1 Like
I use Jetbrains IDEA and don't eat that much storage, the jvm consumes a good amount of memory and CPU but it's nothing extraordinary
Well, back in the days of 8 bit computers one could edit and compile C code in 64K bytes. Which was the high end of what such machines had at the time.
As such I would say the gigabytes required to build a Rust program, even before we consider IDE's is extraordinary.
Anyway, I did not mean to say that syntax highlighting and other IDE luxuries are not useful. Only that a programming language should be intelligible, as text, without such aids.
1 Like