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

171–180 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#171

Post by zbentley »

feanaro wrote: post #127
dccoolgai wrote: post #88

Earlier quoted context omitted.

Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time. I was reserving my thoughts about ES6 un…

Can you give an example of the aspect of restructuring you consider confusing?

I'm not GP, but I believe they were referring to the fact that the syntax for destructuring is visually very similar to the syntax for object literals, which makes it easier to make mistakes while reading code in a hurry or as a newcomer to the language.

Re: Rust 2019 and beyond: limits to some growth

#172

Post by zbentley »

qznc wrote: post #152
DannyBee wrote: post #75

Earlier quoted context omitted.

That is not an important facet at all. It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users. No amount of pretending otherwise will change that. No amount of separation will change this. It does not give you any more ability to change the syntax over time, or get it righter. Your users care only about this syntactic interface. In a good world, they do not…

While I generally agree with your point, D/Walter Bright slightly disagrees with the sentiment. One constraint for D is "must not require data flow analysis" because that incurs a cost on compilation time. Afaik this was mostly inspired by Javas definite assignment rule [0]. If fast compilation is a goal, then a language is constrained by implementation and IR aspects. [0] https://docs.oracle.com/javase/specs/jls/se6…

This is a perhaps over-fine semantic distinction, but I would argue that there's a qualitative difference between IR/language implementation and compilation speed. The former should not drive the language's features; the latter is a language feature.

Re: Rust 2019 and beyond: limits to some growth

#173

Post by dan00 »

oscargrouch wrote: post #106
cageface wrote: post #54

Earlier quoted context omitted.

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-…

I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end. C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and yo…

> Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable.

For existing software it certainly is less about rewriting it but extending it in Rust.

Thanks to not having a runtime and being quite easy to create a shared library with a C-ABI, pretty much any software written in any language could be extended with code written in Rust.

Re: Rust 2019 and beyond: limits to some growth

#174

Post by zbentley »

Ericson2314 wrote: post #78
jarjoura wrote: post #71

Earlier quoted context omitted.

At the end of the day, we're all just writing syntactic sugar over assembly that a very complex state machine has to execute.

No (safe) Rust is safe, while arbitrary assembly is unsafe. "Sugar" where the difference between the range (of elaboration) and codomain is significant is not sugar. If we had an assembly+proofs language and a compiler from Rust to it, then I would agree. See CakeML for an example of research towards correctness-proof-preserving compilation.

I think you are using a different definition of "safe" than Rust folks use.

Re: Rust 2019 and beyond: limits to some growth

#175

Post by dccoolgai »

feanaro wrote: post #127
dccoolgai wrote: post #88

Earlier quoted context omitted.

Yeah, it definitely feels like ES6/7/Next is packed with features that theoretically make it a little faster to write code while making it monstrously slower and harder to read for at least 80% of practitioners... (destructuring comes to mind, with a syntax that is bafflingly similar to literal decs, that used to be the "good part") Seems like they made that choice every time. I was reserving my thoughts about ES6 un…

Can you give an example of the aspect of restructuring you consider confusing?

"Confusing" is perhaps too harsh (although destructuring over several levels can be terribly confounding). By "hard to read" I mean primarily the fact that when you are "scanning" code, destructuring statements are syntactically way too similar to literal declarations. It severely degrades, IMHO, the speed with which you can effectively "scan" code in JS. It's not really that you _can't_ understand it when you slow down and analyze - it's that you _have to_ slow down to see the difference between "let a = [0,1]" and "let [,a] = [0,1]". Whereas in ES5, whenever you saw the brackets you could know without reading into the code there was an object or array being declared.

That's not to say that I think destructuring is all bad - it certainly saves lines of code - but aftet working with it for a few years, I would gladly trade it back for more scannable code, easier syntax for beginners, etc.

Re: Rust 2019 and beyond: limits to some growth

#176

Post by phaylon »

skybrian wrote: post #11

As a newcomer to Rust and perhaps having been spoiled by Go's very readable specification, I was surprised that Rust doesn't have a definitive language spec. How do the people working on Rust ensure everyone has a common understanding of the language without one?

I think a full, accepted specification that is adjusted in line with design decisions is still a bit out. Because as soon as you have a blessed specification, people and tools and such are going to depend on it, which limits the ability to change and break the spec down the line.

I don't think Rust is stable enough yet for a real specification.

Re: Rust 2019 and beyond: limits to some growth

#177

Post by laszlokorte »

steveklabnik wrote: post #160
fhrow4484 wrote: post #99

The Rust documentation is a bit outdated: https://www.google.com/search?q=rust+tour the 1st result is "A 30-minute Introduction to Rust". Going through it requires 4 navigations from the user to get to a valid page, everything in between is deprecated

Interesting! That page has been deprecated for something like four years... thanks for pointing this out. I've seen people mention other pages before, but never this one.

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 the nightly version? But I am not sure. I guess the second-edition does not differ much between the rust versions as the chapters look the same, except for bug fixes? I am not sure.

As a beginner learning rust that is really confusing because I am never sure if I am reading the correct book or if there is some other version with more information.

Eg why differs [6] so much from [7] when both are the "second edition"?

Ok, while writing this comment I now see that [2] are only empty pages linking to [8] and that all that books and documentation are generated for each rust version. But my point still stands: When coming from the google search result page to the rust documentation there is some confusion of what I am looking at.

[1]: https://doc.rust-lang.org/book/first-edition/index.html [2]: https://doc.rust-lang.org/book/second-edition/index.html [3]: https://doc.rust-lang.org/book/ [4]: https://doc.rust-lang.org/1.28.0/book/second-edition/forewor... [5]: https://doc.rust-lang.org/1.29.0/book/second-edition/forewor... [6]: https://doc.rust-lang.org/book/second-edition/appendix-04-ma... [7]: https://doc.rust-lang.org/1.30.0/book/second-edition/appendi... [8]: https://doc.rust-lang.org/1.30.0/book/second-edition/

Re: Rust 2019 and beyond: limits to some growth

#178

Post by sevensor »

jniedrauer wrote: post #118
cageface wrote: post #54

Earlier quoted context omitted.

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-…

Go is still a very simple language. It's not just social engineering. Compare it to Python, which is another "simple" language that you can be dangerous in on day one. As you gain experience in Go, you learn idiomatic ways to do things and memorize the core library, but the fundamental mechanics don't change. As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 diff…

> As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 different ways to build a distributable package, then start extending __getitem__ and __setitem__ and adding decorators to everything and before you realize what you've done, you've torn apart the laws of physics and your code has nightmarish side effects lurking around every corner.

Alternatively, you glimpse the chthonic horrors lurking at the end of that path, purge your code of hidden mutable state, and use Python to write straightforward procedural programs.

Re: Rust 2019 and beyond: limits to some growth

#179

Post by steveklabnik »

laszlokorte wrote: post #177
steveklabnik wrote: post #160

Earlier quoted context omitted.

Interesting! That page has been deprecated for something like four years... thanks for pointing this out. I've seen people mention other pages before, but never this one.

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 ideal. So we've decided to only ship the "edge" version of the book, even if it may be a bit ahead of what's currently in print.

Re: Rust 2019 and beyond: limits to some growth

#180

Post by zanny »

Thiez wrote: post #131
zanny wrote: post #52

Earlier quoted context omitted.

I don't feel like C was ever meant to be the permanent foundation on which all other computing was built. It was a language for its time. It took assemblies of the 70s made them much more palatable with an imperative syntax. C++ was also not meant to be a permanent foundation. It took shortcomings in C for scale and hacked on top functionality Bjarne wanted. The complexity difference between a computer 46 years ago,…

> if Rust introduced overloading and default arguments all those who don't know it exists won't have the language made any harder to use, but those that want it can take advantage of it. The following program might no longer compile if `f` could be overloaded, additional type annotations would be required. fn f(n: u8) -> u8 { n + 5 } let o = Some(Default::default()); println!("{:?}", o.map(f)); In general I would exp…

I don't want to really derail the thread into a discussion on overloading - I was citing it more as an example of a common desire that also introduces a lot of compiler level complexity without really modifying the language syntax - but I imagine any first pass conservative overload implementation would be restrictive enough to let the compile know if theres only one definition of a function. Default would only break if there were 2+ impls of the same signature and would just require a type annotation then.

I'd argue you could not implement overloading without enough support being in place to let the current single signature inference work as it does, which is also probably a good chunk of why its never been really proposed in earnest. Its a hard problem to approach.

Post reply on HN