6 ms·

Red Programming Language: Static linking support

78 points by em-bee 4mo ago

uticus 4mo ago
https://re-bol.com/short_rebol_examples.r https://re-bol.com/short_rebol_examples.r for some examples of the language (from https://redprogramming.com/Home.html https://redprogramming.com/Home.html)
- em-bee 4mo 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 4mo 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 4mo ago
      I think they mean red as a shell scripting/command line language.
      - klibertp 4mo 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.
    - em-bee 4mo ago
      that was kind of a rhetoric question. i was already pretty sure it would work. so the real question is what is actually needed. i found the call documentation. that's a good start, but that is pretty much what every other language also provides. what is still needed is a wrapper that allows me to write somestr: some command --with arguments and have that string be populated with the "some" command output. but then we also need to capture stderr and the exit value, so we actually need to capture three return values. next, support for pipes in some form would also be needed. i have worked with lisp and smalltalk and also TCL so i am aware of course. with so many other interesting languages, it's hard to justify investing more time into learning Red in particular i actually find red in particular one of the more interesting languages. alongside lisp and smalltalk. haskell, erlang and ocaml are also interesting, but for shell use i am specifically looking at languages that use whitespace as an argument and value separator and which allow complex expressions to be written on one line, since that happens often in shell commands. that reduces the list of interesting languages quite a lot. if you know any others that you think are worth learning, please share. btw, your website seems to be down.
naltun 4mo ago
Always nice to see Red updates (thanks for sharing)
andsoitis 4mo 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”.
kryptiskt 4mo 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 4mo 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
  - rebolek 4mo ago
    No, even Rebol2 can build 64 bit but the whole compiler needs to be rewritten to produce 64 bit binaries. It’s not limitation but deliberate choice made when 32 bit was still major target. It may seem silly in the hindsight. But it made sense then.
fithisux 4mo ago
And still here.
rebolek 4mo ago
I always love to see Rebol and Red mentioned anywhere, as I spent more than half of my life with these languages, working with them and working on them. Recently I started working on [Recoil](https://recoil.rblk.eu/ https://recoil.rblk.eu/) which is inspired by Rebol/Red but targets static memory-safe compiled niche to complement dynamic interpreted nature of Rebol. It’s still in very early phase but it already has some very nice features (at least I consider them very nice) like fully compiler owned `parse`, finite state machine and (lazy) finite state transducer datatypes. Oh, and built-in Rebol-like scripting language that can run on (not only) ESP32 called F00. It’s still work in progress but I like it. Maybe someone else can find it interesting too.
anthk 4mo ago
Being able to bootstrap itself should be the main priority.
lanycrost 4mo ago
Static linking is very essential feature for any such language, I've used it a lot with golang and like how elegantly and easily golang do that. Guess you need to have 64 bit :) of course if you not have any reason to stuck on 32.
- em-bee 4mo ago
  i never needed the ability to create a self-contained binary for myself, but when it comes to distributing software to other people it makes a big difference. it was always an issue with languages like python, ruby or pike for example. so i am very happy to see a high level language get that potential. besides go only common lisp has that ability that i am aware of. others are either to low level (rust/c/c++) or to obscure. not even java does it, although java is common enough that it still keeps distribution easy enough. to me this means now is a good time to start using red because now i can be sure that i'll be able to build tools that can be shared easily so i won't just be limited to create toys for myself. 64bit is the next big thing on the roadmap. so no need to worry about that. it will happen.
  - Archit3ch 4mo ago
    > ability to create a self-contained binary > so i am very happy to see a high level language get that potential. besides go only common lisp has that ability that i am aware of. Julia can do it.

78 points by em-bee 4mo ago

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

em-bee 4mo 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 4mo 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 4mo ago
    I think they mean red as a shell scripting/command line language.
    - klibertp 4mo 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.
  - em-bee 4mo ago
    that was kind of a rhetoric question. i was already pretty sure it would work. so the real question is what is actually needed. i found the call documentation. that's a good start, but that is pretty much what every other language also provides. what is still needed is a wrapper that allows me to write somestr: some command --with arguments and have that string be populated with the "some" command output. but then we also need to capture stderr and the exit value, so we actually need to capture three return values. next, support for pipes in some form would also be needed. i have worked with lisp and smalltalk and also TCL so i am aware of course. with so many other interesting languages, it's hard to justify investing more time into learning Red in particular i actually find red in particular one of the more interesting languages. alongside lisp and smalltalk. haskell, erlang and ocaml are also interesting, but for shell use i am specifically looking at languages that use whitespace as an argument and value separator and which allow complex expressions to be written on one line, since that happens often in shell commands. that reduces the list of interesting languages quite a lot. if you know any others that you think are worth learning, please share. btw, your website seems to be down.

naltun 4mo ago

Always nice to see Red updates (thanks for sharing)

andsoitis 4mo 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”.

kryptiskt 4mo 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 4mo 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
- rebolek 4mo ago
  No, even Rebol2 can build 64 bit but the whole compiler needs to be rewritten to produce 64 bit binaries. It’s not limitation but deliberate choice made when 32 bit was still major target. It may seem silly in the hindsight. But it made sense then.

fithisux 4mo ago

And still here.

rebolek 4mo ago

I always love to see Rebol and Red mentioned anywhere, as I spent more than half of my life with these languages, working with them and working on them. Recently I started working on [Recoil](https://recoil.rblk.eu/ https://recoil.rblk.eu/) which is inspired by Rebol/Red but targets static memory-safe compiled niche to complement dynamic interpreted nature of Rebol. It’s still in very early phase but it already has some very nice features (at least I consider them very nice) like fully compiler owned `parse`, finite state machine and (lazy) finite state transducer datatypes. Oh, and built-in Rebol-like scripting language that can run on (not only) ESP32 called F00. It’s still work in progress but I like it. Maybe someone else can find it interesting too.

anthk 4mo ago

Being able to bootstrap itself should be the main priority.

lanycrost 4mo ago

Static linking is very essential feature for any such language, I've used it a lot with golang and like how elegantly and easily golang do that. Guess you need to have 64 bit :) of course if you not have any reason to stuck on 32.

em-bee 4mo ago
i never needed the ability to create a self-contained binary for myself, but when it comes to distributing software to other people it makes a big difference. it was always an issue with languages like python, ruby or pike for example. so i am very happy to see a high level language get that potential. besides go only common lisp has that ability that i am aware of. others are either to low level (rust/c/c++) or to obscure. not even java does it, although java is common enough that it still keeps distribution easy enough. to me this means now is a good time to start using red because now i can be sure that i'll be able to build tools that can be shared easily so i won't just be limited to create toys for myself. 64bit is the next big thing on the roadmap. so no need to worry about that. it will happen.
- Archit3ch 4mo ago
  > ability to create a self-contained binary > so i am very happy to see a high level language get that potential. besides go only common lisp has that ability that i am aware of. Julia can do it.