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

131–140 of 248 posts

Re: The Road to Rust 1.0

#131

Post by bjz_ »

jroesch wrote: post #94
steveklabnik wrote: post #86

Earlier quoted context omitted.

That's right, there hasn't even been enough work for an RFC.

I think one of the core challenges is how traits play with HKTs. You can only allow for the defining of HKed type parameters and type arguments so many ways, but it becomes more complicated when dealing with the resolution of traits around HKTs. In Haskell for ex. there is no `Self` so the type class can easily be dispatched on a higher kinded type without needing a receiver type. In Rust `Self` must currently be ful…

> I'm hoping to finish the RFC once all these features land and I can actually hack a prototype, instead of scribbling on paper.

This would be amazing. One of the big issues blocking HKTs has been that though many folks want it there hasn't really been anyone willing to champion it yet. No pressure though - it is a tough problem.

Re: The Road to Rust 1.0

#132

Post by sigzero »

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.

No, I don't want my language to be bound to someone else's package manager at all.

Re: The Road to Rust 1.0

#133

Post by jfager »

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

What do you mean by 'low-level extensions'? There's nothing in the language proper that can't run on bare metal, how much lower can you get?

If anything, it's the functional parts that feel bolted on: closures are crippled (though getting better soonish), the types that get spit out of iterator chains are hideous, no currying, no HKTs, functional data structures are much harder to write w/o a gc, etc.

Re: The Road to Rust 1.0

#134

Post by cdnsteve »

Can rust be used to power http endpoints like a REST API? Or is it more designed to be system type daemon stuff? I guess I don't fully understand the marketing of it, however I haven't ever written anything in C or C++ either.

Re: The Road to Rust 1.0

#135

Post by ufo »

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

Can you say what is the problem here? What is a string_view?

Re: The Road to Rust 1.0

#136

Post by dbaupp »

ufo wrote: post #135
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

Can you say what is the problem here? What is a string_view?

A non-owning pointer into string memory owned by someone else (effectively a reference into some string). AIUI, the problem is the temporary string returned by get_url() is deallocated immediately after the get_scheme_from_url call, meaning that the string_view reference `scheme` is left dangling.

Re: The Road to Rust 1.0

#137

Post by Xorlev »

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…

Love that you guys are using Rust in production. Very elegant design (AS::Notification IPC -> Rust).

I'd dump the part of the marketing site talking about the fast UI on Ember. It's cool that you guys use Ember and you're proud of it, but I want to see more about your product. Show me how easy it is to drop into an app, or reports you generate, alerts you flag, etc..

Ultimately, while I nerd out on what a product is built with, I only care about what it can offer me. Fast UI isn't a feature, it's an expectation.

Re: The Road to Rust 1.0

#139

Post by tmzt »

cdnsteve wrote: post #134

Can rust be used to power http endpoints like a REST API? Or is it more designed to be system type daemon stuff? I guess I don't fully understand the marketing of it, however I haven't ever written anything in C or C++ either.

There are already a number of libraries and frameworks that implement an HTTP setver in Rust, though things seem to be coalescing around Teepee.

http://chrismorgan.info/blog/introducing-teepee.html#main

There are few REST api libraries as well.

Re: The Road to Rust 1.0

#140

Post by aaronbrethorst »

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 awesome UI than hear what technology it's based on.)

Edit: Seriously, I'm getting downvoted for offering someone feedback on their product experience?

Post reply on HN