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

171–180 of 248 posts

Re: The Road to Rust 1.0

#171

Post by strcat »

someone13 wrote: post #19
AlyssaRowan wrote: post #12

Earlier quoted context omitted.

Not in C. Rust is, as you say, intended to be memory safe. That means it has the hope of getting it right .

FWIW, you can implement the 'Drop' trait to provide a custom destructor, and then use, e.g. 'volatile_set_memory'[0] to zero out the memory of the object. This isn't subject to the same problems as C, AFAIK. [0] http://doc.rust-lang.org/std/intrinsics/fn.volatile_set_memo...

You would have to force the sensitive content to be dynamically allocated. All types in Rust can be moved via a shallow memcpy and that will leave around dead shallow copies. For example, `Vec` will leave around dead versions of the values when it needs to do a reallocation that's not in-place.

Re: The Road to Rust 1.0

#172

Post by yxhuvud »

DennisP wrote: post #88
smacktoward wrote: post #35

Earlier quoted context omitted.

The other justification is generally a clash of cultures: the people who maintain distro/OS package managers generally come out of the culture of sysadmins, who value stability over feature-richness, while the people working the language communities generally come out of the culture of developers, whose priorities are the exact opposite. When languages try to hook into existing OS-level systems, the people on the lan…

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.

I'd be happy enough if the OS-level packagers stopped modifying the package-level packages they packaged.

Re: The Road to Rust 1.0

#173

Post by strcat »

3289 wrote: post #18

It seems that 1.0 is going to be a solid release. But the post-1.0 Rust is going to be even more exciting once they have added inheritance and subtyping which enable true polymorphic reuse!

Object inheritance is only useful in rare edge cases so your statement doesn't make much sense. Traits have default methods, inheritance and can be used as bounds on generics (no dynamic dispatch, type not lost) or as objects (dynamic dispatch / type erasure).

What makes you think object inheritance is such a sure thing anyway? I don't expect either object inheritance or optional garbage collection to materialize, ever. In fact, I'd be pretty sad if the language was degraded with that extra complexity - I think it would be a worse situation than the mess that is C++. There would no longer be a shared idiomatic Rust.

Re: The Road to Rust 1.0

#174

Post by mercurial »

burntsushi wrote: post #75
MichaelGG wrote: post #62

Earlier quoted context omitted.

Would Haskell be better off if the compiler enforced this community agreement, instead of letting users decide? Also, the type annotations can be added on later. While you work and play with ideas, leave everything unannotated. After it's cemented and perhaps refactored a bit, add the "contract". In Rust, even while working things out, the user has to figure out and jot down the types.

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

OCaml has a decent compromise between no signature at all and signatures everywhere: you put signatures in your interface. Works pretty well in practice, I find.

Re: The Road to Rust 1.0

#175

Post by mercurial »

DennisP wrote: post #88
smacktoward wrote: post #35

Earlier quoted context omitted.

The other justification is generally a clash of cultures: the people who maintain distro/OS package managers generally come out of the culture of sysadmins, who value stability over feature-richness, while the people working the language communities generally come out of the culture of developers, whose priorities are the exact opposite. When languages try to hook into existing OS-level systems, the people on the lan…

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 the target system. And you may need deploy multiple applications side by side. Few system package managers have an answer to this.

Re: The Road to Rust 1.0

#176

Post by illumen »

Does it use the GPU, memory compression, code rewriting, automatic vectorisation, multiple cores, or any other performance techniques from the last 10 years?

Re: The Road to Rust 1.0

#177

Post by dbaupp »

illumen wrote: post #176

Does it use the GPU, memory compression, code rewriting, automatic vectorisation, multiple cores, or any other performance techniques from the last 10 years?

Rust is a low-level language so everything user-space can be implemented, and the main (and only) compiler rustc uses an industrial strength optimiser (LLVM) which has support for automatic vectorisation.

Furthermore, the type system is designed to be very good for high-performance concurrency.

See http://blog.theincredibleholk.org/blog/2012/12/05/compiling-... for an example of using Rust on a GPU, and I can only imagine that it has become easier since then.

Re: The Road to Rust 1.0

#178

Post by smosher_ »

MichaelGG wrote: post #160
burntsushi wrote: post #122

Earlier quoted context omitted.

There are `fn` types---which are just function pointers---and there are `||` types, which are closures that correspond to a pointer to a function and an environment. You can actually define `fn`'s within other `fn`'s, but their types are not inferred. Closures cannot be defined at the top level, presumably because there is no global environment to capture. (Rust does have global "static" constants, though, which are…

But if a closure doesn't capture any variables then how it is different?

The immediate difference is the body of what you need to infer against. In the local case it's quite small, and the compiler doesn't have to worry about a lot of what-ifs.

Personally I like seeing types and I'm glad people are forced to write them. (This is an opinion I've had long before Rust existed, so I'm not rationalizing excuses.)

Re: The Road to Rust 1.0

#179

Post by hornetblack »

rubiquity wrote: post #11

> Green threading: We are removing support from green threading from the standard library and moving it out into an external package. I only ever looked at Rust from a 500 foot view while toying with it at a Hackathon, but I had no clue it had so many different types of threading models. This seems like a step in the right direction, indeed. If Task is going to your unit of concurrent execution, as much transparency…

Green threading used to be default. And used libuv for io. Then native threading was avaliable. Then it became default. Now green threading is being moved out of builtin libs.

Starting with green threads is really easy too:

    extern crate green;
    extern crate rustuv;

    #[start]
    fn start(argc: int, argv: *const *const u8) -> int {
        green::start(argc, argv, rustuv::event_loop, main)
    }

    fn main() {
        // this code is running in a pool of schedulers all     powered by libuv
    }
Edit: You can also start up a new libgreen scheduler pool at any time and add some native threads to the pool. So you can have some threads running with libgreen and some with libnative. (So you could theoretically embed a go program inside a rust program)

Re: The Road to Rust 1.0

#180

Post by BruceM »

pjmlp wrote: post #159
BruceM wrote: post #141

Earlier quoted context omitted.

I've been experimenting with Nix on Mac OS X lately and it works fine. I've heard that it works on FreeBSD as well. The big gap is Windows. The good news is that you can integrate your language-specific tools with Nix as well, such as has been done for Haskell, node.js and other things. (I'm looking at it so that we can integrate our Dylan stuff with it.)

When this discussions happen on HN, I always see a narrow discussion of Mac OS X, GNU/Linux, Windows and with luck *BSD. But the world of operating systems is so much bigger than the desktop under the desk. Good work on Dylan by the way.

I'd love to have the time and the resources to deal with more OSes. :) 20 years ago, I had to keep stuff running on Solaris and lots of other platforms. About 20 years ago, I still did some work on VMS on actual VAX hardware! It wasn't that long ago, that we had the possibility of BeOS either. Comparatively, we have quite a monoculture (of POSIX) these days with Windows being the non-POSIX representative.

Maybe unikernels like OpenMirage will help make things interesting.

And thanks! The work on Dylan is a lot of fun and keeps me semi-sane by keeping me busy.

Post reply on HN