Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust's 2017 Roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

241–250 of 274 posts

Re: Rust's 2017 Roadmap

#241

Post by general_pizza »

ainar-g wrote: post #26

Does the "lower learning curve" goal include the lowering of learning curve for people who already know how to program? Because right now, the Book sometimes seems like it's aimed for people who either didn't program a lot, or didn't program in a language with types. What I actually would like is a few "Books" like "Rust for C++ people", "Rust for Go people", etc. Those would describe in many examples how things that…

Interesting. Out of curiosity, what's a case where tmp = a.b(); tmp.c() works but a.b().c() doesn't? I'm still learning rust and the online book's Methods chapter doesn't say anything about such restrictions.

Re: Rust's 2017 Roadmap

#242

Post by kibwen »

iopq wrote: post #201
kibwen wrote: post #98

Earlier quoted context omitted.

> I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)

And it should be white-space sensitive! 1. Writing a tab character introduces the equivalent of {} for blocks, but not other uses of {}. 2. You can still use {} for blocks if need be 3. Everyone uses elastic tabstops in their editor oh yeah, and parens are optional for function application

> parens are optional for function application

I think you've gotten confused somehow... Rust++ is a pure concatenative programming language, function application is wholly unnecessary.

Re: Rust's 2017 Roadmap

#243

Post by mamcx »

girvo wrote: post #212
mamcx wrote: post #128

I wish it have a good history for mobile development (iOS, mainly). I think a modern language without a good foot inside the mobile is non-ideal. Also, a nice history for UI native widgets will be a plus. This is ask a lot, I know. Right now I have some projects where the less-worse option is .NET, swift if only iOS+Linux, Delphi is because cost (and free pascal is unfocused). Then obviously C++, but that is where I…

If you like Delphi/Pascal, have you seen Nim?

Some year(s ?) ago I look at it. Seem nice. Don't clear if is good (enough) for mobile/UI. Need to recheck...

Re: Rust's 2017 Roadmap

#244

Post by dbaupp »

curun1r wrote: post #228
dbaupp wrote: post #73

Earlier quoted context omitted.

Why couldn't Rust's developers write "Rust for Dummies"? I feel like you're connecting dots that aren't actually connected. Obviously having more books from different authors/perspectives is great for Rust, but I don't see, prima facie, why a non-Rust-developer author would do a better job of "Rust for Dummies" than a Rust developer. For one, I would be surprised if a non-"expert" (which is, I presume, why you're so…

It's probably a "forrest for the trees" problem...the developers of a language will have their perspective colored by low-level implementation details. As an example, I found the explanation of trait objects incredibly confusing when I read the book. They confused the subject by immediately talking about static vs dynamic dispatch of functions, which is really an implementation detail and performance consequence of u…

The Rust team is lucky enough to have a dedicated person (Steve Klabnik) writing documentation and teaching, who, as previously mentioned, gets to see a lot of the ways in which people struggle to learn Rust and practice different approaches for teaching it. For the most part, the dark corners of the language implementation are filtered from the compiler hackers, through Steve and his experience, into the actual user-facing documentation.

I think the specific case you mention was a problem more caused by a desire to have some documentation for 1.0, even if it isn't perfect, rather than just leaving the feature undocumented. That page is originally[1] based on a blog post[2] that is targeting people who want to know how they work internally, and there wasn't much time before 1.0 for feedback, revision and iteration of it (there was one cycle, which improved it in the direction you want, but more is always better). The second edition[3] doesn't have the 1.0 crunch date, and benefits a lot from feedback on the existing teaching material (like yours here) and the extra experience the team has had teaching Rust, so, by all reports, does a much better job. (It doesn't seem to currently have anything about trait objects, but I'm sure it will soon.)

[1]: https://github.com/rust-lang/rust/commit/dbccd70a5736fd2e898...

[2]: http://huonw.github.io/blog/2015/01/peeking-inside-trait-obj...

[3]: http://rust-lang.github.io/book/

Re: Rust's 2017 Roadmap

#245

Post by steveklabnik »

general_pizza wrote: post #241
ainar-g wrote: post #26

Does the "lower learning curve" goal include the lowering of learning curve for people who already know how to program? Because right now, the Book sometimes seems like it's aimed for people who either didn't program a lot, or didn't program in a language with types. What I actually would like is a few "Books" like "Rust for C++ people", "Rust for Go people", etc. Those would describe in many examples how things that…

Interesting. Out of curiosity, what's a case where tmp = a.b(); tmp.c() works but a.b().c() doesn't? I'm still learning rust and the online book's Methods chapter doesn't say anything about such restrictions.

It happens if b() returns an owned value that c() returns a reference to. In that case,

  a.b().c()
b here is temporary, and so is freed at the end of the line, making the return of c dangling

  let temp = a.b();
  temp.c();
Now that the return of b() is not temporary, it will last to the end of the scope and so c is fine.

Re: Rust's 2017 Roadmap

#246

Post by steveklabnik »

dbaupp wrote: post #244
curun1r wrote: post #228

Earlier quoted context omitted.

It's probably a "forrest for the trees" problem...the developers of a language will have their perspective colored by low-level implementation details. As an example, I found the explanation of trait objects incredibly confusing when I read the book. They confused the subject by immediately talking about static vs dynamic dispatch of functions, which is really an implementation detail and performance consequence of u…

The Rust team is lucky enough to have a dedicated person (Steve Klabnik) writing documentation and teaching, who, as previously mentioned, gets to see a lot of the ways in which people struggle to learn Rust and practice different approaches for teaching it. For the most part, the dark corners of the language implementation are filtered from the compiler hackers, through Steve and his experience, into the actual user…

Yes, this is true.

(And the second edition will have trait objects in it, it's not there yet though.)

Re: Rust's 2017 Roadmap

#247

Post by cpeterso »

kibwen wrote: post #98
steveklabnik wrote: post #47

Earlier quoted context omitted.

> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sampl…

> I always joke String should have been called StrBuf Agreed, and Vec should just be Buf! Let's fork the language. :)

Why not rename Vec to Buf everywhere with a Vec = Buf type alias for backwards compatibility?

Re: Rust's 2017 Roadmap

#248

Post by cpeterso »

steveklabnik wrote: post #47
ainar-g wrote: post #41

Earlier quoted context omitted.

What about the warts part? Also, as someone who've tried to get into Rust three times now, I've been thinking, have you or anyone from the rust documentation team ever had sessions where you just - take a random C++/Go/Python developer - ask them to solve a not-too-simple but not-too-hard task, something that'll generally take them less than an hour in their "native" language, in Rust - look and take notes on their s…

> What about the warts part? I'm not sure enough time has passed to tell what Rust's warts truly are. I always joke String should have been called StrBuf... I do this, yes. This is one of the reasons I hang out in IRC so often; it's an effective way to collect these kinds of things. More data is always better, and collecting it across multiple venues. I don't think IRC is inherently going to be a representative sampl…

Why not rename String to StrBuf everywhere with a String = StrBuf type alias for backwards compatibility, if this would clarify new users' understanding of String/str?

Re: Rust's 2017 Roadmap

#249

Post by jeffdavis »

lmm wrote: post #198
nostrademons wrote: post #179

Earlier quoted context omitted.

That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market . Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still behold…

Are the with-GC options really that much better? Rust or OCaml's advantages over C++ seem much the same as OCaml's advantages over, say, Java, no?

I don't quite follow the question and/or implication.

Re: Rust's 2017 Roadmap

#250

Post by jeffdavis »

tom_mellior wrote: post #196
nostrademons wrote: post #179

Earlier quoted context omitted.

That may be true, but for programmers that can use GC, there are already very good solutions out there. New products succeed based on how much better they are than the other solutions in their market . Rust's genius is going after the market that can't use GC, which has seen few innovations in programming language design over the last 25 years. (C++11/14/17 has helped this situation immensely, but C++ is still behold…

> Rust's genius is going after the market that can't use GC But the problem with that is that the market that really really can't use GC is vanishingly tiny. Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market. Most developers on most projects aren't. And then Rust implements reference-counted pointers in the library, which is the slowest possible way of…

"But the problem with that is that the market that really really can't use GC is vanishingly tiny."

Even if that's true (which I don't believe), tiny markets have a way of expanding when new offerings are available.

New people are getting involved in OS development in rust, for instance. We might see some really interesting stuff happen there. The same thing may happen with databases and rust.

And you didn't address my example, which was all of those "-devel" packages you need to install to get all of those libraries that so much software depends on: libssl, libjpeg, etc.

"Rust throws the baby out with the bathwater and tries to pressure others into thinking that they are in this market."

And this has what ill effect?

Post reply on HN