Feature #12525: Get some inspiration from the Red programming language!

• Status: Closed
• Assignee: -
• Target version: -

I know this is probably not the right place for a this, but I love Ruby and I can't resist sharing the following information with you, hoping that it will sparkle something interesting in the Ruby language development community.

On March 25, 2016 the 0.6 version of the Red programming language was released.

Why am I even talking about this? Because Red has the most interesting set of features and tooling packed together in a single language/runtime that I've probably seen so far.
Looking at Red features and code samples it appears to be also incredibly simple and convenient to use.

My dream would be having a language like this, but with the Ruby syntax, Ruby OO model and Ruby dynamic features.

Look at some of Red features:

Red features:

Functional, imperative and symbolic programming
Prototype-based object support
Homoiconic (Red is its own meta-language and own data-format)
Optionally typed, rich set of datatypes (50+)
Both statically and JIT-compiled to native code
Concurrency and parallelism strong support (actors, parallel collections)
Low-level system programming abilities through the built-in Red/System DSL
High-level scripting and REPL console support
Highly embeddable
Low memory footprint, garbage collected
Low disk footprint (< 1MB)

Red comes with a interpreter in addition to the compiler, which can be easily accessed using the built-in REPL.
If you are running Red from Windows, you can also use the built-in GUI system. Yes, GUI programming can be that easy!
You can also compile your Red programs and get a single binary with no dependencies.
You don't have to install anything else, the Red binary you have downloaded already contains a complete toolchain for native compilation!

Cross-compilation support:

Here is a list of currently supported platforms:
MSDOS : Windows, x86, console (+ GUI) applications
Windows : Windows, x86, GUI applications
WindowsXP : Windows, x86, GUI applications, no touch API
Linux : GNU/Linux, x86
Linux-ARM : GNU/Linux, ARMv5, armel (soft-float)
RPi : GNU/Linux, ARMv5, armhf (hard-float)
Darwin : MacOSX Intel, console-only applications
Syllable : Syllable OS, x86
FreeBSD : FreeBSD, x86
Android : Android, ARMv5
Android-x86 : Android, x86

Major new features of version 0.6:

View engine, with Windows backend (from XP to 10)
VID dialect
Draw dialect
Reactive GUI programming
GUI console
Simple I/O support for files and HTTP(S) queries.
Codecs system with following codecs available: BMP, GIF, JPEG, PNG
Objects ownership system

http://www.red-lang.org/

I just hope this can trigger something here!
Thank you!

• Subject changed from Get some inspirations from Red programming language! to Get some inspirations from the Red programming language!

• Subject changed from Get some inspirations from the Red programming language! to Get some inspiration from the Red programming language!

[shevegen (Robert A. Heiler)]

Reactive Programming:

"It is a way to link one or more object fields to other fields or global words, by specifying relationships in a block of code (can be a single expression or a complex multi-step computation)."

I do not even understand what this means.

Does this mean to take a method from object A to object B and have both coupled?

If so, I assume that this is somewhat close to inheritance already, perhaps more
free.

Your request here is also not really good because the "inspirations" are not really
easily applicable. I mean you did not make any specific suggestion as to WHAT ruby
specifically SHOULD learn now there.

The best descriptions in the world also do not mean much as long as you do not have
a really functional language that is used by many different people. Python is there,
perl is there, php is there, ruby is there. I don't think that Red is there at all
yet.

Robert A. Heiler wrote:

I do not even understand what this means.

Well I have not yet investigated this, but the sentence you mentioned is coming from the Red blog post http://www.red-lang.org/2016/06/061-reactive-programming.html
which seams to feature comparisons and examples of reactive vs non-reactive in Red. Maybe you just read that sentence alone taken out of context somewhere else?

The best descriptions in the world also do not mean much as long as you do not have a really functional language that is used by many different people. Python is there, perl is there, php is there, ruby is there. I don't think that Red is there at all yet.

I don't think that Red is there at all yet.

I did not say "let's copy what Red did" but just, let's all get inspired by some parts of it.

For example, the view engine directly integrated into the 1 Mb interpreter ?
Ruby could probably benefit from something like that too, if only for the appeal that this feature would have on new users.
And that's probably the less important thing I could mention (but works good as an example).

I am not saying Red is the greatest language ever, why would I? And why are you setting yourself on the fully defensive mode?

I'm just saying, these guys had some great ideas (and have implemented many of them) and it's already interesting because some of those working features at exactly where Ruby is failing... I know Red and Ruby are two different beasts and you can't automagically transform MRI in a AOT compiling language, nonetheless there are some concepts that IMHO could be interesting building on!

Also, from a philosophic point of view, Red is very close to Ruby: it tries to keep simple things simple (look at what you can do with very simple code examples http://redprogramming.com/Short%20Red%20Code%20Examples.html ) and so, although I haven't seen this mentioned on the website, Red seems to want to be here for the developer happiness too. That's the closest to Ruby I can think of ATM (not considering just the syntax, but the full tooling! And mindset).

So Since we share this view, why not just keep as open eye and learn from it, wherever possible?

[naruse (Yui NARUSE)]

• Status changed from Open to Closed

Could you separate into tickets each specific feature?

Issues on a issue tracker should have a specific goal to close.
And Ruby's feature request should have concrete real use case.

Note that ruby-core ML is open to such an abstract topic.