Zig Language

I'm still waiting for a language that is actually safe, that has NO edge cases where it crashes (unlike Rust). I have yet to see a language that handles stack overflows properly without crashing. Zig doesn't have that yet, but in the video that OP linked the language's author says he's working on it.

Why wouldn't you want it to crash when you fuck up?

I'd my software be able to clean up after itself if it fucks up. Or even better, to recover from the error and continue in a well-defined and consistent state instead of relying on the operating system to simply restart my application.

Stop using computers with finite memory. Leave the real world and join the world of academia.

with Ada.Text_IO; use Ada.Text_IO;with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;procedure Smash is procedure Smashit (N : in Integer) is begin Put (N, Width => 0); New_Line; Smashit (N + 1); end Smashit;begin Smashit (0);end Smash;$ ./smash...174474174475174476174477raised STORAGE_ERROR : stack overflow or erroneous memory access
how's that?
60% of the time that same program dumps core

How about doing your job correctly? How about taking some responsibility and having some kind of quality control instead of wasting system resources because your software is shit?

Show me your quality control that checks stack usage.


Looks like guard pages, which requires paging. You automatically have those in your C programs, too. But that's not what I'm talking about. Crashing with a message is not "recovery".

That's an exception, so you can catch it:174534174535shit's fucked, trying to recover...donefrom:with Ada.Text_IO; use Ada.Text_IO;with Ada.Integer_Text_IO; use Ada.Integer_Text_IO;procedure Smash is procedure Smashit (N : in Integer) is begin Put (N, Width => 0); New_Line; Smashit (N + 1); end Smashit; Running : Boolean := False;begin Running := True; Smashit (0); Running := False;exception when Storage_Error => Put ("shit's fucked, trying to recover..."); Running := False; if Running then Put_Line ("and we failed!"); else Put_Line ("done"); end if;end Smash;realistically tho since this still fails 60% of the time, do as Erlang does and have an architecture that expects failure. Which means having the OS deal with it. An OS that "simply restarts" a daemon is an OS that can do more than that.

How would one write an OS that recovers from kernel stack overflows?
Also how can you be sure that your stack overflow never overwrites any of your application's other data? I think your stack-allocated objects would have to never be larger than your OS' guard page size, whatever size that may be. Imagine you were to put a large (multiple megabytes) object on the stack on a platform where the stack grows downwards. If you start writing to that object, you could potentially start writing below the guard page where other application data might be.

statically check stack sizes for kernel code
in case of non-tail recursion, have a hard limit on the number of calls which is proved statically to be impossible to exceed
problem solved