not-yet-awesome-rust / 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.

Not-Yet-Awesome Rust

An (unofficial) sub-community of the Rust programming language that wants to close gaps you feel in Rust's ecosystem.

There are two major resources provided in this community at time of writing: the NYAR ecosystem list and issues in the NYAR tracker.

The List

This README is a list with a twofold purpose:

• 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!

Issues

NYAR's issue tracker can help you get ecosystem gaps filled when you participate in:

• Voting on your favorite issues to let people know you'd use something, optionally commenting and explaining your use case.
• Placing bounties on issues you're particularly passionate about, since issues are where BountySource integrates! We use the bounty tag to indicate which issues have bounties associated.

Table of contents

• Documentation
  • Stack Overflow
• Libraries
  • Character encodings
  • Computer Vision
  • Data processing
  • Data structures
  • Dynamic programming analysis
  • Embedded development
  • Game development
  • Geometry
  • Geospatial Information Systems
  • Machine Learning
  • Mathematics
  • Native desktop application integrations
    • Microsoft Office
  • Parsers/Emitters
  • Personal information management
  • Rust Toolchain
  • User Interfaces
  • Web bindings
    • Google API
  • XML

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!

Character encodings

• Full support for cp437 (see this issue). Implemented here!
  • More fully-featured encode/decode libraries like encoding and encoding-rs exist, but don't support this currently.
  • A decode-only library exists, the development of which seems to have stopped.

Computer Vision

• Some work has been done to create OpenCV bindings in cv-rs as well as automatically generating bindings like opencv-rust. Neither are very complete.
• Piston has imageproc based on image, but in their words, "This is very much a work in progress".

Data processing

• DDS library wiki
• HDF5 (see also Wikipedia and this Reddit post) A stable version of hdf5 crate has been released and is now available on crates.io.
• A good stream processing pipeline with back pressure doesn't yet exist for an asynchronous data processing pipeline
  • RxRust is an older attempt to implement this according to the reactive streams model -- it currently seems closest to this use case.
  • tokio and futures may be interesting components to use when building this.
  • New features soon to come in Rust like impl Trait will probably make developing something like this easier to develop and use.
• Bindings for pandoc A pandoc crate now exists with CLI bindings!
• Bindings for git-annex

Data structures

• A concurrent std::collections::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.

  dashmap is intended to fit this use case exactly.

Dynamic programming analysis/instrumentation

• Binary instrumentation tools like Intel Pin or DynamoRIO are useful for embedded applications. An ecosystem around them (which doesn't exist yet!) could include:
  • Bindings to the C APIs associated with existing applications (for instance, Intel Pin and DynamioRIO)
  • Libraries or applications implementing the features of the aforementioned in Rust

Embedded development

• MINIX support is nonexistent! still a WIP.
  • rust-minix is a WIP adding support for the Linux platform, which the author introduced with this blog post.

Game development

• Integration with existing mature game engines is poor at time of writing.
  • Unreal Engine has had some prior work accessible by making an Unreal account, but nothing has been made freely public at time of writing.
  • Unity3D currently has no published crates for Rust interop.
  • Godot Engine allows Rust interop via godot-rust. Authors' note on stability:

    The bindings cover most of the exposed API of Godot 3.2, and are being used on a number of projects in development, but we still expect non-trivial breaking changes in the API in the coming releases.

• No mature game engine written in pure Rust exists yet.
  • Part of a mature solution will need to include a rich and robust editor. Examples can include:
    • Unreal Editor
    • Unity Editor
  • Amethyst is active and has a roadmap for becoming production-ready. Halted development.
  • Bevy is a new project built with the learnings of the Amethyst project. See the roadmap here.
  • Fyrox is a 3D + 2D game engine which includes a full graphical editor, and an example 3D FPS game built using it.

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, the basics are there but advanced linear algebra is missing)
• Designing low latency DSP algorithms suitable for embedded use (common filters, analysis functions)
• Library for nonlinear dynamical or chaotic systems (solvers, numeric methods etc.)
• A pure Rust libm implementation. These are required to get math functions on #![no_std] platforms
  • The m crate has made some headway here, though it hasn't been maintained recently.
  • The libm crate is a port of libm functionality from musl and newlib to Rust, with the aim of eventually being merged into core.

Native desktop application integrations

Microsoft Office

• An interactive Visual Basic uses for scripting by using the COM interface, which I believe winapi supports.

Networking and Protocols

• AMQP 1.0 - While there are several libraries for AMQP 0.9.1, the AMQP 1.0 spec represents a significant departure from the previous version. fe2o3-amqp implements the AMQP 1.0 protocol for both client side and server/listener side.

Parsers/Emitters

• Ability to parse Registry.pol files from Windows machines -- implemented by this person!
• 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.
  • Bindings to the Python implementation of beancount do not yet exist.
  • An implementation of Beancount bindings, parser, and emitter in Rust is currently WIP, and contributors have been requested.
• There is no pure-Rust solution for QR decoding. The only other crate that handles QR decoding is the quirc crate, which uses C bindings -- implemented by @Wanzenbug and by @piderman, the latter of which was announced on Reddit. See the PR.
• The RData file format does not have a parser or emitter yet.
  • Currently, this formatted is implemented for the R language in the serialize.c module.
• There are no SGML parsers or emitters on crates.io at all.
  • This is mostly a legacy markup language used for legacy type setting and supported in applications like APP (AKA 3B2).

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.

Rust Toolchain

• A stable Rust interpreter does not yet exist, which would made code exploration easier.
  • miri seems to be a step in the right direction -- it just needs some love!
• No debugging experience offers integration with rustdoc, which would
• A rustdoc backend for generating zeal/ dash docsets is missing.

User Interfaces

• A mature framework for Windows native UI has yet to be established.
  • native-windows-gui at one point claimed to be approaching feature-completion, but is now unmaintained.
• Abstractions over native UIs for each platform have yet to be available in pure Rust.
• A good reactive UI library complete with event-driven state management comparable to Redux does not yet exist.
  • carboxyl looks like it may be a good fundamental building block for this.

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, as with google-apis-rs service.
• There is room for more idiomatic APIs for Google in general. google-apis-rs uses the Google Discovery service to expose 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
  • including the disabling of features with security implications like entity expansion bombs
• XML Schema validation
• XPath
• XQuery
• XSLT 1.0/2.0/3.0
• Option to preserve input style
• Is fast

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

not-yet-awesome-rust's Issues

Timely Dataflow as extra data processing resource ?

I'm not familar with this domain, but this project looks like a good resouce.

This project is something akin to a distributed data-parallel compute engine, which scales the same program up from a single thread on your laptop to distributed execution across a cluster of computers. The main goals are expressive power and high performance. It is probably strictly more expressive and faster than whatever you are currently using, assuming you aren't yet using timely dataflow.

• Timely Dataflow: https://github.com/frankmcsherry/timely-dataflow
• PageRank example: https://github.com/frankmcsherry/pagerank

TUI

Maybe as a sub-point to "user interfaces": The TUI story is not that great yet. There's cursive and some crates that provide views for it (table-, tree- and calendar-view), but the ecosystem around cursive has to get much better.

Eg.:

• Tree viewing for custom trees
• File explorer
• Serde-Like data representation and editing (JSON, TOML,...)
• a framework for tabbed containers, split screen, etc

All those should be libraries, of course. So that one only has to combine them for building a UI.

libraries to support parametric modeling and drafting

I would like to see 2D and 3D drafting applications written in Rust. I would be really pleased to see some robust libraries that some FOSS applications could be built on top of or maybe eventually use WASM to build a full featured web-based CAD application at least good enough for education (Sketchup is too much of a toy. Useful drafting isn't hard and doesn't need to be any more dumbed down). Stability always seems to be a problem with the software typically used now (even the expensive stuff), and I would hope Rust's features would be address some of those problems. The engineering (civil, mechanical, structural, etc.) problem domain in general could use some love.

`choose-your-xml-rs` is deprecated. Now what?

The XML section suggests right now to check ous choose-your-xml-rs, which is now deprecated. Is there another resource that can be used in the meantime?

Consider adding mentors and mentoring instructions for list items

Reading and writing of Office file formats

A use case that I frequently stumble upon is to import and export Office files. It would be fine to have one or several good libs to read and write OfficeOpenXML (Excel, Word…) as well as OpenDocument (Sheets, Writer…) files. A bonus would be to have the same representation for the different formats of the same document type (Excel and Sheets), so it could easily be used to import and export the same data structure from/to either format, as well as perform conversions between them.

PIM libraries

If I understand correctly, we are encouraged to propose new entries in the README? If yes, ... here we go:

Mail

• There's lettre_email for building emails, but there's no high-level library for parsing email (The email crate is rather low-level IMO).

• There's no library for transparently handling Maildir and/or mbox

Contacts

• There's vobject which handles contact files (vcard). There are several others, but after evaluating it seems that vobject is the best one. Though it lacks a nice high-level interface (I contributed the foundation for a nice high-level interface, but did not have enough time for polishing yet).

Calendar

• The vobject crate also handles calendar stuff, though the same as above applies: The foundations for a high-level interface are there, but it is not polished yet.

Ledger

• This is a bit more niche: I would love to see a parser and high-level interface for beancount syntax/data

Parser for Media-formats

(I did not do a lot of research on this one, TBH)

• A Parser and Interface for reading/writing MP3 metadata (or any audio format)
• A Parser and Interface for reading/writing Movie format metadata

Weather data / news

(I did not do a lot of research on this one, TBH)

• A crate for reading weather data, possibly from different sources
• A crate for reading news data. I guess this is mostly done via RSS, so a high-level RSS reader would be awesome (as library)

The larger goal

All my proposals here are focused (in one way or another) on Personal Information Management (PIM). That's because I develop a PIM suite for the commandline (but extensible to TUI/GUI/WUI). If anyone wants to develop (for example) a ledger, todo-tracker or workout-tracker, they are more than welcome to contribute, so we can join forces. The framework which I developed in the last two years is rather stable and can be used today to develop PIM tools!
Just talk to me: https://imag-pim.org / https://github.com/matthiasbeyer/imag

---

I'll file an PR to update the list, if you want!

Ideas for a Rust binding in LibreOffice GSoC wiki page

I just stumbled over the Rust UNO Language Binding section in the LibreOffice GSoC wiki page. I think it would be great to put a link to the idea description into the Office document section.

(Official like) Google Client Libraries

The Google client libraries are used in Google Cloud Platform to manage resources.

Rust has a library which solves this particular use case google-apis-rs but it is not beginner friendly to use. It is autogenerated using Google Discovery Service.

And the new & official way to create user-friendly APIs is to use googleapis to autogenerate. It uses grpc which has Rust implementations at 1 & 2 though they are still under development and would require much effort to bring it to feature parity to the official one. (Also a complete grpc would benefit micro-services server-client architecture.)

I would help because I require this but I don't know how it works and I am a beginner at Rust. It is needed, to use Google cloud storage for my Rocket app.

Code page 437 support for exchanging data with legacy DOS applications

I need code page 437 encoding/decoding support for exchanging data with applications running inside DOSBox, DOSEMU, and my retro-computing hobby machine. (eg. for generating menus using .bat files containing box-drawing characters or for reading the contents of text files included with or generated by applications.)

Likewise, I'm sure there are legacy systems out there still running DOS on real hardware. (While not an example likely to result in Rust code, my local non-chain used games store still uses a DOS-based point-of-sale system.)

I researched this, but could only find encoding/decoding libraries without cp437 support and a single decode-only cp437 implementation with an uninspiring README that typos it as cp537 in the same screenful which also says cp437 twice.

I can't remember whether it was encoding or encoding_rs but, last time I investigated this, I came away with the impression that "the most ideal-in-the-abstract place to add support will turn away pull requests for code pages beyond those listed in the WHATWG Encoding Standard".

As-is, my best option is to write a stub in some other language like Python or Free Pascal (the latter being the most typesafe thing I know aside from Rust) which is responsible for doing UTF8<->CP437 conversion and parsing/serializing whatever format is used inside the DOS environment... which really hurts the case for using Rust at all in my own projects in this sphere, when any GUI I write is likely to be PyQt-based.

General Compression Library?

Is there a library which handles the varying compression formats automatically? As in, pass a std::io::Read in and it produces a Result<Decompressed,CompressedIOError> or whatever?

"fully-featured" concurrent maps?

Inlined from this Reddit reply on the introductory /r/rust thread:

I couldn't find any fully-featured concurrent maps. They all seem to have some missing parts, like lookup given a borrowed key.

AMQP 1.0

Have been futzing with AMQP at work. Noticed that there's a few 0.9.1 libraries for Rust, but none for the 1.0 version.

My understanding is that the protocols are significantly different.

Move "ready-to-write" content to `request-for-implementation`

Link to @dtolnay's repo: https://github.com/dtolnay/request-for-implementation

This list should more focused on identifying larger gaps in the ecosystem and places where things like working groups might be appropriate. We should move the "ready-to-write" content -- that is, crates where design can be elicited here and now and really just need to be implemented -- over to the request-for-implementation repo.

What is there to move? A running list will be added here and the issue will be closed once I feel satisfied that the "ready-to-write" stuff is moved over.

StackOverflow: many Q&As aren't very up-to-date!

Quote from @bheklilr on Reddit:

I don't know if this is something that really belongs on this list, but I will say that as a novice rust user I often run into the problem that stackoverflow Q&As/blog posts/etc are from 3 or 4 years ago and the solutions presented there are no longer valid with how much Rust has been updated. I'm not sure what the solution would be, but maybe it could involve putting together a task force to go through and provide updated answers to the most popular questions on SO, finding popular blogs and seeing about getting them updated/deprecated/rewritten, that sort of thing. This would be a lot of effort that wouldn't be terribly visible to people already in the community, but it would be a boon to newcomers. Rust's documentation is great, but it doesn't always have direct answers to a lot of questions asked by noobs like myself. There isn't as much community content, and unfortunately a lot of it is outdated to the point of not even being syntactically correct. This can definitely cause headaches for people trying to get started with Rust.

Concurrent hash map?

Would crossbeam's concurrent hashmap satisfy the concurrent hash map item? https://docs.rs/concache/0.2.1/concache/crossbeam/index.html

XAML parsing support

XAML parsing support is currently missing.

JsonSchema

Does not currently exist for rust - it might be useful.

Streamlining running examples

A large part of my workflow is to clone a library (say rust-sdl2) in a /tmp/ folder, open a new tab in that folder, and call cargo --example on one of the listed examples, then go back to what I was doing.

A cargo plugin (and maybe a feature later on) allowing to run cargo example rust-sdl2 example-n1 that would just work, without having to create a whole folder ourselves, and maybe even caching large libraries, would be a godsend.

If it is made part of cargo itself, trying out a crate becomes even faster. Anyone can just write in their repo: call cargo example mylib example-n1 and be over with it.

Some sandboxing might even be added for more safety.

ReactiveX / Rx / FRP

Rx(Reactive Extensions) is quite popular library available in many different languages, there have been attempts in the past to port to Rust but they've not quite taken off(either not enough interest, contributors or language barriers such as async not being well supported at the time).

RxRust issue suggests that things can be better now with tokio and futures support, as well as futures stream module?(streaming iterators being a desirable feature I and others have been looking forward to in Rust where regular iterators are not appropriate)

Carboxyl, which seems like a good crate trying to offer this points out that Rust lacks decent support for creating declaritive UI components that'd benefit the most(ala React/React-Native equivalent). They later discuss some crates that are offering declaritive UI and that the Async story is better now but their crate would likely need a re-write.

You also have something similar, known in Clojure as Transducers, two Rust crates try to offer this: https://github.com/ruuda/transducers
https://github.com/benashford/rs-transducers

Both haven't been touched since May 23 2016, I haven't personally tried them but assume they're out of date or could be improved on(rs-transducers mentions some limitations they had at the end of their readme). The first repo links to this youtube video to explain Transducers. They seem quite similar to chaining methods with an iterator, you can compose a series of methods as the video shows making good use of reusability.

I recall working on a project in the past where I wanted to compose some functions together but couldn't do it well with Rust and my knowledge at the time. The above would possibly have helped on the project, or streaming iterators(large amount of computation and data with unknown length/completion time that would process chunks of data), trying to support composable function variants based on settings/parameters was difficult to figure out(I think due to lifetimes or other compiler issues with typing/inference). Impl Trait and some other features on their way would help with my issue and perhaps help improve these crates to provide a solid offering in Rust for those looking for Rust equivalent.

MINIX support

The embedded development section states that MINIX support is nonexistent, however I don't think that's true anymore. @ids1024 has been working on MINIX support with some success, for example getting ripgrep to cross-compile from Linux. His work is still work in progress, might worth a mention there though.

• https://github.com/ids1024/rust-minix
• https://iandouglasscott.com/2019/02/18/cross-compiling-rust-code-to-minix/

Potential content update: geospatial crates

https://www.reddit.com/r/rust/comments/8f92k6/a_few_geospacial_crates_ive_been_working_on/

Maybe switch to AsciiDoc for automatic TOC?

Per isaacs/github#215 (comment), this might actually be nice if this list ever gets big.

QR reading library?

This comment on the introductory Reddit post indicates there's a lack of QR reading libraries. In my own searching, I've found plenty of libraries to WRITE QR codes, but READING this seems to be a legitimate hole in the ecosystem.

However, I'm not sure what this exactly would entail, or even the original use case of this user. It seems that there's a QR decoder in this crate; it's the only crate that speaks of decoding that I can see, and it has a C dependency, so there may not be a pure-Rust QR decoding implementation either. I understand that a computer vision library would be required to read a QR code from an image in order to extract QR code to decode in the first place. Perhaps that's all there is?

I'll wait for somebody who knows more than I do to confirm this.

Voting functionality inside the list itself?

Would it even be possible to have a Github-auth'd voting button?

SSH client library

As I understand, Thrussh is a full implementation of SSH, both client and server. It is fully in Rust except for cryptographic primitives.

[Documentation] Extensive comparison of hash functions in the Rust ecosystem

There should be an extensive comparison of all available hash functions in the Rust ecosystem. This should preferably be a repository that has the overview in the README and contains all related things (e.g. benchmarks).

Currently, it's a bit difficult to decide between Sip, Fnv, Fx, Seahash and many others.

The comparison should contain a bunch of data about each hash function:

• Is there a crate that allows me to very easily use that hash function with std::collections::HashMap?
• Main purpose? (E.g. mainly for small keys in a HashMap, or mainly to hash large data like files, or mainly to hash passwords in web applications, ...)
• Quality of the hashes:
  • Cryptographically secure?
  • Secure against DOS/collision attacks?
  • Some other metric about quality. I don't know a lot about this, but I guess there are some standardized tests/metrics for hash functions.
  • Is this a well-known hash function or something that was hacked together by the crate author?
• Speed. There should be several benchmarks for several situations. Ideally (although elaborate) the benchmarks would be run on different systems.
  • Just hashing: multiple benchmarks for different data lengths (1..16 bytes, 24 bytes, 32 bytes, ... 1024bytes ...)
  • Using the hash function with a HashMap in various situations. Also different kinds of keys: integers, small strings, ...

I hope this non-crate suggestion is welcome here!

First-class debugging

This issue is being made in response to /u/edapa on the Rust Reddit:

The biggest gap for me is a first class debugger (rust-gdb is nice, but not all the way there)

It would be best to actually enumerate what's missing -- otherwise, it's hard to list actual use cases associated with this. However, it sounds like there's potential already, and that thinking of those features shouldn't be hard!

How does `metrix` affect the current list?

https://docs.rs/metrix/0.9.4/metrix/

Organize a bounty system for list items and/or requests via issues

A language spec !

An (even incomplete and informal) language specification document can help people understand the concepts and details of the language. It will aid the documentation of libstd in many ways.

Redux like state management crate?

I've come from a web dev background, while I understand Rust isn't quite there for heavy web dev yet(still seems to be trouble in providing an http server that can upgrade connections to websockets on the same port for example), I really did enjoy how Redux worked.

Rust seems to prefer composition and this is something Redux is all about with it's reducers. Middleware support also made it quite powerful and is great to use with React(bit too big of an ask to see a Rust port). IIRC Redux was touted on release as being quite a small library(around 100 lines of JS), yet was great to work with modern JS(ES6+).

Perhaps it worked so well because of JSON being native to JS(where other languages are not as seamless/enjoyable to use JSON), and that it's a dynamic scripting language(which I guess conflicts with Rust being strongly typed and compiled). In Rust I suppose this would be some sort of combination of nested structs or data structure to support the state tree.

I remembered seeing some implementation attempts back in 2016 but they ran into some roadblocks. It seems someone made some progress here with rust-redux, so perhaps it's in a better state now and just needs good middleware(the browser debug tools were pretty good, not sure if they could be used with Rust to do time travel of state).

I found this most useful for state management of UI part of software. As state would change via reducers, binded data would update in React UI without additional work by the developer that other UI frameworks did to connect/bind state to the UI, often causing complications, bugs, debugging woes. Going through an introduction of how Redux works probably explains this better than I can :)

Registry.pol parser thingy implemented

I found this, looked at the format spec, and implemented it.

QR decoder implemented

I ported the C library linked in #17 and used by the quirc crate to rust. Link here

Its not a 1:1 port as the interface is quite C-ism heavy so I set about cleaning it up a bit. Its still not finished but from my limited tests it works well enough.

Would be happy to receive some feedback 😄

What should the NYAR logo look like?

Individual ideas will be listed as comments for voting unless the discussion gets out-of-hand. :)

Is `concache` significant for the concurrent data structures?

https://github.com/saligrama/concache

I think that @stjepang might be interested in commenting here. :)

Is `metered-rs` significant for the metrics libraries?

https://github.com/magnet/metered-rs

Maybe relevant to #3.

A pure Rust full SSH client equivalent

A pure Rust full SSH client equivalent to Go's implementation

I wanted to use Rust for writing an application that can send commands to a fleet of servers over SSH. But, it doesn't look like there is an official pure Rust solution. I understand there are ssh2-rs (wrapper over libssh2 written in C) and Thrussh(not a feature complete client equivalent to that of Go SSH). It would be awesome to have an official Rust SSH library.

cp437 crate implemented

I found #21 and implemented it, and @ssokolow, the main promoter, seems, despite apparent chronic fatigue, to be relatively satisfied with the implementation.

Some more exotic ideas...

Full disclosure: I'm not even a Rust user right now, so I kind of am an idea guy here. If you feel this issue is a waste of your time, don't resist deleting it. ;)

• Since an XML parser is already listed, I give you... SGML. I know it's basically dead and you won't find one to write a parser, but to my knowledge at least some publishers still used this format about ~5 years ago, maybe they still do. Most likely you'd do legacy support. The one repo I found seems to be dead.
• for the XML wish list: XSLT 2.0 support, options to control XML whitespace behavior (like for preserving whitespace), options to disable all XML footguns like entity bombs
• a library that helps implementing GUI libraries (offers OS callback based event handling, unlike SDL2 or SFML, offers drawing primitives, text, images, so you don't have to mess around with OpenGL, Vulkan or other low level backends, helps with different ppi numbers?)
• parser/operations API/renderer for PCRaster maps (category GIS or spatial modelling)
• likewise a parser for Rdata files (statistics/modelling)?

SSH seems to be implemented

SSH client library now exists. https://crates.io/crates/thrussh

Description and philosophy: https://pijul.org/thrussh/

Latest status update for Thrussh: https://pijul.org/2017/12/06/thrussh-0.17/

Metrics libraries can match something like Java's `codahale` library?

Link: http://metrics.dropwizard.io/4.0.0/manual/core.html

Mentoring instructions

For anybody looking at this issue, the most helpful thing here would be to figure out what use cases the codahale libraries in Java can accomodate that others can't yet. The most developed libraries in Rust in this domain seem to be:

• metrics, which seems to be modeled on codahale
• tic

There are probably others. The work associated with this issue is to figure out:

• What's out there
• How it's different from what something like codahale has to offer
• If there's something that the Rust ecosystem can't do yet for metrics.

What relation does Reducer have to the reactive computation gaps?

https://github.com/brunocodutra/reducer

Dynamic program analysis domain?

Basically, there's not much in this domain right now. But what can we tell others to give them a good reference of what feature set to implement?

See this Reddit reply to the introductory post for /r/rust:

Definitely an instrumental tool like Intel Pin or DynamoRIO. My big dream...

GUI crate (Part 1: using native controls)

A uniform abstraction and API above native controls solution on each platform.
There are some crates, just not awesome yet.

"Inheritance, or some inheritance-like construct"?

Originally requested on Reddit here.

I think I can see several use cases for this with UI work specifically, though there are alternative techniques used in C and some Rust libraries already. For example, I know that GTK-rs uses the functionalities that the glib library already provides for manually constructing what amounts to a vtable.

XML technology stack

Some crates in this field do exist, however not in production ready state.

• General purpose DOM tree.
• Proper ncoding handling.
• DTD handling.
• XML Schema validation.
• XPath
• XQuery
• XSLT

GUI crate (Part3: Using web technology)

Production ready GUI using web technology, with support for HTML dialog etc.

Seems libservo is the way to go?

Update: native-windows-gui crate is not maintained any more.

According to its readme.md in the repo.

Generation of Dash docsets

While it is not a backend for rustdoc, there is https://github.com/vhbit/rust-docset to generate docsets form any Rust documentation.

Even if it is not the exact same thing, the list asks for, I think it would be worth to mention rust-docset as a possible solution.