EDIT:
i just read up on this. only the first time the static build is slow. later rebuilds are fast. just like every c/c++ program. the first time it has to build everything, all following times it only needs to rebuild the parts that changed.
this has already been explained, and i am only repeating it here for the casual HN reader, so they can follow along.
old comment, that makes no sense because getting a fast static build isn't even a problem. left here because that is what was responded to:
why do you need a static build after every change? isn't a dynamic one sufficient for testing?
As someone naive to Red myself, I just read through the 5 different compile methods mentioned in the parent comment, and while that's quite a bit more than other languages offer, it seems to offer an interesting set of tradeoffs that balance the needs of different real-world scenarios against the language design.
It sounds like you're describing an edge case. To better understand it, what's the actual context around your requirement of static builds?
To be clear about my question, I am genuinely curious - perhaps there are workarounds that could be used, or optimizations that could be considered in the long term.
However (and critically), there is not nearly enough semantic detail in your arguments as currently presented for developers to potentially extract actionable work items from. This is why everyone else is annoyed.
i am watching red on the sidelines as i am waiting for it to become usable for my interests, so i am not tracking every detail.
though i'd appreciate if you could use a less adversarial and demanding attitude. this is not appropriate for a Free Software and Open Source project, and it only serves to annoy the developers which reduces their motivation to work on the project.
your complaints, even if they were acceptable, won't help your cause. at best they will be ignored. at worst they will slow progress down as developers are less motivated.
it has been explained that the current compiler is not the final version, and as such, speedy static builds are simply not a development goal. and they should not be, because the goal is to rebuild the compiler, at which point this issue may be addressed if it is important enough. when that happens, then it is time to make a case for static builds. until then things will go faster if you could stay out of the developers ways.
