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

201–210 of 248 posts

Re: The Road to Rust 1.0

#201

Post by tomp »

pkolaczk wrote: post #190
pcwalton wrote: post #151

Earlier quoted context omitted.

> There's no reason why a program written in Ruby can't do the same stack allocations, reduced memory fragmentation and predictable performance automatically - if the Ruby VM was better designed. Escape analysis falls down pretty regularly. No escape analysis I know of can dynamically infer the kinds of properties that Rust lets you state to the compiler (for example, returning structures on the heap that point to st…

Rust must statically prove lifetime of references to stack allocated variables does not exceed lifetime of the variables they point to at compile time, in order to be 100% memory safe. How is that different than just an advanced escape anlysis? Theoretically a VM could do much more, because it could do speculative escape analysis (I heard Azul guys were working on such experimental thing called escape detection) and…

You could do escape analysis equivalent to Rust's only if you inlined all the functions. Sometimes, that's simply not possible, e.g. with separate compilation.

On the other hand, Rust is still able to perform its kind of escape analysis (via lifetime-tracking type system), because the relevant facts are embedded in type signatures of Rust functions, and as such must be present even for separate compilation (even if the actual implementation of the function is unknown).

Re: The Road to Rust 1.0

#202

Post by rubiquity »

masklinn wrote: post #170
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…

It had just two: libgreen backed tasks with "green threads", libnative backed them with OS threads.

Does that mean every task will be an OS thread? Or are tasks handled by a runtime specific scheduler and will use a pool of threads for IO?

Re: The Road to Rust 1.0

#203

Post by annnnd »

aaronbrethorst wrote: post #140
tomdale wrote: post #53

We'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 mont…

Somewhat OT, but... I'm looking at your pricing, and I don't have any idea how you define the notion of a "request". Right now, I can't even begin to guess what pricing bucket my apps might fit into, and that reduces my motivation to try out your service. I speculate I'm not the only person who's felt this way. (also, I know why you include the Ember mention at the bottom, but I really don't care. I'd rather see your…

Don't let it get to you - upvote and downvote are very close for mobile users. Here you have a +1 to compensate. :)

Re: The Road to Rust 1.0

#204

Post by mercurial »

DennisP wrote: post #196
mercurial wrote: post #175

Earlier quoted context omitted.

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.

Debian will let you do that. You can run, say, your machine on testing but get the latest Firefox from experimental if you want. This may, however, upgrade other dependencies on your system, but it's pretty much unavoidable.

Re: The Road to Rust 1.0

#205

Post by moonchrome »

alkonaut wrote: post #184
shin_lao wrote: post #155

Earlier quoted context omitted.

The JVM, who is several order of magnitudes better than the Ruby VM, constantly gets smashed in terms of performance and memory usage by a well designed C++ program. Why? Because in theory, a VM should be able to do as well, if not better, than a programer. The limit of a VM is that you are extremely limited in the amount of resources you can allocate to the VM to determine how much resources should be freed. See wha…

Both the JVM and the CLR are regularly beaten by C/C++, despite claims that they are "as fast". What gives? In my view the whole problem comes down to whether or not you are using an idiomatic approach or not. In idiomatic C#/Java you use a lot of heap allocations, garbage collection, you may be using dynamic dispatch and so on. If you write a C# program that uses stack allocation only (no classes, only structs and p…

C# lacks the language features to make dealing with such coding style sane and the libraries use the "idiomatic" approach - if you're willing to put on a straitjacket and throw away the libraries then why bother with C# ?

That's not saying that C# can't be made more efficient by avoiding allocation in performance critical sections, but overall it's going to perform worse than C++, both idiomatic and non idiomatic versions. It's just that for most use cases C# is used the performance difference isn't relevant anyway.

Java doesn't even have value types, so it can't even come close in terms of memory layout efficiency and avoiding allocations without perverse levels of manual data structure expansions - for eg. consider how would you do the equivalent of : struct small { int foo; float bar; char baz; }, std::vector.

Re: The Road to Rust 1.0

#206

Post by tormeh »

pbsd wrote: post #127
dbaupp wrote: post #97

Earlier quoted context omitted.

There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time figh…

Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) ->…

Well, people tried that with D. Didn't catch on.

Re: The Road to Rust 1.0

#207

Post by dragonwriter »

pbsd wrote: post #127
dbaupp wrote: post #97

Earlier quoted context omitted.

There's more to memory-unsafety than raw pointers; all of these are problems even in the most modern C++ versions: - iterator invalidation - dangling references - buffer overruns - use after move (and somewhat, use after free) - general undefined behaviour (e.g. overlong shifts, signed integer overflow) And there's more to memory safety than security critical applications. Rust means you spend a little more time figh…

Iterator invalidation, dangling references, and use-after-move are all essentially the same thing---references outlasting their owner---no need to multiply the issues. Buffer overflows are an issue, yes, unavoidable due to the C legacy. On the other hand, it's somewhat ironic that you point to overlong shifts as a C++ problem when Rust has the exact same behavior. What does this function return? pub fn f(x: uint) ->…

> But what I got instead was an ML with better low-level support; it felt like an enormous bait-and-switch, as nobody is interested in yet-another-functional-language.

Leaving aside whether I think that's a fair description of Rust, I think plenty of people are interested in a functional programming language without the overhead of GC that is suitable for use as a low-level systems language.

You probably shouldn't write "Nobody is interested..." when what you really mean is just "I am not interested..."

Re: The Road to Rust 1.0

#208

Post by masklinn »

rubiquity wrote: post #202
masklinn wrote: post #170

Earlier quoted context omitted.

It had just two: libgreen backed tasks with "green threads", libnative backed them with OS threads.

Does that mean every task will be an OS thread? Or are tasks handled by a runtime specific scheduler and will use a pool of threads for IO?

> Does that mean every task will be an OS thread?

By default, yes.

Re: The Road to Rust 1.0

#209

Post by rubiquity »

masklinn wrote: post #208
rubiquity wrote: post #202

Earlier quoted context omitted.

Does that mean every task will be an OS thread? Or are tasks handled by a runtime specific scheduler and will use a pool of threads for IO?

> Does that mean every task will be an OS thread? By default, yes.

Hmmmm, I hope there are other alternatives in the future (besides libuv). It would be nice to see Rust have a lightweight unit of execution similar to goroutines or Erlang processes.

Re: The Road to Rust 1.0

#210

Post by genericallyloud »

hadoukenio wrote: post #67
ranran876 wrote: post #65

Earlier quoted context omitted.

I'd definitely pick C++11 unless you need to use Rust. Rust is inherently memory safe - however in practical terms this isn't important for most applications. If you are writing security critical applications Rust will provide you with some very important guarantees (ie. there are certain mistakes which are inherently not possible in the language). C++ doesn't really guarantee anything and if you're an idiot you can…

Wow, that was a great comment and exactly the type of info I was after. I think (coming from a dynamic language world) the memory safeness is what pulls me towards Rust. But from what you say and what I've read elsewhere, that was old-style C++ and not C++1[17]. Thanks!

I would just point out that the impetus for the Rust language was Mozilla looking for a better language to implement a browser in than C++. They obviously have a lot of experience writing C++ and how to do it as good as possible, but found it coming up short, especially as multi-core starts becoming the bottleneck.
Post reply on HN