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

181–190 of 248 posts

Re: The Road to Rust 1.0

#181

Post by creatio »

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…

Is it possible to get the names of the Phd thesis read?

Re: The Road to Rust 1.0

#182

Post by nikbackm »

dbaupp wrote: post #112
pbsd wrote: post #109

Earlier quoted context omitted.

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

Seems like this was fixed in C++14 by adding a std::string&& overload.

http://en.cppreference.com/w/cpp/regex/regex_match

Re: The Road to Rust 1.0

#183

Post by dbaupp »

nikbackm wrote: post #182
dbaupp wrote: post #112

Earlier quoted context omitted.

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

Seems like this was fixed in C++14 by adding a std::string&& overload. http://en.cppreference.com/w/cpp/regex/regex_match

The underlying problem is still there, fixing a few of the worst cases in the standard library is helpful but only up to a point. (E.g. anyone with a custom function that does something in a similar vein needs to remember to do the same.)

Re: The Road to Rust 1.0

#184

Post by alkonaut »

shin_lao wrote: post #155
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…

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 primitives), no inheritance/polymorphism, no exceptions, you should find that the CLR stands up pretty well to a C++ program. Sadly, what you have done then is essentially code in a very small subset of C#, OR you have achieved something that is so hard and so prone to foot-shooting you could just as well have used C++ to begin with.

To reverse the argument: if you use C++ with loads of garbage collected objects etc. you will end up with performance similar to a java/C# program. But in idiomatic C++, you usually don't.

Re: The Road to Rust 1.0

#185

Post by alkonaut »

Hopefully the tooling will take off once the language stabilizes. Using a "newish" language is a total exercise in frustration when you are a spoiled kid who expects an IDE to come with your language configured, and a nice big play button for running your first program.

For a language to take off, it badly needs a very good (ideally "official") development experience, such as a custom eclipse impl, or a very good IntelliJ plugin. When a dev experience comes with batteries included it lowers the treshold substantially from just "use whatever text editor you like and compile on command line, here is a readme".

Re: The Road to Rust 1.0

#186

Post by dbaupp »

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…

(I think shin_lao was actually talking along the same lines, saying that even the hyper-optimised JVM often isn't as good as a good C++ program.)

Re: The Road to Rust 1.0

#187

Post by alkonaut »

dbaupp wrote: post #186
alkonaut wrote: post #184

Earlier quoted context omitted.

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…

(I think shin_lao was actually talking along the same lines, saying that even the hyper-optimised JVM often isn't as good as a good C++ program.)

I agree, my point is merely that the bulk of the difference between idiomatic Java programs and idiomatic C++ programs is due to the wildly different ways of of programming idiomatically in Java vs. C++.

The small (steady state) performance difference remaining when doing the "exact same thing" in both programs is just down to how good the C++ compiler is vs. the VM JIT at optimizing (usually better, sadly).

What intrigues me about Rust is that hopefully we won't have to choose between readability and elegance vs. performance and safety. Keep up the good work.

Re: The Road to Rust 1.0

#188

Post by fanf2 »

burntsushi wrote: post #152
dbpatterson wrote: post #146

Earlier quoted context omitted.

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!()` o…

I thought ! in Rust indicates a macro.

Re: The Road to Rust 1.0

#189

Post by InclinedPlane »

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…

Meta note: I saw that this post was being pretty heavily downvoted and upvoted it to keep it from falling out of the discussion. I disagree with the assumptions in the post, but they are handily refuted by replies. I'd rather have a robust discussion with every reasonable side well represented than a boring echo chamber.

I urge other folks here to not merely blindly downvote posts they disagree with, reserve downvoting for posts that don't deserve to be seen at all because they don't contribute to the discussion.

Re: The Road to Rust 1.0

#190

Post by pkolaczk »

pcwalton wrote: post #151
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…

> 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 even move variables from stack to heap once it turns out they do escape.
Post reply on HN