this post was submitted on 28 Mar 2024
246 points (94.2% liked)
Rust
5999 readers
5 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I totally agree, though I think it's worth adding:
The advantages of static types is not just finding bugs (though it does do that quite well). It also massively helps with productivity because a) types are now documented, b) you can use code intelligence tools like renaming variables, go-to-definition, find-references, etc. (assuming you use a good editor/IDE).
In general stronger types are better but I do think there is a point at which the effort of getting the types right is too high to be worth the benefit. I would say Rust hasn't reached that point, but if you look at formal verification languages like Dafny, it's pretty clear that you wouldn't want to use that except in extreme circumstances. Similarly I think the ability to use an
any
ordynamic
escape hatch is quite useful, even if it should be used very sparingly.You are right. But I think similar secondary benefits also come from using the borrow checker. Rust developers, by necessity, try to avoid using circular references and prefer immutability where they can. Both of these are advantages because they tend to make for systems that are easier to understand and are easier to maintain.
Yeah I agree. The borrow checker definitely pushes you to write less buggy code.
Absolutely! Types are as much about providing the programmer with information as they are the compiler. A well typed and designed API conveys so much useful information. It's why it's mildly infuriating when I see functions that look like something from C where you'll see like:
rather than a better strongly typed version like:
I disagree with this, I don't think those are ever necessary assuming a powerful enough type system. Function arguments should always have a defined type, even if it's using dynamic dispatch. If you just want to not have to specify the type on a local,
let
bindings where you don't explicitly define the type are fine, but even in that case it still has a type, you're just letting the compiler derive it for you (and if it can't it will error).You can go to definition / find references / rename for dynamically typed languages too.
E.g. https://github.com/palantir/python-language-server
Without static type annotations you can only make best effort guesses that are sometimes right. Better than nothing but not remotely the same as actual static types. The LSP you linked works best when you use static type annotations.
Also I would really recommend Pylance over that if you can - it's much better but is also closed source unfortunately.
Why would it just be best effort? To find references for a specific thing, it still would parse an AST, find the current scope, see it's imported from some module, find other imports of the module, etc.
Where is the definition of x? What is the type of x? If you can't identify it, neither can the LSP.
This kind of thing actually happens when implementing interfaces, inheritance, etc. Thus, LSPs in dynamic languages are best effort both theoretically and in practice.
Tbf this example can be deducted as
string | int
just fine.The real problem is when you start using runtime reflection, like
getattr(obj, "x")
Types are not necessary at all.
Saying "x is defined somewhere in the entire program" isn't satisfactory to many users. Also, you didn't tell me what type x has. Can I do
x + 5
?It absolutely does. Without static types an IDE/LSP can't reliably find all the references / definition and therefore can't refactor reliably either.
Consider something like this:
Now imagine you want to rename
Foo.bar
or find all references to it. Impossible without the type annotations.Ah, I see. You're talking about object properties. I don't see any issue with finding references to variables, but for properties, yeah.
It breaks down when you do runtime reflection, like
getattr(obj, "x")
.Ok imagine you are a LSP. What type is
x
? Isprize
a typo? What auto-complete options would you return forx.
?I didn't say types. I said find references / go to definition / rename.
How are you going to find references to
prize
, go to its definition or rename it without knowing what typex
is? It's impossible without static types.