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

Rust's 2018 roadmap

blog.rust-lang.org

Post reply on HN
Print view View original

241–250 of 253 posts

Re: Rust's 2018 roadmap

#241

Post by curun1r »

steveklabnik wrote: post #187
curun1r wrote: post #165

Earlier quoted context omitted.

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…

> Compare that to, say, Lisp. This makes me think of the module reform RFC: > In other words, while there are simple and consistent rules defining the module system, their consequences can feel inconsistent, counterintuitive and mysterious. See also Rich Hickey's "simple made easy." I do think Rust has some inherent learning curve, but I also don't necessarily agree with this framing. Simpler languages aren't always…

> Simpler languages aren't always simpler to actually write software in.

I completely agree with this. But when you're learning to program, the goal isn't to write software. It's to learn the lessons and concepts that will one day allow you to write software.

Re: Rust's 2018 roadmap

#242

Post by logicallee »

smoe wrote: post #224
logicallee wrote: post #184

Earlier quoted context omitted.

Thanks for the straightforward answer, and the clarifications too. Starting at the end, a DSP is definitely what I mean by "application" (the reason I used the word 'application' is to exclude a straightforward 'hello world' copied from the exercise book.) For example, have you gotten any audio processing application to work ta you've written, or anything like that? I'm surprised you mention CRUD web apps, as I didn'…

I mentioned CRUD web apps because first, I get the feeling that at least a bunch of the comments talking about high learning curve of Rust are from web developers expecting as fast an on-boarding as say in Python, Node.js or Go and more importantly because I'm a web developer myself with a lot of domain knowledge -- building a simple crud web app (or in Rust context more api) is going to be fairly easy to me in prett…

Thanks - this was very interesting. Bearing in mind that I only went on what I've heard anecdotally (never tried rust), I was frankly surprised that as someone who has domain experience in web development (in what I thought were "easier" languages) you did not feel frustration at Rust "on-boarding". So you definitely countered what I thought.

Re: Rust's 2018 roadmap

#243

Post by shaklee3 »

steveklabnik wrote: post #41
gandreani wrote: post #33

Lots of nice language improvements lined up for this year I haven't played with Rust but I like the ecosystem and transparency. Something that stands out is the Compatibility across editions section. Seems like they really thought this through: > you can be on a different edition from your dependencies. > Edition-related warnings...must be easily fixable via an automated migration tool (rustfix). Only a small minorit…

Glad to hear your enthusiasm! > might not finish in time for the year or will be sub-par. Yeah, these areas of focus are where we think we can make substantial improvements, but it may be something like how the webs services goal: last year we shipped fundamentals, this year we're shipping end-to-end awesomeness. So we may only get the fundamentals in place for this year, and maybe we'll need to focus on it next year…

Not sure if you'll see this, but I really appreciate all the time you spend on here and other places answering questions. It makes a huge difference in getting people interested.

Re: Rust's 2018 roadmap

#244

Post by steveklabnik »

shaklee3 wrote: post #243
steveklabnik wrote: post #41

Earlier quoted context omitted.

Glad to hear your enthusiasm! > might not finish in time for the year or will be sub-par. Yeah, these areas of focus are where we think we can make substantial improvements, but it may be something like how the webs services goal: last year we shipped fundamentals, this year we're shipping end-to-end awesomeness. So we may only get the fundamentals in place for this year, and maybe we'll need to focus on it next year…

Not sure if you'll see this, but I really appreciate all the time you spend on here and other places answering questions. It makes a huge difference in getting people interested.

Thank you! I'm glad it's helpful.

Re: Rust's 2018 roadmap

#245

Post by steveklabnik »

curun1r wrote: post #241
steveklabnik wrote: post #187

Earlier quoted context omitted.

> Compare that to, say, Lisp. This makes me think of the module reform RFC: > In other words, while there are simple and consistent rules defining the module system, their consequences can feel inconsistent, counterintuitive and mysterious. See also Rich Hickey's "simple made easy." I do think Rust has some inherent learning curve, but I also don't necessarily agree with this framing. Simpler languages aren't always…

> Simpler languages aren't always simpler to actually write software in. I completely agree with this. But when you're learning to program, the goal isn't to write software. It's to learn the lessons and concepts that will one day allow you to write software.

This is probably where we disagree. The style you're advocating is "bottom-up" learning, that is, you learn the fundamentals, and then build from there. This is totally valid, but in my general experience of years of teaching, both professionally, and as a hobby, most people don't learn like that. I personally learn like that, so it's a bit frustrating to me that this is true!

Most people want to start "top-down", that is, write something useful. After they've got things working, then they want to "dive deeper" and go back down and learn the fundamentals. It's an spiral, not a direct path.

Another way to think about this is that bottom-up learning is the same spiral, but at a different level of abstraction. You're teaching software, but not hardware. You don't force people to learn about OSes before they learn about software. You don't force people to learn about hardware before they learn about software. You don't force people to learn about physics before they learn about hardware.

Re: Rust's 2018 roadmap

#246

Post by steveklabnik »

logicallee wrote: post #242
smoe wrote: post #224

Earlier quoted context omitted.

I mentioned CRUD web apps because first, I get the feeling that at least a bunch of the comments talking about high learning curve of Rust are from web developers expecting as fast an on-boarding as say in Python, Node.js or Go and more importantly because I'm a web developer myself with a lot of domain knowledge -- building a simple crud web app (or in Rust context more api) is going to be fairly easy to me in prett…

Thanks - this was very interesting. Bearing in mind that I only went on what I've heard anecdotally (never tried rust), I was frankly surprised that as someone who has domain experience in web development (in what I thought were "easier" languages) you did not feel frustration at Rust "on-boarding". So you definitely countered what I thought.

I recently was at a two-day university hackathon. The students had never done Rust before. They learned Rust on the first day, and on the second day, built a website, with admin login stuff, etc.

Different people find different things hard.

Re: Rust's 2018 roadmap

#247

Post by smoe »

steveklabnik wrote: post #245
curun1r wrote: post #241

Earlier quoted context omitted.

> Simpler languages aren't always simpler to actually write software in. I completely agree with this. But when you're learning to program, the goal isn't to write software. It's to learn the lessons and concepts that will one day allow you to write software.

This is probably where we disagree. The style you're advocating is "bottom-up" learning, that is, you learn the fundamentals, and then build from there. This is totally valid, but in my general experience of years of teaching, both professionally, and as a hobby, most people don't learn like that. I personally learn like that, so it's a bit frustrating to me that this is true! Most people want to start "top-down", th…

Do you think this depends on the peoples prior experience level whether they prefer either way? Or is mostly personal?

At least in my case I remember when I had C as a first language in school about 14 years ago, after an initial rush of joy, I got a bit frustrated because I couldn't build anything "cool" and practical quickly. I was relieved when we went on to the much more practical seeming Java. But these days I have all the tools I need to get stuff done quickly and prefer learning new things more bottom-up. In fact top-down often annoys me, because it presumes what I might find useful.

I think a mixed approach as often used when teaching musical instruments could work well. For example justin guitar online course splits up the practice sessions in parts that are tedious muscle-memory/rhythm training you have to push trough and parts to teach you songs from various genres as quickly as possible. So you can actually apply and most importantly enjoy what you are learning from week one. Additionally he strongly encourages doing explicit ear training and some music theory from the get go for the long term benefit.

Translated to Rust I think something like rustbyexample.com but instead of splitting it up by language features, have it categorized by domain and experience level would be pretty cool. If I'm interesting in game development I can start right away with simple cli games and later add graphics and if I'm into networked services I choose that path. Both point to the same deeper concepts but like when learning an instrument it is much more encouraging when at any level you can play the types of music you like instead of having to play what the teacher likes.

Re: Rust's 2018 roadmap

#248

Post by setr »

pleasecalllater wrote: post #212
kiriakasis wrote: post #205

Earlier quoted context omitted.

I agree that tools should be better, but i believe that "just use good tools" might not be a viable solution for the parent.

No, there is no justification for bad tools. If someone makes a tool only for ASCII, fine, but don't expect that people will say it's a good tool. Even huge sites have problems when I want to use my real name, or the name of the city I live in. They are usually made by US companies, which is strange, as you have all kinds of people there, with different names. Unfortunately the reality is that those US companies don'…

>supporting unicode is not as hard as it seems, just use from the beginning.

Retrofitting unicode support onto existing programs however is a hard problem

for all unicode-lacking but otherwise well-developed tools, with no sufficiently useful and also unicode supporting alternive, that you'd like to use, whats your proposal?

Go back in time and tell them to use unicode from the start? Reimpliment them yourself? Give up and say no useful tool for me?

There are a hundred reasons certain tooling isn't viable for your usecase; unicode support is rarely even close to being an immediate dealbreaker. Particularly because it can be sufficiently worked around.

Re: Rust's 2018 roadmap

#249

Post by steveklabnik »

smoe wrote: post #247
steveklabnik wrote: post #245

Earlier quoted context omitted.

This is probably where we disagree. The style you're advocating is "bottom-up" learning, that is, you learn the fundamentals, and then build from there. This is totally valid, but in my general experience of years of teaching, both professionally, and as a hobby, most people don't learn like that. I personally learn like that, so it's a bit frustrating to me that this is true! Most people want to start "top-down", th…

Do you think this depends on the peoples prior experience level whether they prefer either way? Or is mostly personal? At least in my case I remember when I had C as a first language in school about 14 years ago, after an initial rush of joy, I got a bit frustrated because I couldn't build anything "cool" and practical quickly. I was relieved when we went on to the much more practical seeming Java. But these days I h…

This is a very interesting question. I'm not sure! Your analogy to music is quite interesting too. I'm going to give this some thought :)

Re: Rust's 2018 roadmap

#250

Post by xudaiqing »

AceJohnny2 wrote: post #93

> Embedded devices I'm excited about this. In my experience, embedded (and by extension, a large part of kernel/driver programming) is the last stronghold of C, because it's a place where you really need fine-grained control of your environment and C gives you that by default. It's my day-to-day workhorse, and I often feel like I'm stuck in the dark ages still dealing with issues of tooling and expressiveness that CS…

Can't agree more! Through i am afraid there hugh work to be done before i can use it at work since i find we are increasingly rely on vendor's sdks to workaround hardware limit and slicon errors
Post reply on HN