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

Rust 2019 and beyond: limits to some growth

graydon2.dreamwidth.org

Post reply on HN
Print view View original

221–230 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#221

Post by pjmlp »

lifthrasiir wrote: post #166
Ar-Curunir wrote: post #122

Earlier quoted context omitted.

I don't think this is true: what C leaves out in terms of language features , programmers have to reinvent or keep in their heads perpetually while writing code, leading to tons of gotchas.

In the other words, C standard library is not really small. It consists of a small mechanized portion and a much larger portion embedded in wetware , i.e. human mind. The second portion is very hard to update or fix, so the first portion keeps growing to cover all faults of the second.

And POSIX plays the role of an additional runtime library.

Re: Rust 2019 and beyond: limits to some growth

#222

Post by pjmlp »

shaklee3 wrote: post #115
pantalaimon wrote: post #76

Earlier quoted context omitted.

I think the fear of unrefined behaviour is starkly exaggerated in everyday C programming. If you follow the established best practices (and the compiler will warn you if you don't) you will not experience undefined behaviour. > Those kinds of complexities aren't generally something for users to explicitly learn in rote memorization to use the language - if Rust introduced overloading and default arguments all those w…

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.

The continuous growth of CVE entries shows otherwise.

Re: Rust 2019 and beyond: limits to some growth

#223

Post by adrianN »

pjmlp wrote: post #218
adrianN wrote: post #168

Earlier quoted context omitted.

Wanting to do what the new languages can do without breaking backwards compatibility is a big reason why C++ got so complicated. C++98 isn't all that complex, but if you want to learn C++20 you still have to learn every language feature that was developed in the last thirty years and how they all interact.

Just like wanting to learn Python 3.7 means learning about 500 PEPs and how they interact across each Python release (major.minor, during the last 25 years and alternatives to CPython.

Well Python 3 broke compatibility so you don't have to start at Python 0.1 alpha, but yes, completely understanding Python is also no easy task. I write Python almost every day and have taught courses using it, but I know of features that I don't understand. There are probably more that I'm not even aware of.

Re: Rust 2019 and beyond: limits to some growth

#224

Post by steveklabnik »

lambda wrote: post #195
steveklabnik wrote: post #186

Earlier quoted context omitted.

> 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.

Yes, that's why I included the second part, "or the Book provides at least an introduction to the topic and then a reference to the more detailed information in the Reference." 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 referenc…

Yeah, I'm not sure either. Maybe an RFC or internals discussion.

Thanks for caring about this <3

Re: Rust 2019 and beyond: limits to some growth

#225

Post by steveklabnik »

mwcampbell wrote: post #219
steveklabnik wrote: post #200

Earlier quoted context omitted.

The documentation is distributed locally, as static files, as well as being available on doc.rust-lang.org. This is considered a big feature. 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 :/

Here's one way you might be able to make the case: If you require a web server even locally, then the docs can be installed as a single file (zip archive, SQLite database, etc.). This would eliminate the overhead of lots of small files on at least one popular desktop OS, speeding up installation and updates.

This is already an active discussion, yep. We'll see...

Re: Rust 2019 and beyond: limits to some growth

#226

Post by dbaupp »

Ericson2314 wrote: post #206
dbaupp wrote: post #151

Earlier quoted context omitted.

"User" refers to someone writing code in the programming language---someone "using" the compiler. It's not some project-management-y jargon. ----- Extending expressiveness vs sugar is fundamentally a property of the high level language, not the mid-level IR. It happens that talking about a mid-level IR is sometimes a nice way to "prove" that something is new or sugar. As the parent said, the programmer using the comp…

- New program writers (more writing) - Old program maintainers (more reading) - Language implementers You leave out the 3rd and conflate the second. Others have conceive of PLs as some sort of bargain between human and machine, or human and pure math. Either way, there's multiple interests at stake. Or, even simpler, what if Rust becomes way harder to learn, but mastery gives one correspondingly way more productivity…

Language implementors are a very special case. Their effort is O(1) while the other two are O(amount of code in the language). In any case, I don't see what your point is.

---

I think you're conflating things too: NLL is defined in terms of a CFG, which happens to be MIR at the moment, but if the current MIR is insufficient for some task, it can still be fundamentally changed, with the NLL semantics handled specially, e.g. with a multi-step lowering, like HIR in Rustc.

The mid-level IRs chosen for a compiler are in service of the high-level language and its tools (like formal/static analysis), not the other way around.

In fact, a static analysis or formal reasoning tool likely needs more information than fits into a compiler/optimisation-focused IR. (You see this even with LLVM IR vs MIR and SIL etc: LLVM IR can't hold enough info for the front-end to do everything.)

Re: Rust 2019 and beyond: limits to some growth

#227

Post by klodolph »

adrianN wrote: post #168
klodolph wrote: post #116

Earlier quoted context omitted.

I don’t think Java and Go will ever, combined, reach the complexity of C++. The reason why older languages are complex and inelegant is because our understanding of how to create simple yet useful languages has increased, not because older languages accumulate much complexity.

Wanting to do what the new languages can do without breaking backwards compatibility is a big reason why C++ got so complicated. C++98 isn't all that complex, but if you want to learn C++20 you still have to learn every language feature that was developed in the last thirty years and how they all interact.

I would disagree with the claim that “C++98 isn’t all that complex.” It was so complex that any project I found using it would restrict itself to some arbitrary subset, just to keep complexity under control. Java has gone through years of backwards-compatible changes, and is still wonderfully simple compared to early versions of C++. C++ started with a mess of different features and hasn’t really gotten worse. If anything, C++11 is simpler than C++98 from a user’s perspective, even though it’s not from an implementer’s perspective.

One of the big differences is that Java and Go have straightforward context-free grammars, mostly, and you can whip up a working parser in no time. C++ is a bit of a beast, by comparison (hence keywords like “typename”).

C++ also has the complex overloads and template system. I think people underestimate how complex these things are when they are learning C++, and how complex their interactions are. Then there’s the preprocessor.

You can kind of argue that these are just an accumulation of changes, but other languages contemporary with C and C++ do not suffer from these complexities, so the argument falls flat. By comparison, Go and Java rely on reflection or code generation more, and these are a bit simpler.

Re: Rust 2019 and beyond: limits to some growth

#228

Post by fhrow4484 »

steveklabnik wrote: post #179
laszlokorte wrote: post #177

Earlier quoted context omitted.

It's also confusing that there are: 1. A first edition that is marked as outdated [1] 2. A second editions that seems to be not outdated [2] but 3. also the book without any edition marker that differs from the second edition [3] 4. As well as the second edition for various rust versions (eg [4] or [5]) And all of them are only distinguishable via the url. I guess the book without any version or edition marker [3] is…

As of Rust 1.31, there's only one version of the book, doc.rust-lang.org/book Here's a short history: I wrote the first edition myself, before Rust 1.0. Then, Carol and I started a re-write. When it was ready to be published, we cut the final draft as the "second edition", and forked off new work in what was called the "2018 edition". That's why they're so similar. However, for various reasons, this situation isn't i…

Thanks for chiming in here and giving more context. I agree with other commenters about the potential confusion for beginners. The tour of rust in 30 min should probably do an automatic redirect to the doc.rust-lang.org/book

I'd love it if there was something interactive like the golang tour but the book is already a great resource. Thanks for writing it

Re: Rust 2019 and beyond: limits to some growth

#229

Post by steveklabnik »

fhrow4484 wrote: post #228
steveklabnik wrote: post #179

Earlier quoted context omitted.

As of Rust 1.31, there's only one version of the book, doc.rust-lang.org/book Here's a short history: I wrote the first edition myself, before Rust 1.0. Then, Carol and I started a re-write. When it was ready to be published, we cut the final draft as the "second edition", and forked off new work in what was called the "2018 edition". That's why they're so similar. However, for various reasons, this situation isn't i…

Thanks for chiming in here and giving more context. I agree with other commenters about the potential confusion for beginners. The tour of rust in 30 min should probably do an automatic redirect to the doc.rust-lang.org/book I'd love it if there was something interactive like the golang tour but the book is already a great resource. Thanks for writing it

You’re welcome!

That’s “Rust by example”, by the way.

Re: Rust 2019 and beyond: limits to some growth

#230

Post by lambda »

skybrian wrote: post #216
lambda wrote: post #195

Earlier quoted context omitted.

Yes, that's why I included the second part, "or the Book provides at least an introduction to the topic and then a reference to the more detailed information in the Reference." 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 referenc…

Compare with Go's language spec, which is written in a formal (but readable) style with little math. I wouldn't want it to have examples because it's good that it's concise. One way to start might be to have an official extended cheat sheet. A cheat sheet needn't explain everything, but it should list every language feature available. The idea is to give you a definitive "inventory" of everything available so you can…

Thanks for the reference to the Go spec (link for the lazy: https://golang.org/ref/spec)

It is actually fairly comparable to the Rust Reference (https://doc.rust-lang.org/reference/introduction.html), though the way the Rust Reference is divided into chapters makes it a bit hard to see everything at once or search.

They both do contain some examples, as well as things like the syntax in a BNF like format.

Perhaps what I'm looking for is just to have the Rust Reference made a bit more complete and a little more accessible in format (the division into chapters doesn't really seem to help much), as well as improving the SEO since it doesn't show up in Google searches often.

Post reply on HN