Hacker News Reader

Comment by echelon | Hacker News Reader

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.

View on HN

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.

[1] https://static.red-lang.org/red-system-specs.html

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.

We do try to maintain a high standard of civility.

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.

All these languages beg to differ.

- Mesa/Cedar at Xerox PARC

- Algol 68 at UK Navy computing center

- Modula-2+ at Olivetti DEC

- 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.

Does fuchsia contain any significant amount of low level go code? The majority code in zircon seems cpp to me.

D by Digital Mars is a language not a project.

The java use cases you mention seem very niche. Even databases written in Java ( Cassandra) started migrating a lot of parts to C++ (myrocks)

The Microsoft Research ones too don't seem like they came out of Microsoft Research to being used in shipped products.

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.

https://fahrplan.events.ccc.de/congress/2018/Fahrplan/events...

https://www.infoq.com/presentations/csharp-systems-programmi...

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.

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.

>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.

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?

At the very least it would imply that you have full control over the memory from within the language

Garbage collector (and the whole runtime library) is written in Red/System, not in Red.

"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.

> 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.

> E.g., your idea about games is provably false since at least IL-2 Sturmovik of 2001 which was written almost entirely in Java.

Oh, really?

That's interesting. Do you have details? Was the main I/O loop in Java?

Unfortunately, most of the links are dead or lead to nowhere :(

There was more info 10 or so years back, including class decopilers for the game.

According to this Russian Post [1], it's 90% Java + OpenGL, the rest being DirectSound + DirectInput.

A recent example is Minecraft :) AFAIR it's also in Java :)

[q] https://groups.google.com/forum/?hl=ru#!msg/fido7.ru.java/sz...

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.

Mostly due to bad programming practices, as already discussed multiple times in gamming forums.

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.

Reply on news.ycombinator.com