71–80 of 144 posts
Earlier quoted context omitted.
Hilarious example of why English is a terrible language: I meant for the the pronoun to refer to Joyent, not [necessarily] the CTO.
Operator errors do not indicate the quality of a language.
Bit of a mixed bag. Slide 12: > Go etc. are garbage collected, making interacting with C either impossible or excruciatingly slow. "Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general. Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster tha…
>> in-kernel C tends to be de facto safe > This is a bit of a stretch. Not "a bit;" quite a lot of a stretch. What makes C problematic is that the language is specified in terms of an abstract machine that looks absolutely nothing like real hardware, and executing instructions that make no sense in the abstract machine but are very well-defined in the real hardware is liable to cause problems for the optimizer in the…
(I have worked on a system that worked liked this. There was some kind of process information block at address 0, and NULL at runtime was all bits reset. The system compiler was not gcc.)
I think Zig would be better suited. See: https://github.com/ziglang/zig/wiki/Why-Zig-When-There-is-Al...
The top slogan for Rust is "fearless concurrency", which ties back into the memory model, mutability and sharing references. This helps you prevent (at compile-time) data races and other interesting bugs.
I didn't see any support for that in Zig at all.
Earlier quoted context omitted.
> Slide 12: IMO the big GC related issue is lack of determinism especially in the management of external resources. If you need that in a managed language you're forced into grafting reference counting on top which is particularly error-prone and unpleasant. Interacting with other languages can be slow, and bridging uncomfortable. > Slide 14: Rust can be faster than C in the general case because of the optimizations…
> MO the big GC related issue is lack of determinism especially in the management of external resources. This isn't a property of GCs per se; it's just that most GCs are optimized for throughput. Go's GC's pause times are on the order of 1ms, which might not be appropriate for every application, but it's probably fine for soft-realtime systems. There are a lot of other levers one could imagine as well, like semantics…
I’m not criticizing pause times, but rather that you can’t rely on code inspection to identify the point of resource deallocation, which is pretty much the flagship feature of a GC :)
Huh?
L4 is too low-level - you have to run another OS on top of it, usually Linux. QNX offers a POSIX interface.
Bit of a mixed bag. Slide 12: > Go etc. are garbage collected, making interacting with C either impossible or excruciatingly slow. "Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general. Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster tha…
> Slide 12: IMO the big GC related issue is lack of determinism especially in the management of external resources. If you need that in a managed language you're forced into grafting reference counting on top which is particularly error-prone and unpleasant. Interacting with other languages can be slow, and bridging uncomfortable. > Slide 14: Rust can be faster than C in the general case because of the optimizations…
As for Rust can be faster than C, well, people said the same about Ada but it rarely is the case so I wouldn't hold my breath for Rust either. After all, those languages use the same backends - GCC in the case of C & Ada, LLVM in the case of C & Rust. But it's enough to as fast as optimized C and have all the safety features.
Bit of a mixed bag. Slide 12: > Go etc. are garbage collected, making interacting with C either impossible or excruciatingly slow. "Impossible" is, of course, a lie. "Excruciatingly slow" may be the case, though it depends on the kind of interaction you are looking at. Without any context, this statement is overly general. Slide 14 can be taken out of context and misrepresented as showing that "Rust can be faster tha…
>> in-kernel C tends to be de facto safe > This is a bit of a stretch. Not "a bit;" quite a lot of a stretch. What makes C problematic is that the language is specified in terms of an abstract machine that looks absolutely nothing like real hardware, and executing instructions that make no sense in the abstract machine but are very well-defined in the real hardware is liable to cause problems for the optimizer in the…
Is there a language (other than assembly) that would have a closer model to the hardware?
Earlier quoted context omitted.
> MO the big GC related issue is lack of determinism especially in the management of external resources. This isn't a property of GCs per se; it's just that most GCs are optimized for throughput. Go's GC's pause times are on the order of 1ms, which might not be appropriate for every application, but it's probably fine for soft-realtime systems. There are a lot of other levers one could imagine as well, like semantics…
Lack of determinism is absolutely a property of GCs, by definition. You’re never 100% sure when a resource is going to get deallocated/finalized with absolute certainty. This is a dealbreaker for kernel type applications. For instance think of a network socket wrapped in a structure, you can’t rely on a finalizer invocation to close your file descriptor, you don’t know when if ever it will happen so you have to wrap…
Besides, a kernel has to deal with plenty of forms of nondeterminism anyway.
I'd really like to see an open-source QNX-type microkernel in Rust. Everybody is re-implementing early Unix in Rust, but that's not a good model. The great thing about the QNX model is that the tiny kernel barely changes from year to year, because everything is outside it and not very trusted. So it approaches being totally debugged. L4 is too low-level - you have to run another OS on top of it, usually Linux. QNX of…