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

151–160 of 248 posts

Re: The Road to Rust 1.0

#151

Post by pcwalton »

chrisseaton wrote: post #143
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…

"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." But isn't this stuff the job of the VM? 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. If Ruby had a bett…

> 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 structures on the stack in an interprocedural fashion).

This is not in any way meant to imply that garbage collection or escape analysis are bad, only that they have limitations.

Re: The Road to Rust 1.0

#152

Post by burntsushi »

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…

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!()` or `unreachable!()` or `unimplemented!()` or define-your-own.)

> (if you've ever written a little wrapper around a function from a complicated library, you know what I mean)

Yes, absolutely. I haven't really run into this problem with Rust yet though. Types are generally pretty simple. If and when Rust gets higher-kinded types, that would assuredly change.

Re: The Road to Rust 1.0

#154

Post by zeeboo »

dbaupp wrote: post #126
hit8run wrote: post #121

Earlier quoted context omitted.

Hey Tom, did you also consider googles golang? Currently I'm building my backends with golang and I am pretty satisfied with the performance and the whole flow. Maybe it is sometimes a bit cumbersome to check on errors like a paranoid but in the long term it helps to predict what happens in error cases. How about rust? Is the workflow comparable to golang? Is there an equivalent to gofmt and some ide support for code…

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…

Actually, that Go bug is the scanning code getting confused about an incorrectly stored stack pointer value during a very small race between returning from a FFI call into Go and generating a traceback for scanning. I'm not familiar enough with the internals to comment on if that can lead to freeing FFI memory, but I don't think so. Not that crashing the process is much better. :)

Re: The Road to Rust 1.0

#155

Post by shin_lao »

chrisseaton wrote: post #143
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…

"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." But isn't this stuff the job of the VM? 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. If Ruby had a bett…

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 what I mean?

In the end the VM is nothing less than a program. With RAII, for example, there is zero overhead associated with the decision of releasing a memory block, because it's compiled into the program.

On top of that if you start to add some nasty memory optimization tricks allow you, you start to get why manually managing memory is still very interesting when performance and/or memory usage is important.

Re: The Road to Rust 1.0

#156

Post by shin_lao »

dbaupp wrote: post #113
bjz_ wrote: post #102

Earlier quoted context omitted.

> Someone at Yandex recently did a presentation about Rust[1] in which they pointed to a bit of (completely idiomatic!) C++11 code that caused undefined behavior. It would be great to have at least that segment of the talk translated. Sounds like a good example.

The example: std::string get_url() { return "http://yandex.ru"; } string_view get_scheme_from_url(string_view url) { unsigned colon = url.find(':'); return url.substr(0, colon); } int main() { auto scheme = get_scheme_from_url(get_url()); std::cout

The string_view pattern is a pretty bad idea and useless with a decent compiler.

Re: The Road to Rust 1.0

#157

Post by vidarh »

dbaupp wrote: post #147
chrisseaton wrote: post #143

Earlier quoted context omitted.

"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." But isn't this stuff the job of the VM? 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. If Ruby had a bett…

It is very hard to have all this done reliably, especially in a rather dynamic language like Ruby. Maybe the Ruby VM could be better designed to perform these sort of optimisations, but it will never give the same control as a language like Rust, C or C++; i.e. a small code change could cause the optimiser to fail, leading to slow-down and bloat. Furthermore, the hypothetical "sufficiently smart VM" isn't much value…

[Chris has done some fantastic work on a Truffle / Graal backend for jruby; for my part I'm (slowly) working on a "mostly-ahead-of-time" Ruby compiler]

I'm not sure I'd agree with "never", though I do agree Ruby is a hard language to optimize.

There are two challenges with optimizing Ruby: What people do and don't know the potential cost of, and what people pretty much never do, but that the compiler / VM must be prepared for.

The former includes things like "accidentally" doing things that triggers lots of copying (e.g. String#+ vs String#The former is a matter of education, but a lot of the benefits for many things are masked by slow VMs today that in many cases makes it pointless to care about specific methods, and an expectation not to think much about performance (incidentally, it's not that many years ago that C++ programmers tended to make the same mistakes en-masse)

The latter can be solved (there are other alternatives too), or at least substantially alleviated, in the general case by providing means of making a few small annotations in an app. E.g. we could provide a gem with methods that are no-ops for MRI but that signals to compilers that you guarantee not to ever do certain things, allowing many safeguards and fallbacks to be dropped.

Ruby's dynamic nature is an asset here in that there are many things where we can easily build a gem that provides assertions that on e.g. MRI throws an error if violated or turns into a no-op, but that on specific implementations "toggle" additional optimizations that will break if the assertions are not met. E.g. optional type assertions to help guide the optimizer for subsets of the app.

In other words: how optimized Ruby implementations we get depends entirely on whether people start trying to use Ruby for things where they badly need them.

Re: The Road to Rust 1.0

#158

Post by dbaupp »

shin_lao wrote: post #156
dbaupp wrote: post #113

Earlier quoted context omitted.

The example: std::string get_url() { return "http://yandex.ru"; } string_view get_scheme_from_url(string_view url) { unsigned colon = url.find(':'); return url.substr(0, colon); } int main() { auto scheme = get_scheme_from_url(get_url()); std::cout

The string_view pattern is a pretty bad idea and useless with a decent compiler.

What do you mean by useless?

If I have a string like "foo bar baz" and I want the second word, should I copy out that data into a whole new string? That seems rather inefficient.

(How is a compiler going to optimise that away?)

Re: The Road to Rust 1.0

#159

Post by pjmlp »

BruceM wrote: post #141
pjmlp wrote: post #95

Earlier quoted context omitted.

It seems to be only for GNU/Linux systems, what about all other OSs out there?

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.

Re: The Road to Rust 1.0

#160

Post by MichaelGG »

burntsushi wrote: post #122
MichaelGG wrote: post #116

Earlier quoted context omitted.

Oh if nested functions don't need annotation, then I suppose that saves most of the problem. Can top-level definitions be of the lambda form? If not, what's the reason to have separate ways?

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?
Post reply on HN