A 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.
This was something that definitely got my attention.
If the butthurtness of 9214 above is representative of the community, though, I'd probably last 10 minutes in their forum before being banned for life.
Even though some of my responses in this thread can be considered butthurt-ish in the hindsight, I don't think that judging whole community by one individual is a good idea.
- Modula-3 at Olivetti DEC/Compaq/HP and University of Washington
- Oberon, Oberon-2, Active Oberon, Oberon-07 at ETHZ
- Oberon-07 at Astrobe
- Component Pascal at Oberon microsystems AG
- Sing#, Dafny and System C# (M#) at Microsoft Research
- Java when running AOT compiled on bare metal embedded systems like PTC Perc and Aicas Jamaica
- D by Digital Mars
- Go at Google (Fuchsia) and MIT (Biscuit)
If we don't have a mainstream OS written in one, it is mostly a consequence of politics and willingness to push it forward, instead of doing yet another UNIX clone.
Fuchsia's TCP/IP stack and file system management tooling are written in Go.
D is a project for a systems programming language with GC enabled by default. There a couple of experimental OSes like PowerNex.
RocksDB is not part of the Cassandra project, as far as I can tell.
Anyway it doesn't matter how niche they are, rather they were successful implemented and aren't mainstream as a consequence of politics and willingness to push it forward.
Doing UNIX clones is cheaper than improving the overall security.
Which is why in spite of the ergonic issues of using the NDK as it is, I enjoy the fact that Google makes it quite hard to use C and C++ instead of Java/Kotlin on Android.
Which on their little brother variant, Android Things, is even more explicit with user space drivers being written in Java.
Then we have Apple pushing Swift, which even if it takes another decade, it will eventually make Objective-C join Carbon.
Modern systems programming seems to be the land of luddites in IT.
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.
>That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another.
Exactly. Perhaps it is not appropriate to write production ready drivers and operating systems that people will use today in a GC language; but in the future that could change and change will only happen if people take the time to experiment.
C doesn't even assume that code and memory live in the same address space! The portability of standard C is almost as breathtaking as the ease with which you can introduce undefined behavior.
"Full stack" means different things to different people. There are plenty of GC languages which are still relatively-high performance and can thus be used for technically-challenging, "system"-like tasks. In fact, this very variety is what makes it a bit hard to figure out what Red's unique selling point might be, although it's easier if you're familiar with its predecessor Rebol.
> There are plenty of GC languages which are still relatively-high performance and can thus be used for technically-challenging, "system"-like tasks
Unfortunately, they frequently lack the other attribute which makes C and C++ such pervasive solutions, namely portability.
Having "theoretical portability" (for example JVM bytecode) is not much use if your target hardware or operating system cannot support a JVM without you having to first port the JVM yourself.
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.
Minecraft Java Edition is 100% Java, but it's also notoriously slow, and experiences lag spikes, which are often attributed to garbage collection. I think an OS written in a GC language can certainly have adequate latency and throughput, but I don't think Minecraft is a good example of that.
Your comment itself is extremely naive and misinformed. Red toolchain relies on Red/System DSL, which is a C-level language with manual memory management.
