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?
Rust 2019 and beyond: limits to some growth
11–20 of 237 posts
Re: Rust 2019 and beyond: limits to some growth
#12Earlier 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.
> ... comparable to C++’s. When? 2018? 1990?
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.
Re: Rust 2019 and beyond: limits to some growth
#13Re: Rust 2019 and beyond: limits to some growth
#14I 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…
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…
History has proven that system programming language winners come with an OS/platform to cimment their advantage over others.
So I don't agree that the age of "The age of multi-vendored languages like C or C++ for systems programming might be coming to an end.", unless you mean we will managed to get rid of all OSes written in them, specially UNIX flavours or GPGPU libraries.
It would be nice, but it won't happen until the next big hardware revolution like Quantic computers being developed in Q# for example.
Re: Rust 2019 and beyond: limits to some growth
#15I ran into the Failure crate today. It was hard for me to figure out if it was something official that was going to make its way into the core language or just a third party crate. If the former, should I avoid learning failure patterns that are not using this crate? It sometimes feel like the language is moving too fast for me to learn it.
`failure` captures common error patterns in Rust and provided a test bed for experimenting on them while working to improve `trait Error`. There is an RFC for pulling some of the trait improvements into the language. After that, I believe they plan to continue to iterate on the design of the failure crate. The general recommendation I make and see from others is that `failure` is far from stable. Feel free to use it…
That RFC was accepted and merged quite a while ago!
Re: Rust 2019 and beyond: limits to some growth
#16As 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?
[deleted]
Re: Rust 2019 and beyond: limits to some growth
#17Earlier quoted context omitted.
> ... comparable to C++’s. When? 2018? 1990?
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).
Re: Rust 2019 and beyond: limits to some growth
#18Sure, we can limit the language growth, as soon as we get all the critical features in!
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.
Re: Rust 2019 and beyond: limits to some growth
#19As 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?
Some stuff is quite nailed down, some stuff is not. In the end, not breaking existing code is the most important thing.
These things are always on a spectrum. Just because a spec exists doesn’t mean that it has holes; 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?
The answer is that it’s all a spectrum. Many languages don’t have anything resembling a spec at all!
(We are interested and actively working on such a thing for Rust, but we’re shooting high. It’s gonna take a while.)