4 ms·

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

by zeveb 10y ago

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

E6300 10y ago
What about kernel drivers?
- viraptor 10y ago
  Rust: https://github.com/tsgates/rust.ko https://github.com/tsgates/rust.ko Haskell: https://wiki.haskell.org/Kernel_Modules https://wiki.haskell.org/Kernel_Modules And you can find a few others.
  - E6300 10y ago
    I'm on Windows, though.
    - viraptor 10y ago
      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?
      - E6300 10y ago
        As far as I know, the only languages supported for Windows kernel development are C and C++.
        steveklabnik 10y ago
        Rust can expose a C ABI, so that means you could write Rust ones too, same mechanism as the Linux ones.
        AndrewGaspar 10y ago
        The last time I looked, it seems there's a lot of platform work needed in Rust to support drivers in NT.
        viraptor 10y ago
        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.
        sargun 10y ago
        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.
AlexeyBrin 10y ago
> 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 ?
- zeveb 10y ago
  http://www.sciencedirect.com/science/article/pii/089571779090275R 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/ http://www.femlisp.org/ is a finite element analysis for Common Lisp.
  - AlexeyBrin 10y ago
    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 :).
DowsingSpoon 10y ago
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.
- fauigerzigerk 10y ago
  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.
- thomastjeffery 10y ago
  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.

by zeveb 10y ago

E6300 10y ago

What about kernel drivers?

viraptor 10y ago
Rust: https://github.com/tsgates/rust.ko https://github.com/tsgates/rust.ko Haskell: https://wiki.haskell.org/Kernel_Modules https://wiki.haskell.org/Kernel_Modules And you can find a few others.
- E6300 10y ago
  I'm on Windows, though.
  - viraptor 10y ago
    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?
    - E6300 10y ago
      As far as I know, the only languages supported for Windows kernel development are C and C++.
      - steveklabnik 10y ago
        Rust can expose a C ABI, so that means you could write Rust ones too, same mechanism as the Linux ones.
        AndrewGaspar 10y ago
        The last time I looked, it seems there's a lot of platform work needed in Rust to support drivers in NT.
      - viraptor 10y ago
        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.
        sargun 10y ago
        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.

AlexeyBrin 10y ago

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

zeveb 10y ago
http://www.sciencedirect.com/science/article/pii/089571779090275R 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/ http://www.femlisp.org/ is a finite element analysis for Common Lisp.
- AlexeyBrin 10y ago
  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 :).

DowsingSpoon 10y ago

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.

fauigerzigerk 10y ago
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.
thomastjeffery 10y ago
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.