21–30 of 237 posts
Excellent. These are things designers of other languages should have considered but didn't. Looking at you, C++. I write mostly C++...
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).
Not sure which managed languages you mean, those that I use also provide the option to compile to native code just like Object Pascal, if I wish to do so.
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.
To what extent is Rust being adopted by the Fuchsia team?
I 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.
I believe that the general consensus is that it is to be avoided for libraries. For application development it is convenient, but not perfect and it will probably be replaced by something better at some point.
> It sometimes feel like the language is moving too fast for me to learn it.
It has been moving fast, but expect that to change over the next year! Most of the "Rust 2019" posts have been advocating slowing down.
Earlier quoted context omitted.
And Fuchsia.
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?
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?
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…
I would love to see a feature freeze and focus on writing down a spec and speeding up the compiler.
Earlier quoted context omitted.
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…
I have many times run into issues where a written down language spec would have been a big help. The are very useful features in the language that aren't mentioned anywhere in The Book, discovering them requires hoping someone on twitter mentions it, which is crazy. I would love to see a feature freeze and focus on writing down a spec and speeding up the compiler.
The only thing not mentioned in the book should be HRTB. Did you run into something else?
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…
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 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 accepted but are either not finished or not implemented yet. All of those can/will have a significant impact on idiomatic code and API design and will increase the complexity burden:
* specialization * generic associated types (a simple form of higher kinded types) * async/await + generators * existential types * const generics ...
So I do believe Rust needs to slow down considerably and get much stricter with accepting new features. Both to not overwhelm the existing userbase and to not make the language another C++ in terms of complexity.
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…