4 ms·

unhandled null in rust will still cause panic. still cause the bootloop.

• YZF 2y ago
  I'm not a Rust expert but wouldn't you pick some ("null-safe") type that can't be null in Rust? A reference?
  • ArtixFox 2y ago
    i dont think it matters, if you have any exception in the critical boot part, you will end up with this. Rust cannot fix this. Microkernels might.
    • YZF 2y ago
      Something like this Go snippet: func parsefile(string) string { } func thatfunctionthatcrashedinC() { defer func() { if err := recover(); err != nil { log.Println("panic occurred:", err) } }() result := parsefile(badfilethatcrashesC); if result[0] == 'A' { } } so... using a type that can't be nil. recovering from runtime panics (you have to do that but this can be enforced by standards and also it can happen up the stack for all code, e.g. like http handlers do by default in the Go standard library). More importantly these errors are not segfaults in Go, i.e. there's "exceptions" you can and should catch and there are exceptions you can't.
      • ArtixFox 2y ago
        You have all that in C++ too. Exceptions are near zero cost and used everywhere, sometimes even in embedded stuff too.
        • YZF 2y ago
          Sure. I speak C++ ;) You can do this in C++ but I think it's generally more crash prone than Go. Based on personal experience of ~20 years of C++ and ~10 of Go I've debugged many a core dump in C++ and I think zero in Go. You can restrict yourself to the somewhat safer parts of C++ for sure.