> What do you feel is actually missing from Rust?
A solid NumPy-like library, for one.
A solid NumPy-like library, for one.
- There's Atom with Tokamak, which you must also install racer and clippy via cargo to get rapid in-line linting.
- Then there's Visual Studio Code with RustyCode which you can also integrate with racer and clippy, that provides faster code completion and hovering over items will show a tooltip that documents that items.
- Some people like IntelliJ Rust, but I've not tried it myself.
As for installing racer and clippy, it's been made a lot easier recently via rustup:
rustup component add rust-src
rustup component add rust-docs
rustup toolchain install nightly
rustup run nightly cargo install clippy
rustup run nightly cargo install racer
Now you're good to go.
As for NumPy, there's official crates like the `num` family, which provides a plethora of useful numerics capabilities. It's not my forte though so others would know more about the best numerics crates outside of the `num` family. If you know what functionality you are looking for, it may already be created and is searchable at Crates.io.
Most Java/C# IDEs will get you:
- Type-based autocomplete (racer/YCM/etc have this for Rust)
- Jump-to-definition / documentation (YCM/etc has this)
- Autoimport
- Non-grep-based refactoring
- Auto-boilerplating: for example, type `impl Trait for MyType` and have it tab-complete to a skeleton trait impl
- Some error integration (not just fileline jump-to), with tooltips and stuff asking you how you want the IDE to auto-fix the error
- A bunch of other smaller useful things which I can't remember at the moment
Now, autocomplete is a major chunk of this, but nowhere near being all of it.
The way I see it there are two camps on this issue. There's the "text editor" camp who use vim/emacs/sublime and when they are asking for IDE support they just mean autocomplete and jump-to that works from their editor. Then there's the camp coming from Eclipse or VS who want the whole deal.
The Rust Language Server project (https://github.com/jonathandturner/rls) is working on exposing this info from the compiler in a structured form so that IDEs and "text editor"s alike can get IDE features.
Rust does have lots of numeric crates. Too many. I took a look at matrix multiply functions recently.(See [1], below "Here is what the Rust compiler actually does", for some notes on the effectiveness of Rust's subscript checking optimization.) "algebloat" wouldn't compile on stable. "matrixmultiply" is all unsafe code, with C-type raw pointers. "ndarray" has unsafe indexing. "scirust" has more raw pointer manipulation. "matrices" is an empty project.
In the "num" crate, there are bigints, along with rationals and complex numbers, but no matrices. "numeric" has matrices, but it's just a wrapper for some common C libraries. (Also, calling "panic" for a singular matrix in SVD is kind of drastic.[2])
Each of these matrix crates has its own representation for multidimensional arrays. You can't mix them easily.
Matrices in Rust really need some standardization.
[1] https://news.ycombinator.com/item?id=13230551 [2] https://github.com/numeric-rust/numeric/blob/master/src/lina...
We've had this discussion before. ndarray exposes both a safe and unsafe API for indexing, just like the stdlib vector (or core arrays). That is not problematic.
I agree that the lack of standardization is a problem, though. I think that mostly folks use ndarray or nalgebra (and num if they need bigints). Anyone can upload a crate, the question is if the crate is the main one used by the community. There are some efforts to make it easier to choose crates amongst alternatives on crates.io, however.
I suspect most of the issue here is just that no group (only individuals) is using Rust for scientific computing yet, so there's no large driving effort behind getting good libraries here. When I needed this in Rust I just picked the library that I thought would work best with very little thought, with no thoughts on writing my own or improving the lib because I didn't have time. When larger groups work on things generally attention gets paid to stuff like this and better solutions come out on top. Rust isn't quite there yet in adoption for this to happen, maybe soon :)
For 1D, though, the optimization of checking is pretty good. "get_unchecked" for Vec may be obsolete. There's an amusing Stack Overflow question [1] from someone who complains that he changed an access from "[]" to "get_unchecked()" and his program didn't get faster.
Maybe it's time to deprecate some of the legacy "unsafe" stuff. Preferably before the first CERT advisory involving a buffer overflow in a Rust program.
[1] http://stackoverflow.com/questions/39196594/why-dont-i-get-p...
Sometimes you don't want to rely on LLVM, and sometimes the size invariants aren't as easily available to LLVM.
I'm not even sure if this would be that necessary outside of the library itself; unchecked indexing would be useful to implement ops like matrix multiplication within the library, once, and probably never used after that.
The API exists mostly to mirror the stdlib one and its use cases. I don't think it's supposed to be the API you reach for usually. Just because the API exists doesn't mean it's the one you're supposed to reach for.
> That may improve, especially if there's some standard idiom for declaring multidimensional arrays and the compiler handles that idiom well.
I mean, multidimensional arrays do exist in the language. I'm not sure what you're getting at here.
These libraries provide support for treating multidimensional arrays as matrices, with the semantics of matrices (multiplication, addition, etc). You seem to be arguing for making this a first-class compiler feature? I'm not sure how that's very different from just implementing it with some unsafe code -- the bug-prone-ness of the unsafe code is about the same as the bug-prone-ness of a compiler optimization that replicates it. There is a case to be made for moving it into the stdlib itself to avoid the "10 ways to do it" issue, but Rust wants to keep the stdlib small so that's not going to happen.
This is the point of unsafe code. You use it to implement a few safe abstractions like matrix multiplication and iteration in libraries, verify that, and use them. There's a stigma attached to unsafe code; rightly so; because there be nasal demons. But we shouldn't take it to its extreme and conclude that all unsafe code is bad.
> "get_unchecked" for Vec may be obsolete.
Wouldn't count on it. A single datapoint doesn't really mean much here.
I mostly see get_unchecked being used in the context of other unsafe code. Rust's stdlib uses it for the internals of CString and for implementing iterators. It also uses it in an optimization for the rand crate; which does some trickyness with bitmask indexing that LLVM might optimize but I suspect the authors didn't want to rely on LLVM optimizing.
Servo doesn't use it at all, though. Going through my cargo cache dir the crates that use it are those which implement abstractions. Some, but not all, of the use cases there probably get optimized out anyway. The regex stuff also uses it but the invariants there are complicated enough that llvm won't optimize it (there are some decent comments listing out these invariants and explaining exactly how to use it safely, though).
Every matrix package I've seen so far in Rust turns off subscript checking with unsafe code.
[1] http://graphics.stanford.edu/courses/cs148-10-summer/algebra... [2] https://docs.rs/crate/nalgebra/0.10.1/source/src/linalg/deco...
The whole point of Rust is to put an end to that.
Fast and easy to use are UI tricks that can't be handled by a server.
Edit: I just realized that this may be read in a negative connotion and I didn't mean it like that. I just mean that I'm not the person who should be looking at those. I just know it doesn't exist yet and I'd like it to. Telling me of the Rust Server thing gives me no information as to how close the IDE is to being done.