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

31–40 of 237 posts

Re: Rust 2019 and beyond: limits to some growth

#31

Post by taneq »

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.

I'm not sure that's an important comparison. They're not saying that there's no good reason for the current state of C++, or that they can't understand why it's like that. They're just saying that it'd be nice if Rust didn't disintegrate into the same morass of new syntax, primitives, idioms and pitfalls that C++ has become.

Re: Rust 2019 and beyond: limits to some growth

#32

Post by pjmlp »

steveklabnik wrote: post #26
pjmlp wrote: post #24

Earlier quoted context omitted.

Fuchsia is still largely written in C++, with a couple of modules like the TCP/IP stack, written in Go, and Dart for the UI layer. To what extent is Rust being adopted by the Fuchsia team?

There’s a few hundred thousand lines of Rust in Fuchsia. (Garnet’s repo claims 12% Rust as of today.) They’ve been hiring Rust programmers aggressively to add more. They’ve been helping drive the design and implementation of async/await, since they’re big users. Rust is one of the four or five languages that they maintain a sort-of-libc for and use it as an example for writing applications for the OS. (It’s a microke…

I see, so is that an indication that Zircon might eventually migrate to Rust?

Re: Rust 2019 and beyond: limits to some growth

#33

Post by reificator »

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.

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?

Re: Rust 2019 and beyond: limits to some growth

#34

Post by steveklabnik »

reificator wrote: post #33
aaaaaaaaaab wrote: post #8

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.

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 ;)

Re: Rust 2019 and beyond: limits to some growth

#35

Post by steveklabnik »

the_duke wrote: post #29
blattimwind wrote: post #9

Earlier quoted context omitted.

I've been dabbling in some Rust lately and as a long time mostly-C++-and-Python-and-some-Java dev I've found it relatively easy to get started with it. Sure, a lot of things are different (e.g. struct+impl vs. classes), many clearly better, some that may/may not be better just different, but overall it seems to me like Rust is relatively easy to pick up coming from C++. And C++ is usually way uglier and far more comp…

I was drawn to Rust because, behind the apparent complexity of the borrow checker, the language is/was actually very simple and easy to understand. I have been using Rust extensively for over 2 years. In those two years, the language complexity has increased substantially. It's already at a stage where I'm worried about losing track. Also, there is quite a large amount of changes in the pipeline that were already acc…

One thing that’s come out of this years’ posts by various people is that, after those features have landed, people generally do want things to be done. These features shore up major weaknesses in the language for various domains, but there’s not really things not in that list that many people still extremely desire.

Re: Rust 2019 and beyond: limits to some growth

#36

Post by steveklabnik »

pjmlp wrote: post #32
steveklabnik wrote: post #26

Earlier quoted context omitted.

There’s a few hundred thousand lines of Rust in Fuchsia. (Garnet’s repo claims 12% Rust as of today.) They’ve been hiring Rust programmers aggressively to add more. They’ve been helping drive the design and implementation of async/await, since they’re big users. Rust is one of the four or five languages that they maintain a sort-of-libc for and use it as an example for writing applications for the OS. (It’s a microke…

I see, so is that an indication that Zircon might eventually migrate to Rust?

I don’t think there’s any plans to move Zircon. It’s also less pressing, IMHO, since it is a microkernel. Maybe someday, but if I were in charge, it wouldn’t be super high in my list.

Re: Rust 2019 and beyond: limits to some growth

#37

Post by firethief »

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.

So, when it's too late?

Re: Rust 2019 and beyond: limits to some growth

#38

Post by topspin »

galangalalgol wrote: post #18
cesarb wrote: post #7

Earlier quoted context omitted.

Every feature is a "critical feature" to someone. You have to know when to stop.

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.

Re: Rust 2019 and beyond: limits to some growth

#39

Post by cryptonector »

> Reputation for overcomplexity, loss of users. Becoming the next C++ or Haskell.

I think Rust is already there. It's a concern, but I'm not sure you can or should try too hard to avoid this.

What you can do is look to make simplifications as you add complexity.

And sometimes innovations can have simplifying effects. For example, the various "effects" libraries for Haskell simplify I/O code compared to not having them.

Re: Rust 2019 and beyond: limits to some growth

#40

Post by cryptonector »

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.

It's absolutely essential. A sine qua non for a serious new language.
Post reply on HN