Red Programming Language: Static linking support

56 points by em-bee a day ago

I'm a bit surprised that Red still seems stuck at 32 bits, like it was last time I saw something about it years ago. What is the roadblock that prevents them from building 64-bit binaries? I guess it must be very hard since otherwise it would have already been fixed.

em-bee - 2 hours ago

i think the holdup is the lack of self-hosting. probably the rebol compiler they use can only build 32bit binaries so self-hosting and 64bit support go together.
it's on the milestone for 1.0. and according to the roadmap 1.0 is a solid year of work. it's likely not the only thing they want to do for 1.0, but i guess self-hosting is a big chunk

fithisux - 6 minutes ago

And still here.

uticus - 3 hours ago

https://re-bol.com/short_rebol_examples.r for some examples of the language (from https://redprogramming.com/Home.html)

em-bee - 2 hours ago

i'd be curious if red can be used as a commandline shell. the syntax should work well with it. it may just need some wrapper functions to be able to call external programs, pass arguments to them and capture the output.
- klibertp - an hour ago
  Not sure why it wouldn't be usable for that:
  -▶ ./red-cli-066 --== Red 0.6.6 ==-- Type HELP for starting information. >> call/console "echo 123" 123 == 0 >> call/console "pwd" /home/cji/portless == 0
  `call` has a bunch of refinements (toggles or switches appended to the function name with a slash; I'm using /console to redirect output to the parent's stdout), but it's a pretty low-level interface. You definitely could define a few simple helpers and get to a usable Unix-like shell pretty quickly. You'd get native AOT compilation for all your shell scripts for free.
  The problem is that you could write those helpers in just about any language, and while Red has an edge over many due to the regular and simple syntax, it's by no means unique in that regard (TCL is an obvious alternative, Lisp-likes are also strong, and even Smalltalk could join the chat if you don't care too much about startup time). And 32-bit-only thing doesn't look good, even if it's not an actual problem in most cases.
  In short: it can, but why would you? (Don't get me wrong: I like Red! But with so many other interesting languages (if you're willing to look past TIOBE Top 20), it's hard to justify investing more time into learning Red in particular.)
  - ulbu - 29 minutes ago
    
    I think they mean red as a shell scripting/command line language.
    
    klibertp - 2 minutes ago
    
    All that shell scripting needs is the ability to spawn processes and connect their stdin/out/err together. Or at least, that's what distinguishes "scripting" from "shell scripting". Obviously, you can write a library (I like Python's Plumbum) in almost any language you like that provides this functionality conveniently. So, again: yes, Red can be used for that just as well as any other language (and, arguably, it may be better for this use than many others).
    For an interactive shell, you also need a REPL, which Red provides. So if you write that library for Red, you get the interactive shell for free.
    Yes, Red has many advantages: it can AOT compile to native, it's homoiconic, it has a built-in Parse dialect (so the library can be really ergonomic), the Red executable is tiny and starts up fast, it has native GUI capabilities (if you're in a Red-based shell and want to view an image, it's trivial to create a GUI window and display it there). I'm not saying Red would be a bad choice. I'm just not sure it would be my choice, given the existence of, e.g., Chicken Scheme or Smalltalk/X.

andsoitis - 3 hours ago

> We must free ourselves of the hope that the sea will ever rest. We must learn to sail in high winds. -Aristotle Onassis

Love that quote. More poetic than my quip “Hope is not a strategy”.

naltun - 3 hours ago

Always nice to see Red updates (thanks for sharing)