Red Programming Language: Plans for 2019
red-lang.org
Red Programming Language: Plans for 2019
1–10 of 141 posts
Re: Red Programming Language: Plans for 2019
#2A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
Re: Red Programming Language: Plans for 2019
#3A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
You are right that GC s not good fit for low level programming, but Red solves this problem with dialects (DSL) of Red. For low-level it uses Red/System [1], which is C-like language with Red syntax. There are also other dialects (DSLs) for other areas like GUI, parsing, etc... It's better approach IMO than trying to solve everything with one language.
Re: Red Programming Language: Plans for 2019
#4A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
Generally agreed, although the huge number of bugs out there that are attributable to manual memory management suggests that other solutions are worth looking for. Perhaps Rust is heading in the right direction.
Re: Red Programming Language: Plans for 2019
#5A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
What if they can write their GC in the language itself?
https://github.com/red/red/blob/master/runtime/collector.red...
Re: Red Programming Language: Plans for 2019
#6A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
I write kernel drivers and firmware code mainly in C and a little bit of assembler.
I agree with you pretty much.
That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another.
Especially firmware development is somewhat ossified to C. C is universally supported and a lot of people in this trade don't even see need for a change, despite vastly increased system complexity and exposure over open networks. It's not enough for the things to just to work — they need to work securely, otherwise ultimately our infrastructure is at risk.
C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a 4-bit single core microcontrollers to massive RDMA supercomputing clusters. C contender does not need to cover all of that, but should keep that enormous range in mind.
The contender should also be able to interface with C library and linking interfaces. Otherwise it's hard to compose working systems. No matter how amazing the new language is, you can't build everything from scratch.
So far I've placed my biggest hopes in Rust. But we'll see how the things evolve. One should keep an open mind. I wish good luck for the Red folks.
By the way, you often can't allocate or free memory in firmware or kernel drivers either. Like in a kernel IRQ handler or on an embedded device with hard realtime and stability requirements. In that kind of case GC or manual allocation would not make much difference at all — you'd only allocate at initialization or at teardown.
Re: Red Programming Language: Plans for 2019
#7I was so worried when they announced their cryptocurrency plans that Red wouldn't survive when the cryptocurrency hype bubble would inevitably pop. Glad to see that they managed.
Re: Red Programming Language: Plans for 2019
#8A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
What if they can write their GC in the language itself? https://github.com/red/red/blob/master/runtime/collector.red...
What would this change?
Re: Red Programming Language: Plans for 2019
#9A great feature of Red is their cross platform GUI support. I see Android is also supported. Does anyone know what the status of iphone (iOS) support is ?
Re: Red Programming Language: Plans for 2019
#10A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
> It's naive at best.
It's naive at best to assume that something isn't suitable for domains which you perceive as needing near-bare-metal performance.
E.g., your idea about games is provably false since at least IL-2 Sturmovik of 2001 which was written almost entirely in Java.