The feature list in rust really does have my eye. The biggest one in particular was type inference.
The reason type inference was such a big one was because if you use it right, annoying situations like "Two types of strings? What is this?" go the hell away. You have three types, static built in and binary strings, and a third that only makes the gaurentee that the datatype can do all the things a string aught to be able to do, and from there the compiler works out the practical implementations.
This article has done a great job in killing my enthusiasm for the language.
I guess it's implementation of type inference only goes as far as golangs, in that const keyword.
Maybe I was being a bit naive in what I was expecting, hell maybe what I'm expecting isn't reasonably possible. bleh.
Type inference doesn't exactly paper over the differences between types automatically. It just infers types, and doesn't complain as long as all the types line up.
Consider doing something similar in Haskell, setting a variable to either be a string or Text:
GHCi, version 7.4.1: http://www.haskell.org/ghc/ :? for help
Prelude> import qualified Data.Text as T
Prelude T> let x = (if True then "foo" else T.empty)
<interactive>:3:32:
Couldn't match expected type `[Char]' with actual type `T.Text'
In the expression: T.empty
In the expression: (if True then "foo" else T.empty)
In an equation for `x': x = (if True then "foo" else T.empty)
Sure, Haskell can sometimes auto-infer very complex types, and has more extensive type inference than Rust does. But it's not magic, and will not do everything for you.
What you're asking for is not type inference, but something else. Perhaps what you really want is weak typing (automatic type conversions), or message sending (can not statically dispatch).
Rust has type inference similar to Haskell: type information can flow "backwards". It is very different to Go and C++ where types of locals are 'inferred' from their initialiser, and nothing else.
E.g.
fn main() {
let mut v;
if true {
v = vec![];
v.push("foo");
}
}
is a valid Rust program: the compiler can infer that `v` must have type `Vec<&str>` based on how it is used. I don't think it's possible to syntactically write a Go program at all similar to this (a variable has to be either initialised or have a type), and the C++ equivalent (using `auto v;`) is rejected, as `auto` variables need an initialiser.
The C++ analogous, although not exactly the same, is to use a `make_vector` wrapper, like
template<typename...Args>
inline auto make_vector(Args&&...args) {
using T = typename std::common_type<Args...>::type;
return std::vector<T>{{std::forward<Args>(args)...}};
}
...
auto v = make_vector("asd", "dsa", std::string("asdsa"));
It will obviously not deduce types after the vector is declared, but it's as close as one gets to type deduction based on the vector's content.
There is one instance in C++ where information does flow backwards in a sense: disambiguating template overloads. For example,
using fn_type = std::vector<int>(&)(int&&,int&&,int&&);
auto v = static_cast<fn_type>(make_vector)(1, 2, 3);
In this case, the static_cast information flows "back" to the type deduction of `make_vector` to deduce what Args&& is. This is not very useful, just a curiosity.
Doesn't type inference stop at function boundaries, though? I'll grant you that idiomatic Haskell uses type annotations for function signatures (unlike idiomatic OCaml), but it is optional (which is convenient in a REPL).
The type inference does mean that you can care less about what specific type you’re working with, and that it is rare that you will need to write types out (except in signatures—the type inference is deliberately only local), but the distinctions are certainly still there, and due to the nature of the language must be.
Really, this is showing one of the more tricky parts of Rust, potentially to balance the claims of excessive bullishness for Rust that I have heard levelled at me! Don’t let it dim your enthusiasm too far; Rust is still very much worth while trying out in practice.
The reason type inference was such a big one was because if you use it right, annoying situations like "Two types of strings? What is this?" go the hell away. You have three types, static built in and binary strings, and a third that only makes the gaurentee that the datatype can do all the things a string aught to be able to do, and from there the compiler works out the practical implementations.
This article has done a great job in killing my enthusiasm for the language.
I guess it's implementation of type inference only goes as far as golangs, in that const keyword.
Maybe I was being a bit naive in what I was expecting, hell maybe what I'm expecting isn't reasonably possible. bleh.