Hacker News Reader

Comment by zeveb | Hacker News Reader

> We don't have memory safe languages suitable for system programming that's widely available on all kinds of architectures.

Yes, yes we do. Go is available on a ton of architectures; Lisp is available on a ton of architectures; ML is available on a ton of architectures.

Yes, C is available on more. Yes, for some architecture C is the only reasonable choice. But on x86 & ARM, there's no good reason to write new code in C.

View on HN

What about applications with soft or hard real time requirements? (So, for example, a video game or an audio player.) I am not aware of any GC language which is suitable for use in this space. Go certainly is not.

What about any application that cares in the slightest about performance? In this case, memory layout is incredibly important, and many (most?) of those higher level languages are immediately disqualified.

Correct me if I'm wrong as I'm not an expert in this field at all, but aren't hard real time systems written so that no memory allocation or release happens during normal operation?

I'm sure there are other reasons why Go would rarely be considered for a hard real time system, but purely from a memory management perspective you could simply disable the GC.

And then of course there is also Rust.

Rust was made specifically to fill this void. The only problem is that libraries you would want to use (ie for a video game or audio player) are written in C/C++, and therefore much easier to interface with using C/C++. Fortunately that is changing at a fairly good pace.

The most difficult thing about using Rust instead of C is that you must wrap your head around the borrow checker.

> But on x86 & ARM, there's no good reason to write new code in C

Sorry, but this is pure ignorance. Please let me know when was the last time you've tried to implement a CFD or FEA code in Go or Lisp ?

http://www.sciencedirect.com/science/article/pii/08957177909... indicates that folks were writing computational fluid dynamics software in Lisp in 1989.

I think that http://www.femlisp.org/ is a finite element analysis for Common Lisp.

Folks were writing CFD codes in Matlab too, that does not mean that it was a good idea (except for 1D or small 2D problems or for prototyping). My point was that some languages are better suited for particular tasks. In CFD and FEM codes you want speed, if you need to wait a few days for a highly optimized C++ code to get some results (e.g. the flow around an entire airplane) imagine how long it will take to do the same in Go or Common Lisp ...

Case in point FEMLISP uses C or Fortran libraries (Triangle, Tetgen, OpenMP, various linear algebra libraries) under the hood for the actual computation :).

What about kernel drivers?

Rust: https://github.com/tsgates/rust.ko

Haskell: https://wiki.haskell.org/Kernel_Modules

And you can find a few others.

I'm on Windows, though.

If you have experience and interest in windows kernel modules programming, tell me, what did you find in your research? Are the methods described in these posts portable to the win kernel? Are there some other barriers you know of?

As far as I know, the only languages supported for Windows kernel development are C and C++.

Rust can expose a C ABI, so that means you could write Rust ones too, same mechanism as the Linux ones.

The last time I looked, it seems there's a lot of platform work needed in Rust to support drivers in NT.

Same as Linux kernel. I asked because the links show it's possible with some effort and you seemed to dismiss it. If you know of some specific extra barriers in windows kernel, tell us. But if you just meant that it's not officially supported... yeah, that's not a big problem.

The Linux kernel does not allow for C++ code to be in-tree. There are folks who have managed to get some C++ code running in a kernel context, but I would consider it inadvisable.

Reply on news.ycombinator.com