Could someone lay out the advantages of Rust over C/C++/Dart/Go/other languages that cater to a similar space?
The Road to Rust 1.0
51–60 of 248 posts
Re: The Road to Rust 1.0
#52This is all good. No higher kinded types for v1.0?
Re: The Road to Rust 1.0
#53We've been using Rust in production for Skylight (https://www.skylight.io) for many months now, and we've been very happy with it.
Being one of the first to deploy a new programming language into production is scary, and keeping up with the rapid changes was painful at times, but I'm extremely impressed with the Rust team's dedication to simplifying the language. It's much easier to pick up today than it was 6 months ago.
The biggest win for us is how low-resource the compiled binaries are.
Skylight relies on running an agent that collects performance information from our customers' Rails apps (à la New Relic, if you're more familiar with that). Previously, we wrote the agent in Ruby, because it was interacting with Ruby code and we were familiar with the language.
However, Ruby's memory and CPU performance are not great, especially in long-running processes like ours.
What's awesome about Rust is that it combines low-level performance with high-level memory safety. We end up being able to do many more stack allocations, with less memory fragmentation and more predictable performance, while never having to worry about segfaults.
Put succinctly, we get the memory safety of a GCed language with the performance of a low-level language like C. Given that we need to run inside other people's processes, the combination of these guarantees is extremely powerful.
Because Rust is so low-level, and makes guarantees about how memory is laid out (unlike e.g. Go), we can build Rust code that interacts with Ruby using the Ruby C API.
I'm excited to see Rust continue to improve. Its combination of high-level expressiveness with low-level control is unique, and for many use cases where you'd previously use C or C++, I think Rust is a compelling alternative.
Re: The Road to Rust 1.0
#54The ownership idioms are very similar to idiomatic C++11 and std::unique_ptr. Which is to say that Rush has got an industrial strength safe memory management system. But Rust stands out because the rest of the language is such a joy to use, compared to pretty much any other 'systems' language out there. Congratulations to the team!
One of the cool things about the Rust ownership system is the lease/borrow system. Moving is cool, but much of the time you want to synchronously call another piece of code and give it a temporary (stack-frame-long) lease for that pointer.
Rust starts with ownership, but makes it easy to ergonomically and safely lend out that ownership (including one-at-a-time mutable leases) of both stack and heap allocated pointers.
I've been programming with Rust since last December, and I have had essentially zero segfaults coming from Rust code during that time frame, roughly equivalent to what I would have expected writing code in a language whose safety guarantees come with a runtime cost (GC or ARC).
Re: The Road to Rust 1.0
#55Adopting the channels system is interesting. Are there any other languages that have a scheduled release pattern like this?
Go sort of does this, though on longer timescales. Developers are at "tip". Actual releases are every 6 months, and before the release there is always at least one release candidate, and sometimes an actual beta.
Re: The Road to Rust 1.0
#56I used to describe my preferred family of languages as: - C when I absolutely had to (kernel/modules/plumbing). - Python for scripting and broad accessibility. - Haskell when I had the choice and I knew everybody who would work on the project. I was skeptical of Rust when it first came out, due in large part to the many different kinds of pointers it originally had, many of which involved significant manual memory ma…
> Disappointing to see yet another language-specific package management system (Cargo), though So what is the solution to have portable packages for: - RPM systems - Debian systems - tarball systems - Pkg systems - MSI systems - Mainframe OS - Embedded OS - Aix/HP-UX/Solaris package systems - ...
The goal of the [nix](http://nixos.org/) project is to solve this, and every time anyone brings up a package manager on HN, someone has to mention nix. The reality is that nix is really nice, but isn't any better than making a new package manager until it has wide adoption, so no one is using it.
Re: The Road to Rust 1.0
#57Still sitting on the fence as to which language I should pick up on next - the only contenders are C++11 and Rust. How does Rust compare with C++11 as a language? C++11 seems to (in some ways) have caught up with what Rust has to offer (compared to older C++ versions) e.g. smart pointers, concurrency and regexes part of the standard library
C++ is useful when learning Rust since a lot of documentation assumes the reader is familiar with C++ and there’s plenty of C++ documentation that has no pre-requisites.
Hmm. I learned Rust without any C++ knowledge (though I did have a fair amount of experience with C), and it was pretty easy. Recently I've had to start writing some C++ (to my dismay), and it has not been so easy... the language is really complex.
Re: The Road to Rust 1.0
#58This is all good. No higher kinded types for v1.0?
Nope. We're pretty sure they'll be backwards compatible, and there are too many other outstanding issues (eg, syntax) and too little time. Lots of us want them though!
Re: The Road to Rust 1.0
#59Earlier quoted context omitted.
> Disappointing to see yet another language-specific package management system (Cargo), though So what is the solution to have portable packages for: - RPM systems - Debian systems - tarball systems - Pkg systems - MSI systems - Mainframe OS - Embedded OS - Aix/HP-UX/Solaris package systems - ...
The goal of the [nix]( http://nixos.org/ ) project is to solve this, and every time anyone brings up a package manager on HN, someone has to mention nix. The reality is that nix is really nice, but isn't any better than making a new package manager until it has wide adoption, so no one is using it.
Nix was brought up during the discussion that led to Cargo, but no Windows support is a deal breaker.
Re: The Road to Rust 1.0
#60Rust looks fantastic, and has a lot of things I wish I could do while in a higher level language like F#. I just wish Rust was a bit less verbose. Requiring, for instance, type annotations on function arguments because it's sometimes helpful is such a weird decision. Let the programmer decide when an annotation is needed. This gets annoying when you get into functions with complex arguments. Especially for local func…
Even in languages with whole-program inference, it's generally regarded as best practice to write out the types of your functions, hence Rust's choice here. You're right that there's a tradeoff. In general, Rust follows 'explicit over implicit.' > This gets annoying when you get into functions with complex arguments. Have you seen the where clauses yet? This should significantly help complex function declarations.
I just don't understand why there has to be a tradeoff. I just don't get why the compiler should decide on such a large thing, instead of letting the programmer do it. One can always be more explicit if one feels they're getting value from it. If someone wants to write a bunch of terse code, why stop them? Does the compiler gain a large benefit from not having to include this feature? Who loses by allowing users to do what they want?
Comparing C# and F#, the extra annotations change the frequency in which I'll introduce an inner (local) function. For instance, here's a little helper in a piece of code I'm writing at the moment. It's part of a larger function and isn't exposed beyond 5 lines of code.
let runWithLog f name =
try run f name with ex -> logExn ex
Having to add "(f: string -> RunParams -> Whatever -> unit) (name: string)" almost doubles runWithLog helper yet provides no benefit. And this an extremely simple case! Once the arguments are generic, higher-order functions themselves, it gets quite noisy.
Sure, if it's a top-level export, then maybe annotating is a good idea. But if it's limited in scope then what's the harm?
Not that it'll change when I use Rust - there's nothing competing in this category. It'd just be nice if the language let the user decide on the style.