>But, one thing worries me -- performance. Anyone know a list or tracker of benchmarks to see how it roughly compares.
Or is it too ealry too talk about it? Am I pointing to the elephant in the room?
I'd say it's too early.
First, Rust is a compiled, statically typed languaged using LLVM, including stuff such as non aliasing guarantess over C, and designed to be secure AND fast. It's not like it's some scripting language.
Second, you should benchmark your program first. Worrying about a language's "performance" in abstract is more premature than even Knuth anticipated.
A fast language runtime helps all programs. If it's slow, there's precious little you can do about it. And the design of the language may end up such that certain aspects are just always going to be slow. So, I very much disagree with the notion that this a premature optimization (and I'm starting to think that phrase needs to just go away). You seem to allude to as much by delineating between compiled and scripting languages.
You can run Rust completely without a runtime. Part of the reason for that is that there are much bigger performance hawks than you or me monitoring Rust who have significant input on its implementation. That is one of the reasons that Rust moved GC into a library, for example. The last thing I am worried about with Rust is its performance.
That doesn't say much about performance. Languages that do need a runtime, like Java, aren't slower than C++ because of the virtual machine per se (which otherwise does a good job at doing awesome optimizations that are only possible with runtime profiling), but rather the reliance on a garbage collector and the lack of options for fine tuning the memory layout / access patterns and unfortunately the runtime is not smart enough yet to do that for you. Every language that depends on a GC, but that wants to be close to C/C++ in performance, starts with this handicap, even though for most purposes an efficient garbage collector will behave much better than inefficient usage of malloc or a half-assed object pool.
Of course I wouldn't worry about Rust's performance either.
Awesome. Rust's performance is something that impresses me, so I'm certainly not suggesting that it's slow. The point I was making is it's a valid question to ask and a valid thing to measure. Having fought with slow language features (e.g., blocks in Ruby), slow stdlib (e.g., older versions of Scala's collections), and slow techniques adopted by library authors (e.g., ask for forgiveness with exceptions instead of permission) there's just a lot that impacts many if not all apps and if it's outside your own application code, it can be very hard to fix. One of the things I really like about go releases is they indicate exactly what's changed on the performance front, so I have a good idea of what to expect. And since they measure it, they can improve it.
Sure. I think that until they hit 1.0, the Rust devs want to concentrate on getting the language semantics right. The most important thing is that Rust CAN be made fast even if it is not fast today (but I'm not suggesting that it's not fast but it probably has room for improvement). You can't make e.g. Ruby fast while maintaining backwards compatibility.
Piggy-backing on premature optimization: Yes, 100% agreed. Totally needs to go away. I encounter it most used as a crutch for otherwise skilled programmers to ignore any analysis what-so-ever in any area of software development.
IME they produce late, over-budget, fragile systems because they're averse to thoughtful consideration of the problem at hand and end up rewriting the same thing three times over.
I'm generally not a fan of the term "Software Engineer", but I think attempting to earn the label is worthwhile at least. The "burn someone else's money" mind-set is at the opposite end of the spectrum though. I can't imagine any other field where the "customer" (the person cutting the cheques) would find that acceptable.
> Oh sure, I told you up-front I had two kids and my mother-in-law visits frequently so I want a 4 bedroom house, but you built a 3 bedroom one instead. But that's fine, just go ahead and tear that down and start over. I don't mind paying for both. Maybe by the fourth iteration you'll include a kitchen and bathrooms!
> Then on iteration 5 maybe the bathrooms will even have toilets in them. And don't worry about building codes. We'll just rebuild the house after the under-gauged wiring burns it down. Also, after the sewer gases fill the house we can always break up the foundation and redo the plumbing to add P-traps later.
> It's not like any of this is stuff that you could know up-front. That's why I pay you. The professional. With the "get-to-it" attitude to dive in blindly and show me just how fraught with mistakes this whole thing can be. And you're right, how do I really know I'll want a kitchen up-front? Maybe we'll just eat out every night after moving in. Previous evidence to the contrary not withstanding.
Er... went a little off-tangent. Just needed to get that off my chest I guess. ;-)
Agreed -- I've found these pearls of received wisdom often crumble on non-trivial projects. "Premature optimization" can lead some to defer thinking about performance at all. "Profile and fix the hotspots" without simultaneously thinking about architecture can yield a mass of uniformly slow branchy code with no path forward. It's hard to appreciate until you've been there. However, I do have faith that mozilla folks have most certainly been there and that those lessons inform the rust design.
I'd say it's too early.
First, Rust is a compiled, statically typed languaged using LLVM, including stuff such as non aliasing guarantess over C, and designed to be secure AND fast. It's not like it's some scripting language.
Second, you should benchmark your program first. Worrying about a language's "performance" in abstract is more premature than even Knuth anticipated.