3 ms·

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]

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]