Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Road to Rust 1.0

blog.rust-lang.org

Post reply on HN
Print view View original

191–200 of 248 posts

Re: The Road to Rust 1.0

#191

Post by seabee »

dbaupp wrote: post #92
JoshTriplett wrote: post #8

I 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…

As others have said, having a package management system that deeply understands the language and tooling is awesome. Examples: - Rust has a distributed-by-default documentation generator (rustdoc), cargo knows this and provides `cargo doc` to render a library's docs with it. - rustdoc can run code examples in the documentation as tests, to check that everything is up-to-date, `cargo test` does this (along with runnin…

It's very similar to Racket, and yes, it is nice to use!

Other systems can get you much of the way there (node, Python are the only ones I'm really familiar with) but I suspect you need a little language help to achieve the same kind of convenience.

Re: The Road to Rust 1.0

#192

Post by InclinedPlane »

JoshTriplett wrote: post #8

I 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.

That's a much bigger problem to tackle, and one that nobody has really thought much on or done much work with. Package management is a tough problem in the abstract, and it's a big challenge to create a meta-package management infrastructure, more so when there doesn't seem to be any money in it (at least not easily).

Re: The Road to Rust 1.0

#194

Post by burntsushi »

fanf2 wrote: post #188
burntsushi wrote: post #152

Earlier quoted context omitted.

Interesting point. Getting the type annotation inferred for you there is definitely useful. I've used it a few times myself. The `undefined` trick is also immensely useful. I use it a lot when starting a new module. Rust also has a notion of bottom, indicated by `!`, which will unify with all types. I frequently use this in Rust in a similar way that I use `undefined` in Haskell. (In Rust, you would speak `fail!()` o…

I thought ! in Rust indicates a macro.

A `!` followed by an identifier does, yes. But a `!` also lets you define diverging functions:

    fn diverging() -> ! {
        unreachable!()
    }
The two `!` in that code are completely orthogonal things. See the manual on diverging functions: http://doc.rust-lang.org/rust.html#diverging-functions

Re: The Road to Rust 1.0

#195

Post by lmm »

hadoukenio wrote: post #43

Still 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

Why are those your only choices? What makes your problem unsuited to e.g. Nimrod?

Re: The Road to Rust 1.0

#196

Post by DennisP »

mercurial wrote: post #175
DennisP wrote: post #88

Earlier quoted context omitted.

Maybe OS-level package managers should default to stable, but let the user check a box to get the latest and greatest. Developers want a stable system like everyone else, but for the stuff we're hacking on, we have a legitimate need to get the most recent, so our software isn't obsolete by the time we finish it.

That's not so simple. A distro is a fine-tuned collections of packages which work more or less well together. Debian, for instance, comes in stable/testing/unstable/experimental flavours, depending on how daring you are. But even this isn't a universal solution. If you are deploying for instance a web application, you will want to deploy a locked down number of dependencies as well, regardless of what is present on t…

So developers end up installing later versions manually. And in many cases it's no big deal. If the distro has Julia 0.2.1 and Emacs 23, I can upgrade to Julia 0.3 and Emacs 24 and it's not likely to damage anything. It'd just be nice if I could do it with the package manager instead.

But just because I'm doing that doesn't necessarily mean I want, say, the latest unstable version of the window manager.

Re: The Road to Rust 1.0

#197

Post by [deleted] »

dbaupp wrote: post #92
JoshTriplett wrote: post #8

I 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…

As others have said, having a package management system that deeply understands the language and tooling is awesome. Examples: - Rust has a distributed-by-default documentation generator (rustdoc), cargo knows this and provides `cargo doc` to render a library's docs with it. - rustdoc can run code examples in the documentation as tests, to check that everything is up-to-date, `cargo test` does this (along with runnin…

[deleted]

Re: The Road to Rust 1.0

#198

Post by ben0x539 »

Xorlev wrote: post #142
dbaupp wrote: post #126

Earlier quoted context omitted.

I don't speak for tomdale/wycats, but embedding a language with a GC (Go) inside another GC'd language (Ruby) only leads to worlds of pain, especially when trying to efficiently transfer data between them. In languages without compulsory GCs (like Rust, which doesn't have one at all) this works because it's easy to have complete control about when memory is freed, but a GC'd language may free memory that was passed b…

From what I understood, it's a Rust agent communicating protobuf structs over IPC, not embedded into the gem. In such a case, memory safety and GC is less of an issue.

I've never looked at it too closely, but wycats has talked about how the Ruby code calls Rust code through the FFI and how Skylight doing some special things to make that work especially smoothly by directly calling some internal functions of Rust's failure handling bits, and about how the Rust code crashing shouldn't take down the rails process. That seems to suggest it's not just an IPC thing.

Re: The Road to Rust 1.0

#199

Post by eddyb »

steveklabnik wrote: post #70
austinz wrote: post #68

Congratulations to the Rust team! Can't wait to start learning the language and building stuff using it. I'm looking to learn about how Rust's refcounting memory management works (and how it differs from how, e.g. Objective-C or Swift's runtime-based reference counting works), mostly for personal edification. Can anyone point me to any good resources?

Is worth noting that you don't reach for reference counting by default in Rust: your reach for references, then boxes, THEN Arc. You can find documentation on these types here: http://doc.rust-lang.org/guide-pointers.html

Well, you wouldn't go for Arc (atomic RC) unless you need to share data across tasks (threads), within the same task you can use Rc.

This is different from shared_ptr in C++ which is always atomic and LLVM has to try hard (in clang, no idea what GCC does) to eliminate some redundant ref-counts.

Oh and since Rc is affine, you only ref-count when you call .clone() on it or you let it fall out of scope.

Most of the time you can pass a reference to the contents, or, if you need to sometimes clone it, a reference to the Rc handle, avoiding ref-counting costs.

Re: The Road to Rust 1.0

#200

Post by tel »

dbpatterson wrote: post #146
burntsushi wrote: post #75

Earlier quoted context omitted.

> Would Haskell be better off if the compiler enforced this community agreement, instead of letting users decide? Unequivocally, yes. My logic is that, while writing the function may be slightly quicker and more convenient if you can leave off the type, reading that same code is made at least an order of magnitude easier if the type annotation is sitting there in the code. Actually, it gets better than that. Writing…

The thing is, with current tooling, the current design means that I can write a function, type a key combination, and have the type signature printed in a buffer (where I can then copy it into place). And until I do that, there is warning highlighting on the function. Now in some ways this may seem silly - are you really going to understand code without understanding types? But especially for people new to the langua…

> Now in some ways this may seem silly

Not at all!

Typing should be a conversation with the compiler. If you have a strong understanding of what you are writing then, yes, writing the types first makes sense. On the other hand, sometimes I only understand how some particular pieces fit together—at this point, I want the compiler to throw its inference engine at my code fragment and tell me everything it can!

Typing and programming is exactly the same as theorem stating and proving in mathematics. It would be idiotic to have one-way information flow only.

That said, it's also practically criminal to just hand someone a proof without stating what you think it's supposed to be proving. Ultimately, that it where you must wind up.

Post reply on HN