3 ms·

> I hear you. A lot of this is based on opinion; you find the duplication good, I find it near-unbearable. :) I don't really find it good. I just don't see any

> I hear you. A lot of this is based on opinion; you find the duplication good, I find it near-unbearable. :) I don't really find it good. I just don't see any easier to follow alternatives. Imagine getting a contract to add a new feature to C code written for an old mainframe in the 80s. It's a pain, right? Now imagine you just deleted half of the type annotations and replacing them with let. Do you think that would be easier to read? Maybe a better middle ground is left-justified definitions of types? I don't know. I think that vec<int> something = new; might be better than let something = new vec<int>; We read left to right, the first thing on the line is the left most item, and the left side of the variable definition with always be visible (can't have a function call on the left hand side). > If the compiler can figure it out, then so can any other tool I understand that but most IDEs, outside of the ones supporting the new language server initiative, don't really talk to the runtime/compiler. It's also the case that architecturing your compiler/IDE this way is very computationally expensive. I'm on an x220 which is only a few years old and RLS locks up every time I try to load a non-trivial project. > I do think that IDEs are a way to split the difference here; you can hover over people or plusOnes and see the type. It would help but I have not had any luck getting a decent IDE setup for Rust. I know this is something that I am not alone on and (thankfully) this is a criticism the Rust community is very receptive to. I'd be really interested in hearing what you and many of the other core devs do for your environments.

barrkel 9y ago
> vec<int> something = new; > might be better than > let something = new vec<int>; I don't think this is right at all. The name of the variable is far more important than its type - ideally, the name of the variable should include a hint as to the nature of its type, whether it's explicit (e.g. parent and child in a tree navigation function are obviously references to the tree node type that is being navigated over) or very lightly suggested (e.g. pluralization, like children for a list of child things). The actual type is of secondary importance, chosen for implementation reasons (e.g. a map might be hash-based or tree-based, or a list might be a view over some other list, synthesized from some foreign collection, or a wrapper around an array in memory). For me, the name of the variable is of paramount importance for understanding the code. The type is very secondary. Types are usually in two buckets: domain-specific (so the name typically is highly relevant to what's being done and is often the same as the type name or an abbreviation or agglutination), or common denominator library types (typically collections, strings, primitives, that kind of thing) where the name of the variable implies the type. The name is the thing that you see over and over again in the code. You also don't get to see the type when you call a method. So readable code needs good consistent names that make type annotations helpful but far from mandatory for comprehension.
steveklabnik 9y ago
I use VS: Code with the RLS and the plugin we provide for it, that's it. I also sometimes use vim with syntax highlighting, but no RLS or anything fancy. > RLS locks up every time I try to load a non-trivial project. I wonder if this is the initial build; that is, right now, RLS basically needs to build your code in order to do its thing, so the first time you open stuff, it's gonna be slow and make your fans whir. After that it shouldn't be a huge deal. Things have been a bit wonky as of late, but the RLS is now riding the trains at least, so being available on stable will be very nice.

barrkel 9y ago

> vec<int> something = new; > might be better than > let something = new vec<int>; I don't think this is right at all. The name of the variable is far more important than its type - ideally, the name of the variable should include a hint as to the nature of its type, whether it's explicit (e.g. parent and child in a tree navigation function are obviously references to the tree node type that is being navigated over) or very lightly suggested (e.g. pluralization, like children for a list of child things). The actual type is of secondary importance, chosen for implementation reasons (e.g. a map might be hash-based or tree-based, or a list might be a view over some other list, synthesized from some foreign collection, or a wrapper around an array in memory). For me, the name of the variable is of paramount importance for understanding the code. The type is very secondary. Types are usually in two buckets: domain-specific (so the name typically is highly relevant to what's being done and is often the same as the type name or an abbreviation or agglutination), or common denominator library types (typically collections, strings, primitives, that kind of thing) where the name of the variable implies the type. The name is the thing that you see over and over again in the code. You also don't get to see the type when you call a method. So readable code needs good consistent names that make type annotations helpful but far from mandatory for comprehension.

steveklabnik 9y ago

I use VS: Code with the RLS and the plugin we provide for it, that's it. I also sometimes use vim with syntax highlighting, but no RLS or anything fancy. > RLS locks up every time I try to load a non-trivial project. I wonder if this is the initial build; that is, right now, RLS basically needs to build your code in order to do its thing, so the first time you open stuff, it's gonna be slow and make your fans whir. After that it shouldn't be a huge deal. Things have been a bit wonky as of late, but the RLS is now riding the trains at least, so being available on stable will be very nice.