4 ms·
I've been working with rust for about a week now and I've found it a mirror of go in several ways. Go aims to be simple with the aim of being 'easy' to start w
by Everlag 11y ago
I've been working with rust for about a week now and I've found it a mirror of go in several ways.
Go aims to be simple with the aim of being 'easy' to start writing idiomatically within a few days of jumping into the language. Comparatively, rust is a behemoth in terms of complexity.
There's the completely relevant compilation speed difference: if rust could compile within 5-10x the time go does, it would be much more pleasant to work with. Being able to compile within 2 seconds on large projects is crazy for iteration speed; having to wait upwards of 10 seconds on toy projects is not.
However, rust is stupid fast while also being safer than go. Also, generics; that's a flamewar for another day.
Context: I've been working with go for around 2-3 years now. I recently decided to pick up rust because of the guarantees it provides along with the crazy performance.
- kibwen 11y agoYou'll be happy to hear that compilation speed is the foremost priority of the Rust developers at the moment, and is the result of a technical-debt-laden codebase (having survived four years of traumatic language evolution) rather than any intrinsic property of the language. :) Huge improvements are in the pipe.
- Everlag 11y agoFantastic to hear! I don't even want to think about the horrors that 4 years of heavy core changes would do to a language.
- kibwen 11y agoThe bottom line is that self-hosting is a great way to shake down your language on a large-ish codebase and a fine way of encouraging outsider contributions, but should really only be done once you actually have a relatively solid idea of what your language is going to be. :)
- IshKebab 11y agoDo you have any evidence that it isn't an intrinsic property of the language? I would have thought all that type inference is non-trivial to calculate.
- Manishearth 11y agoThe slowest part is the LLVM passes. typecheck isn't very fast either, but it can be parallelized and it's much faster than the LLVM part. We don't really do any optimizations on the Rust side and just hand over IR to LLVM. This IR isn't of the type LLVM was built to deal with (pervasive noalias, lots of iterators, etc). It can optimize it, just that it's slow. We can work on giving better IR there. So type check is slow, but it isn't the reason we're slow. (Still, improvements to type check will help)
- kibwen 11y agoYou don't even need to trust me, use the compiler's own "time-passes" flag to see a breakdown of where the compiler spends its time on any code you wish to feed it.
- grayrest 11y ago> if rust could compile within 5-10x the time go does, it would be much more pleasant to work with As someone who's been around Rust for a long time but writes very little code in the language, I'm looking towards the MIR work and language services effort to improve this. The language is reasonable to work with once you're over the learning curve and you can mentally visualize the allocations/pointers/borrows moving around but the learning curve is really hard. Having a faster feedback loop on a higher information density interface than console text (I have a dream of dynamic borrow/lifetime overlays) to act as an extended tutorial would go a very long way.
- kibwen 11y agoFor those playing along at home, the "MIR" referenced here is the effort to entirely overhaul the compiler middle-end to enable more reliable code transformations and trickier analysis passes, as well as laying the groundwork for goodies like incremental compilation (https://github.com/rust-lang/rfcs/pull/1298 https://github.com/rust-lang/rfcs/pull/1298).
- steveklabnik 11y agoTo elaborate on the 'tricky' here, it's not even that we want to add more _complex_ passes, exactly. It's that many of the current passes are tricky to implement when you operate on an AST, and so we'll be able to make them more solid, eliminating bugs in the process. There is one pass that is certainly "more tricky" from an algorithms perspective, but will result in the rules being more intuitive from a user's perspective.
- CyberDildonics 11y ago> (I have a dream of dynamic borrow/lifetime overlays) This is really what needs to happen for wide Rust uptake. If you look at IRC most people starting with Rust immediately run into compile problems that they don't know how to solve. I did and I write C++11 with rval references all day every day.
- MichaelGG 11y agoRust'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.
- IshKebab 11y agoI 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).
- Chattered 11y agoNot 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.
- MichaelGG 11y agoYou 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.
- markus2012 11y agoWhat helps today is skipping the translation phase (syntax checking only) using rustc -Z no-trans. This makes the edit/fix syntax cycle 20x faster. A way to configure this in vim: https://www.reddit.com/r/rust/comments/3kc6s7/fastest_editcompile_cycle_in_vim/ https://www.reddit.com/r/rust/comments/3kc6s7/fastest_editco...
- igouy 11y ago>>having to wait upwards of 10 seconds on toy projects<< meteor-contest Rust #2, 545 lines of code, 4.75s to build http://benchmarksgame.alioth.debian.org/u64q/program.php?test=meteor&lang=rust#log http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... I do see what you mean.
- kibwen 11y agoGrossly misleading. You're measuring the build time of an optimized build, which is not what developers are building during routine development. Optimized builds deliberately trade compilation speed for superior performance.