Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Rust's complexity is pretty much directly related to the problem it solves (no GC, memory safe, high perf). And even then it's sorta straightforward given those constraints.

I'd bet that if they fixed up type inference to work everywhere (like Haskell or even like an ML) that'd reduce the perceived complexity as beginners wouldn't need to figure out type annotations by hand all the time.



I don't think that would help very much. You still need to know the types, even with type inference. Type inference just helps avoid excessive typing (of the keyboard kind).


Not generally true. I'd have given up on Haskell yonks ago if that's all type inference was good for. In many cases, I just can't figure out the types of arguments without stopping completely and thinking really hard, and I usually can't be bothered to do that when I have a compiler that's happy to do it for me. Haskell gets bonus points for allowing me to insert holes arbitrarily in my code and ask the type-inferencer "what sort of thing do I need to put there?" Inference of the types of function arguments is a special case of that.

It might not be such a big-deal in Rust. I don't have enough experience with it. But if it ever gets HKTs, it wouldn't surprise me if their interaction with typeclasses becomes a pain-point without (nearly) global type inference.


You don't need to know the type. If you take a parameter, then pass it to another function, you don't need to know how that function specified it (if it was a mutable borrow, or full ownership or whatever). It'd just flow through. Or when using an argument and unsure which constraints I need, it'll fill those in for me.

I write some in F# and I never specify types unless there's an obvious clarity issue or a type inference limitation. Most of the time that's because type inference in F# flows only one way and the whole .NET instance methods don't offer alternative syntax (i.e., you must write x.Foo, and you can't do that without knowing x's type - it won't get inferred).

When I don't know the type, then I ask the IDE or REPL what it is. Problem solved; everyone happy.

This is more of a problem when writing short functions (it increases the overhead both timewise and resulting noise) or when dealing with complicated types. I've dealt with types requiring 300+ character annotations. That's no fun. Or particularly when there are certain traits or other constraints that you haven't fully worked out. Making you figure them out on paper and write them down doesn't benefit anyone - they're required for a real reason and the compiler will always check and let you know.


> I'd bet that if they fixed up type inference to work everywhere

You mean on function parameters and stuff? Never going to happen, and most of us would not count that as a "fix". If anything that makes programs harder to read, since tracking a type becomes much, much harder.


I know the Rust team is ideologically opposed to it. It would ease the barrier to entry, as well as making Rust more amenable to shorter programs. It also provides more of an elegance, making items no different than expression bindings. Most importantly, it doesn't oppose the opinion that humans should do a computer's work. After all, Rust could always provide a mode to infer then write the type annotation out. Hopefully an IDE will do this.


Explicit function signatures are a feature that favors correctness over ergonomics. This isn't the first place that Rust makes this tradeoff: immutability itself is entirely useless in Rust except as a means to to aid programmer correctness (to wit: as a result of tracking ownership, Rust could trivially infer immutability based on usage patterns, but when the devs hinted at the idea of removing immutability the community rallied in opposition (the legendary "mutpocalypse")).

Furthermore, the forthcoming work on incremental recompilation intends to leverage the fact that function signatures are infallible in order to enable drastically improved incrementalism (no need to even consider recompiling code that calls a function if only the body of the called function changes), and the same fact will be leveraged to enable huge parallelism in incrementally compiled units.

Furtherfurthermore, Rust deliberately doesn't employ Hindley-Milner and so I'm not even 100% certain that whole-program type inference is feasible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: