Giters

vbarrielle / not-yet-awesome-rust

A curated list of Rust code and resources that do NOT exist yet, but would be beneficial to the Rust community.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Not-Yet-Awesome Rust

A curated list of Rust code and resources that do NOT exist yet, but would be beneficial to the Rust community.

The purpose of this list is twofold:

  • Enumerate specific use cases and their problems domains that do not yet have a robust ecosystem in Rust.
    • The definition of "specific" and "robust" for this list is yet to be determined!
  • Encourage the Rust community to approach gaps in the Rust ecosystem by providing this list as a point of collaboration!

You can jump right into editing this file here. See the contributing guide for information on what you can do to help or if you have questions about this list!

Table of contents

The List

Documentation

Stack Overflow

  • There are many older Rust questions on Stack Overflow that wouldn't work with today's Rust because of syntax that has changed since the release of 1.0, or that may have better solutions because of other Rust ecosystem developments.
    • See #4 for an SO query and a list of these known issues!

Libraries

Character encodings

Data processing

  • DDS library wiki
  • HDF5 (see also Wikipedia and this Reddit post)
    • The following crates exist, but are missing some thing(s):
      • hdf5-rs has a lot of functionality, but is currently in design flux and has an issue reporting its status.
      • hdf5 seems capable of writing HDF5-encoded data, but not reading it.

Data structures

  • A concurrent HashMap-like structure has not been fully developed yet.
    • concurrent-hashmap is still missing methods like iter_mut, entry, drain, and clear from the original HashMap interface.
    • evmap is a different design around eventual consistency, and so departs from the normal HashMap interface.

Geometry

  • PCL equivalent - point clouds, essential 3D geometry functions
  • Voxel library, operations and representation of voxel data. There is a piston crate for rendering voxels but this isn't suitable for working on domains like medical data, more geared towards game development. To enable processing in scientific domains like medicine there needs to be processing functions such as being able to: convert to triangular mesh, thresholding, and morphology. This is because things like MRI data is expressed as voxels, thresholding can separate grey and white matter in the brain, morphology identifies shapes and structures inside the body etc.

Geospatial Information Systems

  • OGC standards - multiple crates for standards for encoding, sharing or manipulating geospatial data link. There's already a crate for GeoJSON but none of the others appear to have crates.
  • More complete GDAL wrapper (or pure rust alternative). rust-gdal is an incomplete wrapper so needs work.

Machine Learning

  • Machine learning toolkit like scikit-learn in Python (both rust-learn and rusty-machine are insufficient). Rust-learn only supports classification, rusty-machines misses support for sparse data and serialization. Both of them miss quite common unsupervised techniques (like PCA).
  • Deep learning toolkit with GPU support a good flexibility (think Tensorflow or Chainer in Python). Most of the current libraries are either simplistic (you cannot do seq2seq network in them for example), or miss GPU support.

Mathematics

  • Sparse matrix libraries (SPRS library needs some love, since sparse/dense matrix products are super slow, otherwise is quite good)
  • Designing low latency DSP algorithms suitable for embedded use (common filters, analysis functions)
  • Library for nonlinear dynamical or chaotic systems (solvers, numeric methods etc.)

Native desktop applications

Microsoft Office
  • An interactive Visual Basic uses for scripting by using the COM interface, which I believe winapi supports.
Native UI toolkits
  • A mature framework for Windows native UI has yet to be established, but native-windows-gui claims to be approaching completion.
  • Abstractions over native UI choices for each platform have yet to be available.

Parsers/Emitters

  • Ability to parse Registry.pol files from Windows machines -- implemented by this guy!
  • Common office document formats are yet to have more mature solutions:
    • Excel/Calc spreadsheet deserialization seems available with calamine, but no serialization libraries seem available for them, let alone for the entire XML formats that the Office/OpenOffice suites themselves support.
    • Otherwise, OpenOffice and Microsoft Office
  • There is currently no library to convert between different office document formats.
  • The beancount data format has no parser or emitter libraries yet.
    • A builder interface for a higher-level emission API would also be nice.

Personal information management

  • Contacts via vCard have been implemented using vobject, but no "high-level interface" exists yet that uses it or an alternative.
  • iCalendar parsing has been implemented via several crates (i.e., vobject), but a higher-level API is missing.
  • Bindings to the Python implementation of beancount do not yet exist.

Web bindings

Google API
  • Generation of Google bindings using googleapis and gRPC would be more performant than using JSON web requests to the Google API.
  • There is also room for more idiomatic APIs for Google in general. google-apis-rs exposes the vast majority of Google Services, but they can be difficult to grok for beginners or someone unfamiliar with Google APIs in general.

XML

There is yet to be a library that handles all of these:

  • General purpose DOM tree
  • Proper encoding handling
  • DTD handling
  • XML Schema validation
  • XPath
  • XQuery
  • XSLT
  • Is fast

For more feature and performance comparisons for existing Rust XML crates, see choose-your-xml-rs.

About

A curated list of Rust code and resources that do NOT exist yet, but would be beneficial to the Rust community.

License:The Unlicense