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

161–170 of 248 posts

Re: The Road to Rust 1.0

#161

Post by shin_lao »

dbaupp wrote: post #158
shin_lao wrote: post #156

Earlier quoted context omitted.

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?)

For small strings, a copy is not only faster but more multithreading friendly.

Keep in mind that on a 64-bit architecture a view is at least 16 bytes large and that small strings can be copied to the stack resulting in better locality and reduced memory usage.

Last but not least, with copy elision, your temporaries might not even exist in the first place.

Example:

    std::string data;
    // ...
    auto str = data.substr(2, 3);
    // pretty sure str will be optimized away
    if (str[0] == 'a')

Re: The Road to Rust 1.0

#162

Post by xngzng »

doe88 wrote: post #16

What I think is an important feature of this language is the ease with which it can interact with other languages. Especially the possibility for Rust code to be called from foreign languages such as C very easily. I'm looking forward for even better support of iOS with the support of arm64, I think it is really important to offer an alternative. BTW is there an RFC on dynamically sized types ? I can't find any, I'm…

Agreed. Two areas I can think of: 1. Rust library that is callable from Python. Many are using C/C++ for optimised Python program. 2. Able to create iOS framework library in Rust to be callable from Swift/Objective-C; similarly Rust library callable from Android NDK.

Re: The Road to Rust 1.0

#163

Post by wycats »

djur wrote: post #96
wycats wrote: post #44

Earlier quoted context omitted.

> The second production deployment of Rust is a Ruby gem, written in C, that calls out to Rust. It's used in skylight.io, if you're curious. Yep! I'm one of the authors of that project. The fact that Rust provides automatic memory cleanup and the attendant safety without runtime overhead (even ARC has non-trivial runtime overhead) was a huge win for us, as was the transparent FFI. We were looking for a way to write f…

Are there any open source libraries spun off from the Skylight agent? It would be nice to see some examples of production-quality Rust code.

A few:

* https://github.com/carllerche/hamcrest-rust - a (badly in need of more fleshing out) testing library * https://github.com/carllerche/nix-rust - bindings of Linux/OSX-specific APIs to Rust * https://github.com/carllerche/curl-rust - a binding of libcurl to Rust * https://github.com/carllerche/pidfile-rust - a library for using a pidfile for mutual exclusion across processes * https://github.com/carllerche/mio - a low-level IO library that attempts to implement an epoll-like interface across multiple platforms

Re: The Road to Rust 1.0

#164

Post by toolslive »

How difficult is it to start from a huge C++ codebase and start adding new features in Rust? How bad is such an idea? I know there is interoperability, but those are toy examples, does anybody have real life experiences?

Re: The Road to Rust 1.0

#165

Post by dbaupp »

shin_lao wrote: post #161
dbaupp wrote: post #158

Earlier quoted context omitted.

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?)

For small strings, a copy is not only faster but more multithreading friendly. Keep in mind that on a 64-bit architecture a view is at least 16 bytes large and that small strings can be copied to the stack resulting in better locality and reduced memory usage. Last but not least, with copy elision, your temporaries might not even exist in the first place. Example: std::string data; // ... auto str = data.substr(2, 3)…

I don't think copy elision[1,2] means what you think it means, it simply allows the compiler to avoid e.g. allocating a new string when returning a string, or avoid allocating a new string to store the result of a temporary. That is, copy elision allows

   std::string str = data.substr(2, 3);
   return str;
to only allocate one new string (for the return value of substr), instead of two. There's no way the compiler can get out of constructing at least one std::string for the return value, especially if there's any form of dynamic substr'ing (e.g. parsing a CSV file with columns that aren't all the same width).

Sharing is only multithreading unfriendly if there's modification happening, and modification of textual (i.e. Unicode) data is bad practice and hard to get right, since all Unicode encodings are variable width (yes, even UTF-32, it is a variable width encoding of visible characters).

Furthermore, a string_view is strictly better than a string for many applications, since a string_view can always be copied into a string by the caller if necessary (i.e. each function can choose to return the most sensible/most performant thing, which is a string_view if it's just a substring of one of the arguments).

The only sensible argument against string_view in C++ I know is: it's easy to get dangling references. Which is correct, but that's a general problem with C++ itself, not with the idea of string views (Rust has a perfectly safe version in the form of &str, which cannot become dangling like in C++).

> Keep in mind that on a 64-bit architecture a view is at least 16 bytes large and that small strings can be copied to the stack resulting in better locality and reduced memory usage.

No, a string_view points into memory that already exists, there's no increased memory usage; a small string copied on to the stack will be part of the string struct, which is at least 3 * 8 = 24 bytes: a pointer, the length and the capacity. Also, a memcpy out of the original string is always going to be more expensive than just getting the pointer/length (or pair of pointers) for a string_view, since the memcpy has to do this anyway.

[1]: http://en.wikipedia.org/wiki/Copy_elision

[2]: http://definedbehavior.blogspot.com/2011/08/value-semantics-...

Re: The Road to Rust 1.0

#166

Post by mercurial »

dragonwriter wrote: post #91
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.

Haskell compilers can, and its probably better for production code to have them do it. OTOH, it can be better for exploratory coding in some circusmtances not to. (For one thing, it can be a tool to find cases where you accidentally write something that is more general than the types you were thinking of, but perfectly valid for the more general type -- which, at least as someone fairly new to Haskell, I find myself…

It's also much more convenient for REPLs.

Re: The Road to Rust 1.0

#167

Post by [deleted] »

toolslive wrote: post #164

How difficult is it to start from a huge C++ codebase and start adding new features in Rust? How bad is such an idea? I know there is interoperability, but those are toy examples, does anybody have real life experiences?

[deleted]

Re: The Road to Rust 1.0

#168

Post by lvillani »

shadowmint wrote: post #125
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…

There are some work-in-progress code completion tools https://github.com/phildawes/racer ). No format tool yet, but its often talked about and Id be surprised if it doesnt happen. The biggest infrastructure difference to go at the moment is that its tricky to cross compile binaries in rust.

From time to time I use "rustc --pretty normal ". Not a real formatting tool, and it has a tendency to produce some funny results at times, but it's better than nothing.

Re: The Road to Rust 1.0

#169

Post by dscrd »

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.

As a packager in a Linux distro, I'm disappointed every time somebody tries to cram in PL-specific packages inside distro packages.

Re: The Road to Rust 1.0

#170

Post by masklinn »

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