Skip to content

Roadmap

Jump to bottom Edit New page
Ary Borenszweig edited this page Aug 5, 2015 · 29 revisions

Roadmap

This roadmap defines the things that we definitely want to have in the language and plan to do. It can grow over time, but it can only shrink once we do the tasks.

Language

Stuff that has to do with the language syntax, semantic and runtime.

Concurrency support

  • Define how to do channel select
  • Fix/check IO.select
  • Fix/check Process.run
  • Run fibers on multiple threads, with a single IO loop and job stealing
  • Add concurrency primitives like WorkGroup
  • Implement context switch in assembly
    • For 32 bits
    • For 64 bits

Process execution

Platform

Stuff that has to do with where and how Crystal runs.

32-bits support

Tools

Built-in tools integrated to the crystal command.

Package manager

Crystal will provide a built-in package manager. We really want this to be the only package manager so it's easier to build a collaborative community.

We want a truly decentralized package manager. These ideas could make it work:

  • No global directory where all deps are installed: it's local to each project (lib/libs directory)
  • Each repo has a special branch (maybe _releases) with metadata for dependencies for each version. These are cummulative, so version 0.2 contains metadata for 0.1 and 0.2.
  • Crystal provides a command to release a new version, pushing to that special branch, and creating a tag
  • Use Semantic Versioning
  • Automatically download recursive dependencies
  • Resolve conflicts
  • Remove Projecfile, use YAML, both for project.yml and for the metadata file
  • Include name and version in project.yml
  • The name above is used for the directory in which it is installed, and used by require "...", so for example "webmock.cr" will be installed in "lib/webmock", and that directory will contain the direct checkout of the project (so it has the src directory in it)
  • The require logic changes to that if you do require "foo", we check if there's foo.cr in CRYSTAL_PATH, or foo/foo.cr, or foo/src/foo.cr (this last one is the one that will be used for dependencies installed via the package manager). With this logic, the current CRYSTAL_PATH value doesn't need to change
  • Probably rename "libs" to "lib"

With the above, when you do crystal deps install, all first-level dependencies are gathered. From there we go to each depednency's repository and check out the special _releases branch to get all metadata for all versions of that first-level dependency. We apply this recursively until we get all the metadata for all involved libraries. The previous process should be fast, because only that metadata branch must be checked out, and only once for each library (and we can parallelize the requests). Then we can solve conflicts and install what's needed.

For discoverability, we can list github/bitbucket repositories that have crystal code and that also have that special _releases branch, which in turn contains all the information for every version of the library.

For all of this, the easiest thing would be to build on top of @ysbaddaden's shards, which already has the desired YAML format, probably has some logic for semver, etc.

Automatic build/run

It would be awesome if you could download a project and just do crystal build or crystal run without arguments, and that builds/runs the default executable.

For this, we can use the name of the project (specified in project.yml) and use ./src/{{name}}/{{name}}.cr.

This argless version also executes crystal deps, so that doing crystal build/run works out of the box (given you have the necessary dependencies).

Docs generator

  • Improve the docs viewer
    • Nicer style
    • Allow searching
    • Show inherited methods from superclasses and included modules
    • (optional) Don't use HTML frames because they are deprecated/discouraged
  • Support inter-linking between docs (we can start with http://www.docrystal.org/)
  • Allow specifying a different README for the docs (so that we can, for example, have a better intro for the standard library)

Debugger

This section needs to be defined.

Standard library

Stuff provided by the standard library. If you wish to tackle some of these, please let us know! But first open an issue so we can discuss the best way to do it (and we'll link the issue in this page.)

Some types listed here might already exist but have incomplete functionality, or must be reviewed (we might need to mark this in the code somehow, similar to how, for example, Rust does it.)

  • zlib (integrate @datanoise's, eventually)
  • openssl (integrate @datanoise's, eventually)
  • File
  • FileUtils
  • IO timeout
  • Encoding support
  • HTTP::Client streaming
  • HTTP::Server streaming
  • WebSocket
  • Time
  • TimeSpan
  • TimeWithZone
  • TimeZone
  • Logger
  • FTP
  • SMTP
  • DB interface
  • Random interface
  • SecureRandom
  • JSON
  • XML
Add a custom footer
Add a custom sidebar
Clone this wiki locally