6 ms·

been a while since I played with Red, but from what I remember the problem was this: 1. default compile mode was shared, so all executables relied on a "libred

by 38 3y ago

been a while since I played with Red, but from what I remember the problem was this: 1. default compile mode was shared, so all executables relied on a "libred.dll" or similar 2. compiling "libred" was really slow (1 minute), but after that its done and skipped in the compile stage, making compile much faster (but still with the limitation of #1) 3. you can compile static, but then the static "libred" needs to be compiled EVERY TIME, making every single static compile, even "hello world" take one minute EVERY TIME. I posted multiple issues about #3, but they were closed each time as "wont fix" or "working as intended" or similar. So OK fine, I just moved onto Go and Rust, even C, plenty of other languages that dont have this issue.

Zamiel_Snawley 3y ago
Is the intended workflow to use dynamic linking when developing, and static(if you want it) for release? If so, that sounds reasonable to me.
- 38 3y ago
  yes, that was one of the arguments. however I dont accept that. I have used C, C++, C#, Crystal, D, Go, Nim, Rust and Zig, none of which have this issue.
  - kstrauser 3y ago
    Hmmm. I thinking of Rust and its `cargo build --release` that recompiles the whole thing from scratch (if you haven’t already made a release build).
    - deleted 3y ago
      [deleted]
  - Zuider 3y ago
    But do those languages permit rapid Lisp-like development in the way Red does? I am not sure I see the problem. The slow static compilation is reserved for the final deployment of the app, so it should not hinder development.
  - lelanthran 3y ago
    > yes, that was one of the arguments. however I dont accept that. I have used C, C++, C#, Crystal, D, Go, Nim, Rust and Zig, none of which have this issue. Which issue? This one? >>> but from what I remember the problem was this: >>> 1. default compile mode was shared, so all executables relied on a "libred.dll" or similar Don't all the above languages, besides Go, rely on a library for runtime? Ever got the error `missing msvcrt110.dll` when distributing binaries of your application on Windows? The only difference here that I see is that you can choose to recompile the runtime; with C, C++, et all on Windows, you don't get that choice - you have to use the dlls that the language specifies whether you like it or not.
    - gliptic 3y ago
      No, at least C, C++, D, Rust and Zig allow static linking of the runtime libs, even on Windows. And they don't recompile it every time. Rust especially will static link everything by default.
      - patrec 3y ago
        That's not entirely correct. Rust on Linux will dynamically link glibc and libgcc by default. And you can't reliably create a fully statically linked executable on some operating systems like macOS et al.
        greatfilter250 3y ago
        [dead]
    - Guvante 3y ago
      It is just a caching bug. You shouldn't need to recompile the runtime to statically link it. Red might not have a way to store intermediate static linking files and so is forced to do a full compilation everytime. Caching at the output file level is simplest but can result in these kinds of weird performance issues. (Shipping a precompiled library is standard to avoid this pain point, MSVC includes four versions of its standard library, Debug/Release and Static/Dynamic in the various combinations)
  - canadianfella 3y ago
    [dead]
PrimeMcFly 3y ago
1 minute really isn't that long.
- 38 3y ago
  I guess when I put "every time" in all caps twice I was being too subtle.
  - PrimeMcFly 3y ago
    No, you weren't. Your point was taken and considered in my reply.
- lgas 3y ago
  It is if you don't want your train of though interrupted.
- mock-possum 3y ago
  Based on what
- vore 3y ago
  Imagine tweaking some parameter to see how the result changes but having to wait 1 minute every time for the answer...
  - K0balt 3y ago
    You only have to compile for the final build.
culebron21 3y ago
Sounds like exactly the problem of Julia language. On the surface, Julia seems slick in code and fast in running. But then you discover that 1. there are no objects, so when you switch from Python, instead of chains of methods, like `my_dataframe.groupby(...).aggregate(...).groupby(...).aggregate(...)` you need either (a) a lot of poorly readable nested calls, or (b) ugly "pipes", where the left side is implicit first param of the function on the right side: ` my_df |> groupby(...) |> aggregate(...) |> groupby(...) |> aggregate(...)`. (Writing them, you feel insecure of what is happening -- in this case, what gets passed to the function.) 2. You can't make it a CLI script, because it compiles the whole code WITH dependencies every time, and as soon as you import some serious libraries, compile times will skyrocket. I quickly hit 40 seconds of compilation with just geospatial lib and dataframes. These 40 seconds turned out to be A LOT when you develop interactively. And you can't build everything in a Jupyter Notebook, because eventually you'll have to switch to a CLI script. I think I could put up with pipes, but the compilation times were the final argument against Julia.
- troupo 3y ago
  > (b) ugly "pipes", where the left side is implicit first param of the function on the right side: ` my_df |> groupby(...) |> aggregate(...) |> groupby(...) |> aggregate(...)`. (Writing them, you feel insecure of what is happening -- in this case, what gets passed to the function.) These are not ugly pipes. These are a very common feature in a lot of functional languages. Once you've used them, you want them everywhere :) And of course you know exactly what is passed to the function. You wrote it yourself: left side is passed as the first param of the function on the right side.
  - thumbuddy 3y ago
    I think it's not so clear a lot of times which function is called. Say you write a function that accepts your type as an argument. Cool, you compile it everything is good. Now you import a library, just so happens it also has a function that has the same name, and accepts an argument of the same parent type. Which function gets called? If you're reading the code and not intimately familiar with how imports work, all the imports in scope, and the function your coworker defined on like 5,000 in a random file you might not be sure unless you start debugging. Pipes are fine, but methods and traits with a strong type system reduce any ambiguity there. Doesn't mean you can't use pipes reasonably! But in Julia that seems like it could be harder to unpack.
rebolek 3y ago
While what you write is more or less true, the biggest problem here is that compilation is OPTIONAL. Red scripts can run in the interpreter just fine and TBH I use compile very rarely. it's a dynamic language with optional compilation, so complaining that the compiler is slow isn't very fair. The compiler is written in Rebol (language Red is based on) which is dynamic language also, so that's why it's slow. Rebol itself is written in C and its scripts can't be compiled. You can of course bundle the script with the interpreter which is ~1-2MB with OS dependencies only. (I used to work for Red and use Rebol in my job daily)

by 38 3y ago

Zamiel_Snawley 3y ago

Is the intended workflow to use dynamic linking when developing, and static(if you want it) for release? If so, that sounds reasonable to me.

38 3y ago
yes, that was one of the arguments. however I dont accept that. I have used C, C++, C#, Crystal, D, Go, Nim, Rust and Zig, none of which have this issue.
- kstrauser 3y ago
  Hmmm. I thinking of Rust and its `cargo build --release` that recompiles the whole thing from scratch (if you haven’t already made a release build).
  - deleted 3y ago
    [deleted]
- Zuider 3y ago
  But do those languages permit rapid Lisp-like development in the way Red does? I am not sure I see the problem. The slow static compilation is reserved for the final deployment of the app, so it should not hinder development.
- lelanthran 3y ago
  > yes, that was one of the arguments. however I dont accept that. I have used C, C++, C#, Crystal, D, Go, Nim, Rust and Zig, none of which have this issue. Which issue? This one? >>> but from what I remember the problem was this: >>> 1. default compile mode was shared, so all executables relied on a "libred.dll" or similar Don't all the above languages, besides Go, rely on a library for runtime? Ever got the error `missing msvcrt110.dll` when distributing binaries of your application on Windows? The only difference here that I see is that you can choose to recompile the runtime; with C, C++, et all on Windows, you don't get that choice - you have to use the dlls that the language specifies whether you like it or not.
  - gliptic 3y ago
    No, at least C, C++, D, Rust and Zig allow static linking of the runtime libs, even on Windows. And they don't recompile it every time. Rust especially will static link everything by default.
    - patrec 3y ago
      That's not entirely correct. Rust on Linux will dynamically link glibc and libgcc by default. And you can't reliably create a fully statically linked executable on some operating systems like macOS et al.
      - greatfilter250 3y ago
        [dead]
  - Guvante 3y ago
    It is just a caching bug. You shouldn't need to recompile the runtime to statically link it. Red might not have a way to store intermediate static linking files and so is forced to do a full compilation everytime. Caching at the output file level is simplest but can result in these kinds of weird performance issues. (Shipping a precompiled library is standard to avoid this pain point, MSVC includes four versions of its standard library, Debug/Release and Static/Dynamic in the various combinations)
- canadianfella 3y ago
  [dead]

PrimeMcFly 3y ago

1 minute really isn't that long.

38 3y ago
I guess when I put "every time" in all caps twice I was being too subtle.
- PrimeMcFly 3y ago
  No, you weren't. Your point was taken and considered in my reply.
lgas 3y ago
It is if you don't want your train of though interrupted.
mock-possum 3y ago
Based on what
vore 3y ago
Imagine tweaking some parameter to see how the result changes but having to wait 1 minute every time for the answer...
- K0balt 3y ago
  You only have to compile for the final build.

culebron21 3y ago

Sounds like exactly the problem of Julia language. On the surface, Julia seems slick in code and fast in running. But then you discover that 1. there are no objects, so when you switch from Python, instead of chains of methods, like `my_dataframe.groupby(...).aggregate(...).groupby(...).aggregate(...)` you need either (a) a lot of poorly readable nested calls, or (b) ugly "pipes", where the left side is implicit first param of the function on the right side: ` my_df |> groupby(...) |> aggregate(...) |> groupby(...) |> aggregate(...)`. (Writing them, you feel insecure of what is happening -- in this case, what gets passed to the function.) 2. You can't make it a CLI script, because it compiles the whole code WITH dependencies every time, and as soon as you import some serious libraries, compile times will skyrocket. I quickly hit 40 seconds of compilation with just geospatial lib and dataframes. These 40 seconds turned out to be A LOT when you develop interactively. And you can't build everything in a Jupyter Notebook, because eventually you'll have to switch to a CLI script. I think I could put up with pipes, but the compilation times were the final argument against Julia.

troupo 3y ago
> (b) ugly "pipes", where the left side is implicit first param of the function on the right side: ` my_df |> groupby(...) |> aggregate(...) |> groupby(...) |> aggregate(...)`. (Writing them, you feel insecure of what is happening -- in this case, what gets passed to the function.) These are not ugly pipes. These are a very common feature in a lot of functional languages. Once you've used them, you want them everywhere :) And of course you know exactly what is passed to the function. You wrote it yourself: left side is passed as the first param of the function on the right side.
- thumbuddy 3y ago
  I think it's not so clear a lot of times which function is called. Say you write a function that accepts your type as an argument. Cool, you compile it everything is good. Now you import a library, just so happens it also has a function that has the same name, and accepts an argument of the same parent type. Which function gets called? If you're reading the code and not intimately familiar with how imports work, all the imports in scope, and the function your coworker defined on like 5,000 in a random file you might not be sure unless you start debugging. Pipes are fine, but methods and traits with a strong type system reduce any ambiguity there. Doesn't mean you can't use pipes reasonably! But in Julia that seems like it could be harder to unpack.

rebolek 3y ago

While what you write is more or less true, the biggest problem here is that compilation is OPTIONAL. Red scripts can run in the interpreter just fine and TBH I use compile very rarely. it's a dynamic language with optional compilation, so complaining that the compiler is slow isn't very fair. The compiler is written in Rebol (language Red is based on) which is dynamic language also, so that's why it's slow. Rebol itself is written in C and its scripts can't be compiled. You can of course bundle the script with the interpreter which is ~1-2MB with OS dependencies only. (I used to work for Red and use Rebol in my job daily)