December 19, 2015

Answers to community questions

Features, future directions

Will Red get lisp like macros?

The short answer is: yes, but.... We first need to define how we want the API for macros to look like and how to prevent users from shooting themselves in the foot too easily using them. Also, macros are challenging for a visual debugger, we also need first to have a clear vision of how an IDE would handle that (I have not yet looked into how top Lisp IDE managed that, though I hope they have solved it elegantly).

About the ETA, we had a strong need for macros in our Android bridge, though that need might be gone now that Red's startup time has been vastly improved earlier this year. Answer to that should come in a few weeks, once we merge the existing Android backend with our new GUI engine.

When will Red get optional types?

It already has, along with multi-typing: you can specify one or more allowed types for function arguments, return value and local words. Only arguments type-checking is implemented for now, the rest will come on the path to 1.0. The most interesting part of optional typing is how much the compiler will be able to leverage it to generate much faster code when everything is mono-typed. Though, we will find that out after 1.0, once we will work on the self-hosted compiler and toolchain. As the current toolchain has a limited lifetime, we try to avoid any non-mandatory feature before 1.0.

Will Red have built-in support for some type of concurrency and/or parallel processing? What kind of model is it going to follow?

Certainly. Increase in computation power is now horizontal, with multiple cores, multiple processors and distributed architectures, so, strong concurrency support is a key part of a modern general-purpose language.

For now, the model we aim at is the Actor model. It is a good fit for Red and would provide a clean way to handle concurrent and parallel tasks across multiple cores and processors. Though, a few years has passed since that plan was made, so we will need to revisit it when the work on 0.9.0 will start, and define what is the best option for Red then. One thing is sure, we do not want multithreading nor callback hell in Red. ;-)

Do you plan to implement any kind of app/web server in Red, similar to Cheyenne available for Rebol?

As Cheyenne's author, I have strong plans for a new web application server with much better scalability than what you could achieve using Rebol. Red 1.0 should come with pretty strong server-side programming abilities out of the box, then on top of that, we'll provide a modern framework for webapp creations (think GWT or Opalang-like approach).

In addition to that, we'll have a Cheyenne RSP compatibility layer for running old Cheyenne scripts aiming at at drop-in replacement for existing webapps.

Will Red support multiselect/switch soon?

As soon as possible, maybe for the upcoming 0.6.0 release.

Will we get promises/futures in Red?

Possibly. We will experiment with that in one of the 0.7.x releases. We will have to see how such abstraction could integrate in our future concurrency model.

Will Red get direct access to Android's (and IOS later) camera, location, gyroscope, etc features?

Absolutely, our GUI engine already features a camera widget (in our Windows backend). The work on Android backend in 0.6.x version will bring wrappers to all the common hardware features.

Red is going to get modules support in future, what about Red/System?

As Red/System is an embedded dialect of Red, Red's upcoming modules system will allow inclusion of Red/System parts, so a separate modules system for it is not necessary for now.

Will function! be first-class datatype in Red/System v2?

Strictly speaking no, as you won't be allowed to create new functions from Red/System at run-time (but you will be able to create new Red/System functions from Red dynamically). The other first-class features will be possible (to a greater extent than today): passing function! pointer as arguments, returning a function! value from a function or assigning a function! pointer to a variable.

Will Red have the equivalent of Go lang's net package?

Red will feature a complete networking layer in 0.7.0, including async IO support, through a nice high-level API (similar to Rebol's one). So DNS, TCP, UDP and many more common protocols will be built-in, fortunately, relying on a very lightweight API, unlike Go's net package. ;-)

What about a package manager (in future)?

We have a modules system planned for 0.8.0. Design details are not yet defined, though we'll strive to integrate the best ideas from other existing package managers around.

Is there going to be inbuilt unit testing, something like

We'll have a built-in unit testing support, probably starting with a lightweight one integrated into our upcoming modules system.

Is there a chance Red gets self-hosted sooner than initially planned, removing the R2 dependency?

Self-hosting Red means rewriting the toolchain (compilers, linker and packagers) in Red (currently written in Rebol2). Technically, 0.6.0 should have all the needed features for starting such rewrite, unfortunately, we currently don't have the resources to start such big task while continuing the work towards 1.0. The self-hosting work would not be a port of the current toolchain, it would use a very different architecture (because of JIT-compilation requirement and extra features of Red compared to Rebol). We aim at a programmable modular toolchain model, not very far from LLVM (just simpler and magnitudes smaller).

To be accurate, fully removing Rebol2 dependency is a two steps process:

  1. Removing the need for Rebol/SDK to build the Red binary, making it easy for anyone to rebuild Red binary from sources.
  2. Rewriting the toolchain in Red.

Developers, community, documentation

How do you regard the development of Red 2.0 to proceed in terms of speed/progress? Will it be faster or equal to current road to Red 1.0?

Red 2.0 is mostly about rewriting the toolchain in Red, which represents only 25% of the current Red codebase (the other 75% part is the runtime library). Moreover, the modular architecture and public API  of the new toolchain will make it much easier to write and integrate contributions from third-parties, so we'll gear all our efforts towards involving as many skilled contributors as possible. If you want Red 2.0 to come quicker, helping Red's user base grow up by contributing, writing apps, docs and tutorials is the best thing you can do right now. ;-)

What do you think is the "killer app" Red should provide, in order to attract more of developers/newcomers?

Definitely an innovative IDE. ;-) Beyond that, I believe that a successful Android app written in Red could do a lot to spread Red usage widely. If you have a great idea for such app, you'll soon be able to code it in Red 0.6.1, with full Android support.

What about documentation comments (something like rustdoc

In Red, like in Rebol, docstrings are allowed in functions (and in modules once we have them), so they can be processed more easily than comments (which exist only when the source is in text form). That's one of the tangible advantages of having an homoiconic language. That is also how the help command works in the console, it extracts information at runtime from functions and the environment.

That said, if you want heavier documentation embedded inside your code, you can easily define your own format for that and writing a preprocessor for it should be almost trivial using our Parse dialect (either in text form or after loading, in block form). You can go as far as implementing a Literate Programming layer if that suits your taste, like this one made for Rebol.

That's all for this time, if you want to discuss some parts deeper, you are welcome to join our chat-room on Gitter, which is way more convenient than Blogger's comment system.

See you soon for the 0.6.0 release, don't miss it! ;-)


  1. If Red wants an innovative IDE, the one to beat is the Leo editor. It's like Light Table and org-mode had a homoiconic baby. GitHub recently added it to its text editor showcase and it's possibly the state-of-the-art in fluidly connecting literate documentation to code that practically writes itself with mind maps. Red may be ahead of its time in wanting its own complete stack, but its philosophy of computational self-sufficiency from idea to machine code would go so well together with a non-Pythonic Leo.

    1. Thanks for the info. The innovations we are aiming at, are in a different direction, though, experiments like Leo are good food for thoughts.

  2. Congratulations on the upcoming 0.6 release! Looking at the Trello lists, it looks like garbage collection won't be added until 0.8. Until then, how are Red programmers handling memory management?

    1. Thank you! For now, until we get the full GC implemented, if you stick to a few simple rules, the memory usage remains low enough. For example, by avoiding doing frequent temporary allocation, especially in loops, or re-using allocated series as much as possible, using the `/into` refinement where available. So far, we don't really have big Red applications, nor server-side ones, so memory usage remains in acceptable ranges despite the lack of GC.

      By the way, there's also a `simple-gc` branch on github which implements a temporary GC while waiting for a more sophisticate one. In that branch, the GC is implemented, but needs significant debugging before being usable. So, we should have a backup solution before 0.8 arrives.

  3. This comment has been removed by a blog administrator.

  4. is there any plan for game develop? i think red is very nice for game develop

    1. I may have read online that Red 1.0 may be able to handle game development.

    2. Red can be used for game coding, though, currently it is not optmized for that domain. We will provide in the future (post 1.0) a proper support for writing fast 2D/3D games.

      That said, you can already write simple games using the GUI engine from master branch (Windows only for now).

  5. You really should take a look at this. The best way to learn about mistakes is to learn from others. It's about a system language called BitC. It's sounds very much like RED in it's ideas, sorta. The reason it's important to look at it it seems he was not able to pull it off and whatever problems he had might be avoided by you. He's done a lot of work at Universities and Microsoft on micro-kernals and other stuff and seems to know what he's talking about.

    Here's a link to wiki on bitC

    A link from that page to an explanation of what went wrong. He raises some issues that you may have already figured out.

    A link to BitC project that has some design goal info.

    And for shits and giggles Protothreads

    My apologies if this is irrelevant.

    1. Thanks for the links Sam. I know about BitC and protothreads. BitC is a system programming language, while Red is a fullstack language (from system to high-level programming and dialecting).

  6. Can you kindly put some tutorials on Youtube (latest stable) as many people are really interested in this programming language and there isn't too much material available. I think that will gain Red some well deserved interest. Good Luck!

    1. Thanks for the good suggestion. We are planning a series of learning videos, though, our resources are currently entirely focused on bringing Red to a decently usable level. Community support and help for creating learning materials like videos and documentation is mostly welcome.

  7. People at Red, Can I ask about new updates, looking at number of forks at github and how much material is available on line it looks like a toy project with no real life usage? Do you people have some material book like other languages have? Besides how it creates small forms is really amazing


Fork me on GitHub