3 ms·
Some tasks - such as implementing kernels - are poorly suited for garbage collection Right, but we have C for that. I also doubt that Rust would be suitable f
by cmccabe 14y ago
Some tasks - such as implementing kernels - are poorly suited for garbage collection
Right, but we have C for that. I also doubt that Rust would be suitable for hard-realtime applications, due to the fact that it has garbage collection. Even task-local garbage collection is still garbage collection, and not what you want for hard-realtime applications.
Of course there's a bunch of different definitions of "hard realtime" floating around, and rust would probably be suitable for some of them. I fully expect that someone will reply to this with something like, "Well MY definition of hard realtime is playing movies, and Rust is suitable for that." :) But when I think of hard realtime, I think of applications where you must have absolute determinism.
- scott_s 14y agoYour definition of hard real time is the accepted definition; playing movies and such is soft real time. Anyway, about C: that's the point. People are trying to create safer systems programming languages that can replace C.
- cmccabe 14y agoI don't think Go is intended to replace C. It was intended to replace C++.
- scott_s 14y agoC++ was intended to replace C, so it's intended to replace both.
- cmccabe 14y agoLet's not judge the intentions of the Golang authors by what the intentions of the C++ authors were. Golang is a higher level language than C. It will not be suitable for non-GC'ed environments, and the Golang authors are perfectly well aware of that. It's ok to make a language that solves many problems really well, without trying to solve every problem in the world in one bloated language.