personally i disagree, at least in a pragmatic approach to js's design. also your example doesn't make much of a valid point i feel: the promises are still async on the microtask queue. you seem to be showing syntax, not semantics.
> the promises are still async on the microtask queue. you seem to be showing syntax, not semantics
Well, GP doesn't want to get rid of concurrency, do they? They are talking about syntactic preferences when they want to "make every function async". I just showed them a way to make every function "some-form-of" sync, so they'll know how to change every function according to their preferences, either async or sync.
the only reason to use cython (in my experience) is to write quick numpy extensions without a tonne of extra baggage from having a complete compiled extension in C/C++/Rust. Often, you explicitly want to avoid the compiler offering you any kinds of additional checking because you want to get maximum throughput. Most of the functions I’ve written in cython explicitly opt out of bounds checking etc since the memory access is sequential and bounded by construction and very obvious when you mess things up by writing simple unit tests. Given that, it doesn’t seem useful to me to add any kind of memory safety as additional overhead. YMMV I mostly do scientific computing and signal processing.
The benefit also isn’t as big as you might expect. Most of Linux’s recently found security vulnerabilities were due to ToC/ToU bugs. Fil-C would not magically fix these problems.
It would sometimes be a good trade off, for some users. But I don’t think many regular users would choose to pay this cost.
If you’re using SeL4, userland processes are already strictly sandboxed. There’s still some benefit to Fil-C, since the added memory safety would make it much more difficult to take over a process. But the blast radius of a compromised program in SeL4 is much smaller because of the capability model.
This is a myth that seems to never die. OS kernels can and have been written in GC languages. Watch the video maybe? The whole presentation was running on a distro fully compiled with FillC.
Ok, I stand corrected: only the kernel userland was compiled with Fil-C.
However, I don't see why the full Linux kernel could not be compiled with Fil-C. It would be nice if Fil himself could explain what limitations there are, but the documentation does not list missing C/C++ features as far as I know, it only says it's "fanatically compatible" which I take to mean mostly everything should work?!
But to my point in general, here's a osdev.org wiki explaining how high level languages can and have been used for OS development (with the caveat that some Assembly code is required, which I believe is also true of kernels written in C): https://wiki.osdev.org/Languages
https://github.com/mikeaustin/kopi