Most importantly, the finished MIR revolution [0] will finally allow developers to focus on new exciting features, like ergonomic "impl Trait" [1], incremental compilation, or even the beginnings of Gc [2].
I was surprised to hear this and immediately thought "but why would you do such a thing!?" but I read the blog post and I'm impressed with the forethought that I certainly lacked. This is freaking genius.
Adding to_degrees() and to_radians() methods to f32 and f64 seems a little out of place, considering f32 and f64 are numbers without units. Why not include to_celsius() and to_fahrenheit() then?
Shouldn't to_degrees and to_radians be part of a trait that f32 and f64 (and potentially other types) both implement, rather than being independent methods directly on f32 and f64?
Over the course of Rust's history, we have tried a number of times to get a trait hierarchy for numerics working, and it's always had problems. It's still a general open question.
I'm not suggesting a trait hierarchy for numerics, or a numerical tower. I'm purely suggesting putting individual methods or families of related methods into independent traits that each numeric type can implement. For instance:
Operators like + and / already live in traits; why not put methods like these into traits as well, so that users can implement them for their own types (variable-precision floats, decimal floating point, etc)?
(As a side note, can a trait accept an AsRef<Self> in place of &self or self, so that register-sized objects implementing Copy don't need to use &self?)
As always, it's a tradeoff. Doing something as a trait is hard for its own reasons, at least in a standard library. Should radians and degrees be two traits, or one? If we pick wrong, are we okay with having that be stable forever?
Plus, since you can define your own traits, if this is functionality you need, you can just do it, and delegate to the inherent implementation for those two types.
We really do need to spend time on the numerics APIs though... I would love to pour some time into it again... just figuring out how to fit it in with all the other stuff I'm doing :(
I agree with the caution though. This takes time to get right.
The advantage of the current approach is that you can just define the traits you need in your crate, and the standard library does not have to stabilize unrefined interfaces.
These are the sorts of things type systems try and help avoid. Having the same crappy behavior as an '80s scientific calculator isn't exactly something to strive for.
That said, this is probably such a simple use that it's not worth having Degree and Radian classes in core.
Not really. I'm for strong typing, but not all mathematical concepts need to be a separate type. Should we have separate type for 'ratio' or 'real' or 'natural'? A radian is still represented as a number -- specifically a float, generally. This is more like Rust building out a standard Math library, a la Node.js or C/C++. Since rust is aiming at being a C replacement, I can understand why they'd include this.
It's a number associated with a unit. Making it a distinct type, even when the underlying representation is a float, makes it harder to make mistakes by substituting or combining units inappropriately.
This sort of stuff works really well when the type system incorporates units of measure directly (usually as some kind of generic type parameter). F# is a good example.
This is similar to having 3D position and direction in different types (e.g. point and vector instead of a generic 4-component vector). It looks nice in theory, and it is 'type safe' (e.g. you can't add 2 points, only point+vector or vector+vector), but writing real-world code with this is awkward.
Hm, I'm likely thinking about it wrong, but I don't see why you'd even necessarily want a type system to stop that... Is it not similar to running, which I expect to work?:
var s1 = "blah"
var s2 = s1 as string
var s3 = s2 as string
edit: Nevermind, I guess you're wanting like types for units of measurement. Sounds interesting.
Most readers would expect the "as string" statement to be idempotent; to_radians() isn't, because it's actually implicitly degrees_to_radians(). If your type system isn't going to keep track of which quantities were already degrees, then your function names should be a little more explicit about the fact that value.to_radians().to_radians() is both converting and reinterpreting, twice.
I see, I had missed that detail. Thanks for the explaining it!
Is the best way to solve that problem by introducing "unit measurement" types that are more specific than general numerical types? Or is there another way? Or even a general concept I can go read about? Thanks in advance!
Last I checked, scientific calculators had degrees and radians as modes. This made pressing the button idempotent, an appropriate compromise given the lack of types.
> We’re excited about features like MIR becoming the default and the beginnings of incremental compilation, and the 1.11 release has laid the groundwork.
The changelog is silent about these two points, so does it mean that -Z orbit defaults to "on" in 1.11 and -Z incremental can be used in 1.11?
I think it's on in the 1.12 beta, which was also published today. The orbit switch was switched on during the cycle that just ended, so I'd be surprised if it was already on on the stable.
We're working on the new book because the old book isn't as good as it could be, but that doesn't mean it's bad: a lot of people have told me that they really love it. But I am hyper-critical of my own work, and there's a lot of ways you can improve something that's already good :)
As you can see, the new book isn't really far enough along to fully teach you Rust yet. I would maybe check out the new material first, and then just read the existing book afterwards.
By the way, you've helped me multiple times in multiple mediums - it appears you're both very active and very productive. It is very appreciated, thank you.
(I'm sure some random strangers thank you doesn't mean much, but it's hard to not notice your work. And i just wanted to make sure i expressed my appreciation.)
Cool! One thing I hope you can fix: That page hijacks cmd-option-{left, right}, which are (or can be) used in Safari for tab switching. Very annoying. Apps that hook the arrow keys should always check for whether shift/alt/ctrl/meta keys are also down, to avoid trampling on people's keyboard shortcuts.
> Apps that hook the arrow keys should always check for whether shift/alt/ctrl/meta keys are also down, to avoid trampling on people's keyboard shortcuts.
The majority of pages shouldn't intercept up/down either, because that breaks the ability to scroll the page. Only pages that will never involve scrolling (such as whole-screen web apps or games) should do that.
Left/right can be OK, as long as you never expect your page to need horizontal scrolling.
FWIW, I am one of those people who really loves it. I'm excited for a new book, but I feel it's worth saying that the old one has been not only instrumental in my efforts to learn Rust, but also a flat-out enjoyable read. Thank you!
Hopefully someday, though the new book will also be published by No Starch, so if you don't want to wait, I'll bet you can buy one from them (proceeds going to charity).
Servo's compile time went down by about 20% or so. We think that it's because non-zeroing drop enabled LLVM's memcpy optimizer (which is currently pretty fragile pending the MemorySSA rewrite) to do a better job.
As with any large-scale change, it depends. We did testing across the ecosystem before turning it on by default (that will be in a future release, not 1.11) and there weren't any major regressions, at least. Some small improvements are there.
It says right on it that "rustup is an official Rust project. ", though I can see why you might not trust that. If you ask in IRC, most people will point you to it first these days.
Yeah. It does link to the rust-lang-nursery org, but I totally understand the hesitancy. Then again, it is just in beta, so it's not as hyper-important right this moment for everyone to use it.
Why a major OS would need to be "picking up Rust as a first class citizen"? What does that even mean?
So far no major OS has picked C++, Java or any other language than C as a first class citizen either. All of the OS related loadable library APIs are still C.
Doesn't seem to slow down any of those languages, though.
2. I'd be interested to know why Servo is a "pipe dream".
3. Why does a major OS need to pick up Rust as a "first class citizen", when they haven't done so for JavaScript, Java, Python, PHP, Ruby, Go, D, Scala, Haskell, Lua, Clojure, etc. etc.?
Firefox and Mozilla might very well go down but Rust can stand on its own. Not sure however what "first class citizen" for a programming language on an OS means. Can you clarify?
Yeah not really sure what that was supposed to mean in relation to Rust. To me that statement would only make sense for languages that require some sort of runtime/interpreter installed rather than natively compiled.
eg Python and Perl get shipped by default in most Linux distros base image, whereas Java or Ruby don't tend to be.
Whereas C doesn't have a compiler shipped in some/most base images - despite C being about as first class as languages get on Unix.
Yeah. I was also wondering if they meant "available through my distro's package manager", in which case, that's been happening a lot lately. Debian and Fedora will both have initial packages in their next releases, and work is ongoing with a number of linuxes.
I was composing a much longer answer before I realised that this is actually a really interesting question. While I try and think through that, this is my immediate reaction. It comes down to one thing: the ABI.
Only C (and therefore to some extent C++) is the first class citizen in all the major OS families we care about, because the C ABI is the standard for compiled objects (whether executable or library).
Totally. Rust is still far too young for something like ABI stability, so it wouldn't even make sense as an option yet. But beyond that, this pretty much puts the world in two boxes: "C" and "not C". There's a lot of activity in the "not C" space, so being there isn't an automatic death-knell for Rust, as the OP seems to imply.
> Rust is still far too young for something like ABI stability
Without question.
The interesting question to me is (if starting again) whether ABI stability/compatibility is something that is necessary or desirable for userspace citizens to interoperate with each other and the kernel.
> Only C (and therefore to some extent C++) is the first class citizen in all the major OS families we care about, because the C ABI is the standard for compiled objects (whether executable or library).
Well, on Windows there's COM for this, which is technically the C ABI too, but really deserves to be considered its own thing.
Yes, that's it. To keep things maintainable, OS interfaces are available to applications in the form of shared libraries, and that requires a well-defined and stable language ABI.
It's regrettable that C++ currently has an advantage over Rust in this regard...
C++ is not just boost and ICU - there are a handful of C++ libraries with a good ABI compatibility track record, for example Qt and the KDE stack.
The C++ ABI of Microsoft Visual Studio is stable since practically forever, albeit with a severe restriction: the language ABI is stable, but not the C++ (or even C) standard library ABI - every Visual Studio release comes with a new incompatible msvcrNNN.dll. But you can load as many different runtime libraries into a process as you like, the big practical restriction is that you can't pass standard library objects allocated by one runtime to a different one.
The C++ ABI of GCC is stable since version 3.2, released in 2002, on x86 platforms (there were numerous fixes in later releases for other platforms). They even managed to retrofit new incompatible C++11 requirements on std::string with some preprocessor hackery and namespace mangling, without bumping the libstdc++ SONAME.
As usual, on macOS the situation isn't as good because they threw out libstdc++ for some clang reinvention of the wheel.
It's not really true that C++ does not have an ABI advantage over Rust if (by your own comment) they both end up using the C abi. Although pedants will insist that C is not a subset of C++, practically speaking you can write idiomatic C perfectly fine that will compile with a C++ compiler, and much C code in the wild is actually written this way. And most moderately experienced C++ developers are very comfortable with all of these elements and syntax (like pointers, goto, C style callbacks, etc), because they are a subset of their own language. It's very straightforward to have your API be C (and therefore have a stable ABI) but do implementation in C++. Even some C standard libraries do this.
In summary, if you're writing a C API/ABI, source compatibility is still a major advantage, there is no two ways around it.
[0]: https://github.com/rust-lang/rust/pull/35764
[1]: https://github.com/rust-lang/rust/issues/34511
[2]: http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...