Comments by "" (@pierreollivier1) on "Was Rust In The Linux Kernel A Mistake?" video.

  1. C++ ? come on let's be serious
    5
  2.  @acpp23  C++ has too many problems, it's basically a worst C from a C perspective, 99% of the features are useless, the tooling is as bad if not worst, the compilation time on it's own is a no go, and it carries the same broken semantic as C. I really don't see what they would get, just less control, more implicit stuff, and worst compilation speed, all of that for nothing. There is a reason why nothing in actual low level. Even MS is replacing C++.
    2
  3.  @mmstick  The problem with C is not one of memory safety, that's a consequence not a cause. Zig tries to fix the cause, which ends up resolving 90% of the consequences at 10% of the cost of something like Rust. Like the linux kernel is 17M loc of pure C, it's crafted by the most talented devs in the world, and honestly with such a wobbly and error prone language is actually incredible how safe and well made the kernel is. So if anyone (because I don't really care if Zig ends up wining) can offer a language that has similar semantic but modernized C semantic, sane defaults, actually helpful compiler and really well made and useful tooling for debugging and crafting high quality code, than It's not even a question of if it will win against Rust, it just will. Yes Rust does make writing safe and correct code somewhat easy, but nothing comes free, and I'm not sure the community of the linux kernel as a whole is willing to pay the price that comes with Rust. But full disclosure I have zero ball in this game I really don't care which languages ends up landing in the kernel, and I would be happy if it's Rust, I just think it's a hard sell.
    1
  4.  @kuhluhOG  Completely agree, I understand why Rust encodes lifetimes in the type system because those annotations are needed for the lifetime analysis, but at the same time. Lifetime are not a set in stone thing, this is why I find that languages like Zig is in this case imo superior because lifetime is managed by your allocator. So I can have let's say a linked list, and Idk maybe I can allocate my node with a fast static allocator on the stack because I know those nodes need to live only for that function, maybe I want those nodes to live for a frame time, so I might use an arena, or maybe I just need to allocates a few nodes here and there in which case a heap allocator is ok, but now I want to debug something so I can swap that with a debug allocator and a logging allocator to track my allocations. The point being that I think Rust would benefit from an actual allocator interface, that could offer to the compiler some lifetime guarantees, because structs should have generic lifetime in 99% of the cases and should be managed by the developer locally, I think this would help reduce the syntax clutter and also make the code more explicit and self documented
    1