Live data from Hacker News

Rust's 2018 roadmap

blog.rust-lang.org

161–170 of 253 posts

Re: Rust's 2018 roadmap

#161
post #85

Earlier quoted context omitted.

I see, but this is still a political issue. Maybe a lot of minorities people just voted "no" in that survey question. Because.. why excluding people based on their skin color is discriminatory, but including people based on their skin color is not discriminatory?

Discrimination, noun: > the unjust or prejudicial treatment of different categories of people, especially on the grounds of race, age, or sex. Is it unjust to make sure people from a minority do not feel alienated?

Is it just to alienate the majority to encourage the minority? A lot of companies promoting "diversity" certainly think so.

Re: Rust's 2018 roadmap

#162
post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

>I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far).

I'm genuinely curious (this is a straightforward question): have you personally gotten applications you've written to compile yet, or are you still learning theoretically?

(I haven't used rust, but have read a few comments about a high learning curve.)

Re: Rust's 2018 roadmap

#163
post #79

I'm an average programmer, but I honestly don't get the goal of inclusiveness [edit: from the Rust 2017 Survey Results] > Diversity and inclusiveness continue to be vital goals for the Rust project at all levels. I mean.. lifetime checks won't stop working if you don't consider yourself heterosexual or anything o.O The two matters simply don't mix in my head

If you're open to learning about why it _actually is_ important, there are some good resources out there to give you a little more context as to the reasons why.

You could read this: http://www.latimes.com/business/technology/la-diversity-righ...

Or maybe if you like listening instead: https://www.gimletmedia.com/reply-all/52-raising-the-bar

So, while it's a nuanced and complicated topic, there are actual reasons why this benefits a project like Rust. Diversity amongst any organization is not only good for society, but objectively the output of the org itself.

Re: Rust's 2018 roadmap

#164
post #149
post #140

Earlier quoted context omitted.

Yes, you should instead make sure everyone doesn't feel alienated, not only the people from a minority regarding their race, age or sex.

That... does seem to be the goal.

No no no, you see, by making minorities safer we must then be making the majority feel less safe! Safety is a zero sum game after all.

Re: Rust's 2018 roadmap

#165

Earlier quoted context omitted.

Can you clarify your meaning? I'm a little confused. It sounds like you say "Rust isn't really a beginner's language... it's probably easier to teach [Rust] as a first language than a second after Python or Java". At first it sounds like a contradiction but when I inspect closer I realise there's alternative interpretations. Do you mean "learning a system's programming language is not helped and may even be hindered…

I think your parent is saying "Rust isn't a great language to learn programming with", that is, if you've never programmed, Rust is not a great choice. I agree, but I don't think it's inherent; I think it's a lack of resources targeted at this demographic.

I do think a lot of it is inherent in the design choices that Rust has made. Rust, as a language, has a fairly large surface area. There's a lot of different syntactical and conceptual lessons that need to be learned by new Rust programmers.

Compare that to, say, Lisp. My first programming class at Berkeley was taught in Scheme, which is basically Lisp. Within the first 20 minutes of the first day, the professor had not only gone over a bunch of introductory announcements, but he'd also introduced us to every bit of syntax we would learn in the course. The second lecture covered car/cdr and recursion. Beyond those two lessons, everything we learned was about the practice of programming, not the language we were programming in.

Rust occupies a fairly unique position of being high level, with lots of abstractions to make experienced programmers more productive, and low level with fairly precise control over lower-level hardware concerns. That's really impressive, but I do believe that impressive power comes at the cost of an unavoidable learning curve. You'll never get a backhoe to be as simple to operate as a shovel. Which isn't to say that there isn't ample opportunity for the work that you and Carol are doing to make learning Rust easier--beginners now have it much easier than people like me that jumped in around 0.8. But it is to say that I don't think it's possible to ever make Rust as easy to learn as conceptually simpler languages.

If I were designing a CS curriculum, I'd start new students with a Lisp dialect, then move on to Assembly (which, while hard, provides what is, to me, an essential view of the actual hardware that you're using) and then move on to the more practical languages. I'd still like to teach Rust, but it would come later to help introduce advanced concepts like compilers and operating systems.

Re: Rust's 2018 roadmap

#166
post #65

I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). As someone not only new to Rust but also systems programming in general I especially appreciate that the chapters include actual reasoning about why things are how they are in Rust and that they seem pretty open abou…

>I started learning Rust over the weekends and I think the second edition "The Rust Programming Language" is among the best introductory books on a programming language I have read (well half way so far). I'm genuinely curious (this is a straightforward question): have you personally gotten applications you've written to compile yet, or are you still learning theoretically? (I haven't used rust, but have read a few c…

Depends what you mean by application. So far I only worked on simple exercises and translated some algorithms I have previously written in Python. Compiling them is fairly easy since the compiler output is very helpful and IDE integration is quite good for still being new. Main painpoint is, that I haven't managed to get the debugger work yet.

Rust does have a high learning curve but to me it seems justified by its goals, the domains it targets and using some concepts that are unique or not the most common. Still I'm fairly confident I would get a simple CRUD web app out in a day if that's what I wanted. Learning curve is not crazy high, just higher than the usual high level languages.

My background is mostly in Python/js web development, but I'm currently learning dsp for audio processing and synthesis. And since language doesn't really matter at my current level I alternately implement things in Python, puredata, C++ and Rust. So I won't be implementing full fledged applications for quite a while :)

Re: Rust's 2018 roadmap

#167
post #12

Earlier quoted context omitted.

Each module has to have it's own GC. In my experience, it's been easier to integrate two languages that have GC (JavaScript and Go) than two languages where only one is GC'd (JavaScript and Rust). What will the interop with Rust and JavaScript look like? How will pointers be managed?

It's not at all easier to interoperate two separate GC'd languages unless you have one garbage collector to manage them both . Web Assembly does not provide the hooks necessary to integrate GC, and JavaScript does not provide critical features, such as finalizers, that are necessary to do things like break cross-language cycles. Absent that support, manual memory management of DOM objects is necessary, and Rust is go…

For specific needs I have occasionally made my Go struct constructors (NewFoobar() *Foobar) use malloc ported to Go + mmap to allocate memory and said structs have a .Close() method (think defer foobar.Close()). It worked fine... This is a fine solution/compromise, in 95+% of development solutions you don't want your devs wasting their time managing memory manually, and in the worse cases they will get it wrong.

Re: Rust's 2018 roadmap

#168
post #85

Earlier quoted context omitted.

It's less about goals of the technical project, and more about goals of the organization. Rust the language is written by people, The Rust Team, most of whom I'd imagine are volunteers. In order to guarantee the life of the project, its important for potential contributors to not only feel comfortable using the language and writing code, but also feel comfortable in discussing the future potential features and use ca…

I see, but this is still a political issue. Maybe a lot of minorities people just voted "no" in that survey question. Because.. why excluding people based on their skin color is discriminatory, but including people based on their skin color is not discriminatory?

There is a difference between "including" and "not excluding" people based on color or whatever. It's (officially, anyway) about removing barriers, not roping people in. I'll grant in practice it's a blurry line.

So, yeah, it's a political issue, but an open source project is necessarily a political entity by virtue of being made of people. You can't escape making political decisions, and since "inclusivity" mostly just means being nice to people, I can't complain much.

Re: Rust's 2018 roadmap

#169
Some honest criticism.

I'm not a guru, but I've used a fair bit of F# and modern C++ in a commercial setting, so a lot of things in rust weren't too surprising. I learned about the different kinds of strings (they make sense, even if they're poorly named). I learned the strict borrowing rules. I learned the strict mutability rules.

But try as I might, I can't bring myself to care about the difference between the ~190 different types of iterator[0].

I think I should just be able to use a Iterator trait, but I can't get any of those concrete instances to match up. It very much triggers my "I don't care reflex" in a way the other stumbling blocks really didn't.

[0] https://doc.rust-lang.org/core/?search=Iter

Re: Rust's 2018 roadmap

#170

Some honest criticism. I'm not a guru, but I've used a fair bit of F# and modern C++ in a commercial setting, so a lot of things in rust weren't too surprising. I learned about the different kinds of strings (they make sense, even if they're poorly named). I learned the strict borrowing rules. I learned the strict mutability rules. But try as I might, I can't bring myself to care about the difference between the ~190…

All those iterator types are exactly the same as C++ having std::vector::iterator, std::vector::const_iterator, std::deque::iterator, ..., and exist for similar reasons: mostly zero-overhead abstractions. (This is even more visible in the range proposals for C++.)

Using concrete types for every adaptor means all the steps in a iterator transformation pipeline are statically known and (importantly) obvious to the compiler, and thus is highly amenable to inlining/optimisation to get it down to something close to a plain 'for' loop. If you're willing to forgo that performance, it's possible to just put everything behind a pointer/virtual call with a Box>, which ends up more similar to sequences in F# etc.

It does seem as if the motivation for this design isn't discussed in the documentation.

Post reply on HN