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

41–50 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#41

Post by Groxx »

dccoolgai wrote: post #30
rossdavidh wrote: post #23

I think that, in not only languages but anything related to code (frameworks, packages, etc.), there is a tendency for things to overshoot because that is likely to make those who know the most, more powerful (they know how to use all the features), and its negative impact is on new learners, i.e. those who have little or no voice in these decisions (for obvious and often good reasons). Thus, it becomes a form of pul…

As a longtime JS dev, I sometimes cringe for this reason when I see new features in ES. Even though I'm excited about them, when I think about experiencing them as a learner I feel intimidated. One good point the article makes that I wish more language designers accounted for is the fact that in a shared language you can't just pick and choose - to reach a level of expertise you basically have to know all of it.

JS especially has been a rocket-ship of new language features lately. It used to be my go-to language for new people since it was so simple (when used with a few boundaries (like every language needs)) that it could be picked up and the basics understood fairly quickly, and you can set people free to look at other people's code, and gradually learn DOM APIs and whatnot as needed.

Not any more. Not even close. The amount of stuff you have to deal with immediately is far larger now.

I actually miss the days when people added this kind of stuff to their transpiler of choice (e.g. coffeescript) and just used that - it doesn't need to be in the language, because it can never be removed from the language. Let fads appear and die outside that barrier, not inside.

Re: Rust 2019 and beyond: limits to some growth

#42

Post by lostmsu »

steveklabnik wrote: post #20
pjmlp wrote: post #12

Earlier quoted context omitted.

In the 1990's we already had a couple of OS vendors shipping C++ compilers on their OS SDKs (Apple, IBM, Microsoft, Be, Symbian). So far that is only true of Redox.

And Fuchsia.

There's an official Rust support in SDK? There's an official SDK?

Re: Rust 2019 and beyond: limits to some growth

#43

Post by steveklabnik »

lostmsu wrote: post #42
steveklabnik wrote: post #20

Earlier quoted context omitted.

And Fuchsia.

There's an official Rust support in SDK? There's an official SDK?

I’m talking about FIDL, to be clear: https://fuchsia.googlesource.com/docs/+/d4f9b980f18fc6722b06...

(And I also elaborate more about specifics in my other sibling comment)

Re: Rust 2019 and beyond: limits to some growth

#44

Post by [deleted] »

steveklabnik wrote: post #34
reificator wrote: post #33

Earlier quoted context omitted.

Let's also come back to it when Rust is older than C++. It's a new language targeted toward people who want stability and performance, what do you expect to see by now?

Rust will never be older than C++ since they both get one year older every year ;)

[deleted]

Re: Rust 2019 and beyond: limits to some growth

#45

Post by Ericson2314 »

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 languages are forgettable sugar, and making consistencies of various sorts tractable.

I would argue that even outside of languages as we conventionally think of them, the lack of separating functionality into core languages/interfaces and sugar is the central failure in letting complexity spiral out of control. And indeed, just about everything has.

Re: Rust 2019 and beyond: limits to some growth

#46

Post by [deleted] »

noir_lord wrote: post #17
pjmlp wrote: post #12

Earlier quoted context omitted.

In the 1990's we already had a couple of OS vendors shipping C++ compilers on their OS SDKs (Apple, IBM, Microsoft, Be, Symbian). So far that is only true of Redox.

To be fair though 1990's C++ written in the recommended way is almost a completely different language to 2018 C++. The change isn't as marked as say perl5 and perl6 but it is still huge. I've no dog in either fight though, I moved to managed languages a long time ago (Object Pascal was the last compiled language I used in anger).

[deleted]

Re: Rust 2019 and beyond: limits to some growth

#47

Post by skywhopper »

aaaaaaaaaab wrote: post #8
CJefferson wrote: post #2

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

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.

No, the point is to get ahead of C++'s situation so as not to repeat its mistakes. You can't do that if you wait until it's too late.

Re: Rust 2019 and beyond: limits to some growth

#48

Post by ajross »

topspin wrote: post #38
galangalalgol wrote: post #18

Earlier quoted context omitted.

Async/await isn't stable yet, that seems to be making many commenters here wait to adopt, so at least that should make it in before they lock it down. I'd like the platform independent SIMD but that I can admit is niche and could live in nightly for a long time without harming adoption. They have polls to get a feel for the difference between those two categories and which features fall into them.

Landing async/await will be a watershed. Fast, safe, low resource communications applications implemented in Rust will proliferate.

Or maybe it's just a fad. There have been far more failed IO paradigms than watersheds...

I mean, I like it too, but the point upthread is that you can't just suck in every nice-looking idea or you'll end up like C++.

Re: Rust 2019 and beyond: limits to some growth

#49

Post by paulsutter »

aaaaaaaaaab wrote: post #8
CJefferson wrote: post #2

I can't agree more with this. I am a long time c++ dev, been to c++ committee meetings. The language is too complicated and inconsistent, and that is now I believe unfixable. I believe no one understands it. New features keep arriving, but you still have to learn everything that came before, for older codebases. For example, {} style initalisers were added to simplify and "unify" things. Except to make a vector of le…

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

Re: Rust 2019 and beyond: limits to some growth

#50

Post by Ericson2314 »

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…

Also the Dependent Haskell work of Richard Eisenberg I'd argue is more important as an attempt to shrink the language than add expressive power. The main thing it does is combine existing language features, which only yields more constructs insofar as the old features had friction. You can think of it roughly as taking the convex hull (or probably better bounding parallelepiped) of the existing feature space.

Seen in this light, I've never such a thing attempted at this scale (GHC's size and GHC/Haskell's age), and very much commend it. Hope other things can do the same thing someday.

Post reply on HN