Earlier quoted context omitted.
Let’s revisit this when Rust has... - the number of users - the amount of mission-critical legacy code that has to compile - the number of compiler vendors - age ... comparable to C++’s.
According to that we should all be using COBOL Did you hear they’re finally making it object oriented? The name will be ADD ONE TO COBOL
Rust 2019 and beyond: limits to some growth
191–200 of 237 posts
Re: Rust 2019 and beyond: limits to some growth
#192Since when did you need to read, comprehend, and digest every language feature in Rust to ever use the language? The absence of HKT / GATs / overloading / default arguments from the language doesn't make it easier for a newbie to learn. These aren't topics someone new, or even intermediate, should ever be touching until they need them. And in the absence of having this functionality (example - we JUST got const fn th…
Yes this hole thread makes me think we have a bunch of people who think complexity = initial learning curve. No wonder most of our industry is an inscrutable inconsistent mess.
Once, long ago, there was a new programming language. It was lean and mean. Partly to keep codebases understandable to all, and to make the language easy to learn and straightforward, it eschewed both having too many features, and having any feature that was too abstruse. People marvelled that the whole language, standard library and all, could fit in a nutshell. The name of the language was Java. The end.
Re: Rust 2019 and beyond: limits to some growth
#193Earlier quoted context omitted.
There are only two types of languages, those that are too complex and those that aren't yet.
There is at least one language that evolves in the opposite direction. The philosophy of Oberon is that "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
So whatever Wirth has done was quite of interesting in terms of language research for the language geeks among us, but hardly with any market relevance.
Re: Rust 2019 and beyond: limits to some growth
#194Earlier quoted context omitted.
> Especially the bit about 'negative space' got my intention, that's one tool I'm going to put in my toolbox to re-use. One of the most profoundly useful things I've ever realized in my life is that the most important choices are often about deciding what not to do. Creativity is deeply wedded to the idea of constraints and pragmatically, there are only so many hours in the day. Deliberately deciding to not investing…
I see the value of deciding what not to do for version(s) X of something , but ruling something out for all eternity seems a little... short-sighted? Who's to say that what you're ruling out won't become the next big concern for everyone and your technology won't be the odd one out without it?
In practice (and with some experience) most decisions do not prevent revisiting them later.
Re: Rust 2019 and beyond: limits to some growth
#195Earlier quoted context omitted.
I'd say that most of these are language features. The only that are mostly library features are operator overloading and simd, but they both have associated language features supporting them. I agree that completeness is hard, but I feel like it could be a bit easier if there were some consolidation of the material. At the very least, make sure that everything covered in the 2018 edition guide is also covered in the…
> I'd also make sure that everything covered in the Reference is covered in the Book, They have very different goals, so this will never happen. The Book's job is to teach you how to program in Rust. The referece's goal is to (eventually) be a full specification. The former must be a sub-set of the latter. I do agree that everything should be documented, but the book cannot cover every last possible thing.
For example, I don't think that every last detail of #[repr(...)] needs to be covered in the Book; but as the entry point for most people, it's how they discover features, so it should at least provide an introduction, and link to the reference for more information.
Likewise, while I think that the std::ops documentation does a good job of covering all of the details of operator overloading, I think the Book could provide a slightly more discoverable introduction to operator overloading which isn't just being used as an example of another feature, default generic type parameters, and provide some links to std::ops which might help with the Googleability problem.
One thing that I think really needs to be focused on is some SEO for the docs. For some reason, the way the Rust docs have been organized over the years, with old versions of docs and the old book being replaced by the new one, means that a lot of times, when I search for something I find old, out of date docs.
For instance, with operator overloading, if I search for "rust operator overloading", I find Rust by Example, which is OK but has a lot of text in comments which is harder to read, followed by a first edition link which warns about being out of date and then provides a link to the new book but not where in it to look, as well as a link to the 1.30.0 version of the first edition book, then a link to std::ops (which if I were a newcomer, I might not realize was relevant), then a 1.5.0 edition of the book.
The first edition operator overloading chapter seems pretty reasonable, actually, and it's present in the table of contents so its more discoverable, and it contains a link to `std::ops`. But because of the new structure of the second edition book, the first page I see if I try to check the book tells me that it's outdated, and directs me to the new book in which this material is harder to find.
And in the new book, even once I find it, there's not much to direct me to where to learn more about the topic. There's no link to `std::ops` documentation; I have to separately look that up.
Part of the problem was that the first edition book was a bit more like a more accessible reference, while the second edition has a more narrative or tutorial structure. So there's no longer a place to go for an accessible reference to all of the language features. There's the Reference, but that's written for detail and precision and not accessibility, and as discussed, is incomplete. There's Rust by Example, but that's mostly just code examples with commentary in comments. The second edition book covers a lot of the same material as the first edition, but because of the different structure, some of the "reference information" on more advanced features is just buried in a couple of "Advanced X" chapters.
I'm not sure of the best way to address this; I admit that getting this right isn't easy.
One option might be to have the new book be in two halves; one of which was the narrative/tutorial portion; chapters 1 through 18, and 20, perhaps, though they might be able to be slimmed down a bit and some material moved to the second portion. The other half which is more of an "accessible reference" for advanced features; the material in chapter 19, but expanded a bit and with more discoverable per-topic chapters like the "Syntax and Semantics" section of the first book, plus the Nomicon material, and any of the topics which are missing.
Or, alternatively, just expanding on and integrating the "advanced X" material, Nomicon, and missing topics into the overall structure of the book.
Or another option would be to have the Book just be the Book focusing on the main narrative/tutorial introduction to the most common features, and have a Reference in two portions; one longer one which covers every major feature but in an accessible style with examples, followed by a more formal appendix covering each last little detail.
I guess ultimately what I'm saying (sorry for taking so long and so many diversions to say it, but as you point out, it is hard to get this right, and I've been thinking about what I'd be looking for as I write), is that there should be some place that has an "accessible reference" to all major features which is organized somewhat like the "syntax and semantics" section of the first edition book. The second edition book, chapters 1 through 18, is definitely a better organization as a book than the first edition, but that structure doesn't lend itself well to covering every feature, and as you point out, you wouldn't want it to.
But the Reference also isn't a friendly place to point people, both because of the "incomplete" warnings but also because it's written in a more formal style.
And the fragmentation into the Book, Nomicon, Rust by Example, stdlib docs, 2018 Edition Guide, Cookbook, Reference, Cargo Guide, Unstable Book, along with some of the reorgs along the way, can sometimes make it a bit hard to figure out the right place to look. I feel like there should be one document somewhere that has a reasonable accessible introduction, with examples, to every feature, in addition to the more formal and succinct Reference.
Maybe I should put my money where my mouth is and try to compile something like what I mean. It would help to have a little bit of buy in from docs team leadership, though, so that there would be a hope of it getting merged and maintained. Perhaps a docs RFC would be appropriate?
Re: Rust 2019 and beyond: limits to some growth
#196Earlier quoted context omitted.
This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/c…
It's been a while since I watched this but my current thoughts on "Growing a language" is that I fear it is an unhelpful simplification of what makes language design hard. IMHO language design is a holistic design problem that needs global optimisation. You cannot incrementally hill-climb yourself anywhere useful when you can't backtrack over past decisions. It is like designing a workshop. You only have so much spac…
This is an interesting observation that reminds me of
> In Lisp, you don't just write your program down toward the language, you also build the language up toward your program.
from Paul Graham's "Programming Bottom-Up". Some people would consider it an advantage being allowed to fold the "design a language problem" into the overall problem.
More, I think this is just a matter of degree, not kind.
As soon as you have something as apparently simple as named procedures, you're really writing a DSL, albeit very coarsely, for your business problem. Add named record types. Add textual macros. Add operator overloading. Add Lisp-style macros. At every point where the language allows a word on the screen to stand in for something larger, you're giving the programmer the power to design a language for their problem domain.
Re: Rust 2019 and beyond: limits to some growth
#197Earlier quoted context omitted.
Rust will never be older than C++ since they both get one year older every year ;)
Interpreting GP's comment using the Principle of Charity[1], I assume GP meant "older than C++ is now". [1]: https://en.wikipedia.org/wiki/Principle_of_charity
Re: Rust 2019 and beyond: limits to some growth
#198Earlier quoted context omitted.
I agree. I see comments like that time and time again. As someone who writes it professionally, it just doesn't occur as often as the internet would make you think.
You think this until you're on the front line exposed as attack surface directly or indirectly via linkage. This is a knowledge category where ignorance really does give people unfounded confidence.
Re: Rust 2019 and beyond: limits to some growth
#199Earlier quoted context omitted.
I'd also like to mention that getting to the documentation for anything with Rust is fairly annoying, mostly because a ton of the stuff in the book links to the first edition and getting from the first edition to the current one is really cumbersome. It'd be great if you would be redirected from the old book to the latest version instead of getting to it and only get a warning that it isn't the latest version. Especi…
Can you please file bugs when you see this? I'd be happy to update them to point in the right place. We have some constraints that make plain redirects really hard; we cannot run a web server or use a ton of JavaScript, for example. Maybe this situation is painful enough for community consensus to change...
Just curious, why are those constraints there?
Re: Rust 2019 and beyond: limits to some growth
#200Earlier quoted context omitted.
Can you please file bugs when you see this? I'd be happy to update them to point in the right place. We have some constraints that make plain redirects really hard; we cannot run a web server or use a ton of JavaScript, for example. Maybe this situation is painful enough for community consensus to change...
> we cannot run a web server or use a ton of JavaScript Just curious, why are those constraints there?
I personally would love to tell people "sorry, you have to run a basic web server, even locally" for a few reasons, but it doesn't feel socially viable at the moment, sadly :/