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

111–120 of 248 posts

Re: The Road to Rust 1.0

#111

Post by tiles »

bjz_ wrote: post #102
Jweb_Guru wrote: post #79

Earlier quoted context omitted.

I definitely understand where you are coming from, and I agree that C++11's ecosystem maturity is a great reason to choose it at the moment. However, I cannot agree with you that Rust's safety guarantees are not useful for most C++ programs, or that you have to be an "idiot" to do memory-unsafe things in C++11. Someone at Yandex recently did a presentation about Rust [1] in which they pointed to a bit of (completely…

> 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 slides on Slideshare are surprisingly easy to follow (and were a good introduction for me): http://www.slideshare.net/yandex/rust-c

Re: The Road to Rust 1.0

#112

Post by dbaupp »

pbsd wrote: post #109
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.

See slide 42 of STL's recent talk for what I guess will be a similar example: https://github.com/CppCon/CppCon2014/tree/master/Presentatio...

Reproduced here:

  const regex r(R"(meow(\d+)\.txt)");
  smatch m;
  if (regex_match(dir_iter->path().filename().string(), m, r)) {
      DoSomethingWith(m[1]);
  }
- What's wrong with this code?

  - Haqrsvarq orunivbe va P++11
  - Pbzcvyre reebe va P++14
  - .fgevat() ergheaf n grzcbenel fgq::fgevat
  - z[1] pbagnvaf vgrengbef gb n qrfgeblrq grzcbenel
(http://rot13.com/ 'd if you want to guess.)

Re: The Road to Rust 1.0

#113

Post by dbaupp »

bjz_ wrote: post #102
Jweb_Guru wrote: post #79

Earlier quoted context omitted.

I definitely understand where you are coming from, and I agree that C++11's ecosystem maturity is a great reason to choose it at the moment. However, I cannot agree with you that Rust's safety guarantees are not useful for most C++ programs, or that you have to be an "idiot" to do memory-unsafe things in C++11. Someone at Yandex recently did a presentation about Rust [1] in which they pointed to a bit of (completely…

> 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

Re: The Road to Rust 1.0

#114

Post by yazaddaruvala »

tomdale wrote: post #103
alelefant wrote: post #99

Earlier quoted context omitted.

I've never built a Rails app, so perhaps there's something simple that I'm missing (I'm mostly a C# guy), but how would I use Skylight to monitor my on-premise application? The pricing makes it seems like a hosted service. I would have expected some sort of profiler to be needed on the server and then perhaps a centralized location for the data to be pushed to for display. The design of the site is great and I'm most…

Thanks for asking. If you're interested in the nitty-gritty, Yehuda and I gave a talk on the architecture behind Skylight at RailsConf: http://www.confreaks.com/videos/3394-railsconf-how-to-build-... The short version is that the agent runs on your servers and collects information from your Rails app using the ActiveSupport::Notifications instrumentation built in to the framework. We serialize that into a protobuf th…

Just an FYI, while I think, to set up skylight I just add a gem to my project, I'm still not really sure. It would have been nice to go to your homepage and have it confirm that it is easy to configure/deploy into your application.

Re: The Road to Rust 1.0

#115

Post by steveklabnik »

burntsushi wrote: post #100
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?

Steve already told you that refcounting isn't reached for by default, and I wanted to share an anecdote to emphasize that. I've written a regex library, CSV parser, command line arg parser, elastic tabs and quickcheck in Rust. Behold: $ find ./ -type f -name '*.rs' -print0 | xargs -0 grep Rc $ I've definitely reached for it a few times as an escape hatch, but I've always ended up finding a cleaner approach to persist…

You're logged in as root? O_O :p :)

Re: The Road to Rust 1.0

#116

Post by MichaelGG »

burntsushi wrote: post #89
MichaelGG wrote: post #60

Earlier quoted context omitted.

I just don't understand why there has to be a tradeoff. I just don't get why the compiler should decide on such a large thing, instead of letting the programmer do it. One can always be more explicit if one feels they're getting value from it. If someone wants to write a bunch of terse code, why stop them? Does the compiler gain a large benefit from not having to include this feature? Who loses by allowing users to d…

Rust will do type inference on lambdas for you. :-) fn fubar(x: uint) { let times = |n| x * n; println!("{} * 5 = {}", x, times(5)); } Rust only enforces type annotations on top-level functions. > Does the compiler gain a large benefit from not having to include this feature? Who loses by allowing users to do what they want? FWIW, I feel precisely the opposite as you. I'd rather have an ecosystem of code where top le…

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?

Re: The Road to Rust 1.0

#117

Post by burntsushi »

steveklabnik wrote: post #115
burntsushi wrote: post #100

Earlier quoted context omitted.

Steve already told you that refcounting isn't reached for by default, and I wanted to share an anecdote to emphasize that. I've written a regex library, CSV parser, command line arg parser, elastic tabs and quickcheck in Rust. Behold: $ find ./ -type f -name '*.rs' -print0 | xargs -0 grep Rc $ I've definitely reached for it a few times as an escape hatch, but I've always ended up finding a cleaner approach to persist…

You're logged in as root? O_O :p :)

Haha, no, I added that in after-the-copy-and-paste. :P

Fixed nonetheless. Do'h.

Re: The Road to Rust 1.0

#118

Post by MichaelGG »

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…

Certainly the user should be allowed to decide when they feel the code needs further documentation to be readable. Trying to drag people into something seems unfriendly.

Re: The Road to Rust 1.0

#119

Post by pnathan »

ranran876 wrote: post #65
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

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…

I've had a vastly happier Rust experience than C++ experience (I've written in both, well beyond the "zomgz 50line starter program").

The Rust compiler is vastly smarter and gets you type checking you have to pay out the nose for in C & C++. I'm a fanboy of Rust, but I would suggest looking hard at Rust for any C or C++ production code going forward. (My default going forward for this space will be Rust unless overriding considerations say otherwise).

Re: The Road to Rust 1.0

#120

Post by Shamanmuni »

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!

Read what the other commenters are pointing out. Maybe the situation is better in C++ now than it was before, but it doesn't mean you can't shoot yourself in the foot, specially for a beginner. Rust was built with safety in mind from the start, there are errors you can make in C++ that the Rust compiler simply won't let.

My advice is, if you're learning it for work, then go with C++. Even if it succeeds, it will take some years for Rust to be mainstream and as pointed out the library support is great.

If you're learning it for fun or for the sake of learning something new. Then Rust is a very nice and promising language bringing things from functional languages that C++ lacks and offering very interesting tooling around it.

Whatever you choose, after you feel confident with one go and learn the other as it will probably give a better perspective in the strengths and/or weaknesses of both.

Post reply on HN