Since many years, we are offering pre-built binaries for the Red toolchain, as a more convenient way to use Red, even if it is not strictly needed, as Red can be run from its sources, the toolchain being run by a Rebol2 interpreter. As the Red REPL and toolchain are not run by the same engine, the console (REPL) used to be compiled on first run of the `red` executable (when no arguments was provided or a Red script was passed). This resulted in a significant delay on the first use of the console (both for the GUI and CLI versions).
We have now decided to change that by providing separate pre-built binaries for the consoles and toolchain. This is a temporary split until Red gets self-hosted, at which point we can recombine everything into a single binary.
Another change is the temporary dropping of the semantic versioning until version 1.0 and related "stable" releases, as it seems to be too confusing to some users (Red being still in alpha stage). This also will remove a tendency from some users to care more about version increments than feature availability and work being done overall. We will now be proposing only pre-built binaries for latest commit, though older binaries will still be available if that can be of any help to anyone.
So the pre-built binaries now are:
Red GUI : Red interpreter + View + GUI console
Red CLI : Red interpreter + CLI console
Red Toolchain : Encapper for Red + Red/System compiler
We are also considering ways to merge the GUI and CLI consoles into a single binary which can work even if no GUI API is available, falling back on CLI mode. We will also have the console(s) act as a front-end for the toolchain, even downloading it for you in the background when needed. Though for that we need a proper asynchronous `call` function implementation. More news about this soon.
In the meantime, enjoy running Red consoles almost instantly from just a click on the Download page!
You cannot have missed that in the last months (and even last years), our
overall progress has slowed down drastically. One of the main reasons is that
we have spread our limited resources chasing different objectives while making
little progress on the core language. That is not satisfying at all and would
bring us most likely to a dead-end as we exhaust our funding. We have spent
the last weeks discussing about how to change that. This is our updated action
plan.
From now on, our only focus will be to finish the core language and bring it
to the much-awaited version 1.0. We need to reach that point in order to
kickstart a broader adoption and provide us and our users a stable and robust
foundation upon which we can build commercial products and services necessary
for sustainability.
Given the complexities involved in completing the language and bringing an
implementation that can run on modern 64-bit platforms, we have devised a
two-stage plan.
Upgrade the current 32-bit Red implementation
👉 Language specification
It is now time to do so in order to clean-up some semantic rules and address
all possible edge cases which will help fulfill our goals of implementation
robustness and stability. The process of writing down the complete language
specs will result in dropping some features that we currently have that end up
being problematic or inconsistent. OTOH, we might add some new features that
will need to be implemented for 1.0.
👉 Modules
We need a proper module system in order to be scalable. We also need to have a
proper package management system which will be tied to a central repo where we
can gather third-party libraries. That would also enable modular/incremental
compilation (or encapping) which will be most probably supported in the
self-hosted toolchain.
👉 Concurrency
We need a proper model for concurrent execution in order to leverage multicore architectures. We will define one and make a prototype
implementation in the 32-bit version.
👉 Toolchain
Before starting to work on the new toolchain, we will make some changes to the
existing version in order to prepare for the transition. The biggest change is
the dropping of the Red compiler, which will only act as a (smart) encapper.
Routines and
#system directives will still
be supported, but probably with some restrictions. The Red preprocessor might
also see some changes. This change means that Red will only have one execution
model instead of the two it has currently. The Red compiler has become more of a burden
than a help. The speed gains are not that significant in real code (even if
they can be in some micro-benchmarks), but the impossibility for the compiler
to support the exact same semantics as the interpreter is a bigger problem.
This move not only will bring more stability by eliminating some edge case
issues but also will reduce the toolchain by almost 25% in size, which will
help reduce the number of features to support in the new toolchain.
👉 Runtime library
Some improvements are long overdue in the Red runtime library. Among them:
unified Red evaluation stack.
unified node! management.
improved processing of path calls with refinements.
improved object! semantics.
All those changes are meant to simplify, reduce the runtime library code and
address some systemic issues (e.g. stack management issues and GC node leaks).
👉 Documentation
We need proper, exhaustive, user-oriented documentation for the Red core
language. This is one of the mandatory tasks that needs to be completed and
done well for wider adoption.
Self-hosted Red for 64-bit version
👉 Toolchain
In order to go 64-bit, we have to drop entirely our current toolchain code
based on Rebol2 and rewrite it with a newer architecture in Red itself. The
current toolchain code was disposable anyway, it was not meant to live this
long, so this was a move we had to do for 1.0 anyway.
linker support for 64-bit executable file formats for the big 3 OS.
support for linking third-party static libraries.
32-bit backends will not be supported in 1.0, though, they could be added back
in the future.
👉 Runtime library
The current Red runtime library written in R/S will be kept and some
adjustments will be needed in order to be fully compatible with a 64-bit
environment (like updating all imported OS API to their 64-bit
versions).
View engine will not be part of that upgrade for 1.0, but will be done in a
1.1 version, priority is given to Red/Core for the 1.0.
Roadmap
Here are the main milestones:
v0.7 : Full I/O with async support.
v1.0b : (beta) completed self-hosted Red with 64-bit support.
v1.0r : (release) first official stable and complete Red/Core language release.
v1.1 : View 64-bit release.
v1.2 : Android backend and toolchain release.
v1.3 : Red/C3 release.
v1.4 : Web backend for View release.
v2.0 : Red JIT-compiler release.
v3.0 : Red/...
The 0.7 should be the last version for the 32-bit Red version and current
toolchain and we will be working on that first.
For reaching the 1.0-beta milestone, we target 12 months of intensive work, so that will bring us to Q3 2023. That's an ambitious goal but necessary to reach for the sake of Red's future.
The currently planned beta period for 1.0 is 2-3 months. We want a polished,
rock-solid, production-ready 1.0 release.
For the 1.1, we will probably make some (needed) improvements to View engine
architecture and backends.
For Red/C3, as the Ethereum network is transitioning to 2.0 and a new EVM, we
need the WASM backend in order to support it.
Version 1.4 will bring a proper web runtime environment to the WASM backend,
including GUI support.
The 2.0 will be focused on bringing a proper JIT-compiler to Red runtime, that
should radically improve code execution of critical parts without having to
drop to R/S.
Version 3.0 is already planned, but I will announce that once 1.0 will be
released. ;-)
One major platform is missing from the above plan, that is iOS. Given how
closed that platform is, we will need to come up with a specific plan on how
to support it, as it won't be able to cross-compile for it (you would need a
Mac computer), nor probably generate iOS apps without relying on Xcode at some
point (not even mentioning dynamic code restrictions on the AppStore), which
are layers of complexity that Red is trying to fight against in the first
place... So for now, that platform is not among our priorities.
To finish, let me borrow some words from someone who succeeded more than
anyone else in our industry:
Expect me to say "no" even more so from now on, as we get laser-focused on our
primary goal.
