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

151–160 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#151

Post by dbaupp »

Ericson2314 wrote: post #97
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…

OK yours is the second comment to talk about "Users". IMO this first-impression-based design methodology, like we're writing some consumer CRUD app for the startup [proverbial] you're gonna quit in terrible skeumorphic philosophy for designing languages. Languages are for more terrible; programs last (too?) long; long-future readers may be expert or knowledge. Let me response point-by-point > It's not a thing your us…

"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 compiler only truly cares about the high-level language when writing code. They may dip into the mid-level for optimising their code etc., but they won't write it directly: to a non-compiler author, IRs are implementation details of the programming languages that happen give insight into how some detail of the language works or how a particular piece of code is optimised.

To hammer home this point: if there's some major change required/desired in the high-level language, the current details of the mid-level language shouldn't affect the overall design. The mid-level IR can change to accommodate the desired surface behaviour.

Re: Rust 2019 and beyond: limits to some growth

#152

Post by qznc »

DannyBee wrote: post #75
Ericson2314 wrote: post #45

The comparison between C++ and Haskell is laughable, and shows that Graydon is missing the most important facet of this: GHC Haskell and Rust with have an intermediate language (Core and MIR + Chalk, respectively), which keep the rest of the language in tight check. No other mainstream language has this (Java bytecode doesn't really speak to high level safety properties). This ensures the vast majority of the languag…

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/html/defAssign....

Re: Rust 2019 and beyond: limits to some growth

#153

Post by Longhanks »

akavel wrote: post #145
the_clarence wrote: post #114

Earlier quoted context omitted.

Big fan of Rust as well, but this is why both Go and Rust are going to co-live. They are both amazing languages.

Personally, in my heart, I'm kinda keeping fingers crossed for a future where if one needs to/has to, one uses Rust (mostly where one would use C/C++ today, including for "squeezing the last drop of performance", and especially high risk everpresent libraries like libpng; plus as an extra, probably for highly ambitious parallelism like in Servo); otherwise, one just goes with Go (for the amazing general productivity…

“Secure” Personals devices with a Kernel developed entirely by Google? Sounds like a nightmare.

Re: Rust 2019 and beyond: limits to some growth

#154

Post by lmm »

usrusr wrote: post #133
mehrdadn wrote: post #112

Earlier quoted context omitted.

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?

There are two possible ways to deal with that situation: create something new that is the old thing plus the feature that had been ruled out for it, or simply revoke that decision. Eternity can be surprisingly short when everybody agrees that it is time to move on. Both ways are perfectly possible, and both would in many cases be much preferable to having an implicit "is it time yet for X?" on the agenda every time t…

> Eternity can be surprisingly short when everybody agrees that it is time to move on.

That relies on having a decision-making process and culture that accommodates that. In my current job I'm stuck dealing with inadequate tools because of tool choices made in 2002 that no-one has the political capital to revisit.

Re: Rust 2019 and beyond: limits to some growth

#156

Post by steveklabnik »

dullgiulio wrote: post #149
baq wrote: post #142

Earlier quoted context omitted.

Rust both greatly benefits from and is encumbered by LLVM. Maybe there’s room for a different LLVM-like or perhaps LLVM compatible project.

Interesting, what do you think makes is encumbered by LLVM? I thought that sqeezing MIR in the middle Rust could get both Rust-specific transformations and then benefits from the LLVM generic code optimizations...

It can!

LLVM is fantastic, but it's also a huge C++ component, and it's not necessarily optimized for speed. It would be nice to end up with something in Rust to simplify the toolchain needed, and to maybe have something that could be even faster for debug builds.

Re: Rust 2019 and beyond: limits to some growth

#157

Post by steveklabnik »

lambda wrote: post #77
steveklabnik wrote: post #28

Earlier quoted context omitted.

Absolutely! We’re working on it for a reason. The only thing not mentioned in the book should be HRTB. Did you run into something else?

Conditional compilation? There's still just a placeholder referring to the first version of the book or the reference. https://doc.rust-lang.org/book/conditional-compilation.html pub(crate) doesn't seem to be mentioned in https://doc.rust-lang.org/book/ch07-02-modules-and-use-to-co... . Some things that are covered are a bit hard to find. For example, I didn't know if operator overloading was covered; it turns out, i…

Thanks! So I think that some of this difference is that you're mostly describing library features, not language features. It's also true that some of these examples blur the lines. I'm going to make some notes.

> it might be a good idea to remove the scary warning from it, or to do an audit of it and only put the warning on the sections that are found to be incomplete

Completeness is hard, as you've seen with the book! This is what we'd like to do, but it's non-trivial.

Re: Rust 2019 and beyond: limits to some growth

#158

Post by steveklabnik »

burntsushi wrote: post #110
f2f wrote: post #64

Earlier quoted context omitted.

> Go’s spec isn’t formally proven, for example, so you could make a similar claim: how can people know that it all works without a proof? that's moving the goalposts. let's see Rust's language spec finalized first, then we can talk about it being proven. without the two you shouldn't throw stones.

There are no stones being thrown and no goalposts moving. Go's specification is clearly in a much more advanced and useful state than Rust's. The point is to respond to "how can people know." That is, it is a measure of degree, not binary.

Yes, this is exactly it, thank you.

Re: Rust 2019 and beyond: limits to some growth

#159

Post by steveklabnik »

Santosh83 wrote: post #123

Rust can force a programmer to be disciplined and that's good as far as it goes, but sadly no current language can force (or even encourage) a programmer to think critically at an architectural level. Indisciplined coding leads to security issues (at least immediately), but a poor architecture can mean a complete failure of the project to meet its goals, never mind exceeding them.

One claim about Rust that's increasingly common is that its language constraints do require you to reconsider architecture. See https://kyren.github.io/2018/09/14/rustconf-talk.html for example.

Re: Rust 2019 and beyond: limits to some growth

#160

Post by steveklabnik »

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.
Post reply on HN