4 ms·
I was also, in fact, referring to the bulk of legacy code bases that can't just be fully rewritten. Almost all good engineering is done incrementally, including
by mightyham 11mo ago
I was also, in fact, referring to the bulk of legacy code bases that can't just be fully rewritten. Almost all good engineering is done incrementally, including the adoption of something like safe_c.h (I can hardly fathom the insanity of trying to migrate a million LOC+ of C to that library in a single go). I'm arguing that engineering effort would be better spent refactoring and rewriting the application in a fully safe language one small piece at a time.
- kstrauser 11mo agoI’m not sure I agree with that, especially if there were easy wins that could make the world less fragile with a much smaller intermediate effort, eg with something like FilC. I wholeheartedly agree that a future of not-C is a much better long term goal than one of improved-C.
- uecker 11mo agoI don't really agree, at least if the future looks like Rust. I much prefer C and I think an improved C can be memory safe even without GC.
- whytevuhuni 11mo ago> I think an improved C can be memory safe even without GC That's a very interesting belief. Do you see a way to achieve temporal memory safety without a GC, and I assume also without lifetimes?
- uecker 11mo agoA simple pointer ownership model can achieve temporal memory safety, but I think to be convenient to use we may need lifetimes. I see no reason this could not be added to C.
- whytevuhuni 11mo agoA C with lifetimes would be nice, I agree. Would be awesome if someone did a study to see if it's actually achievable... Cyclone's approach was certainly not enough, and I think some sort of generics or a Hindley-Milner type system might be required to get it to work, otherwise lifetimes would become completely unusable.
- uecker 11mo agoYes, one needs polymorphism. Let's see. I have some ideas.
- 1718627440 11mo agoC does have the concept of lifetimes. There is just no syntax to specify it, so it is generally described along all the other semantic details of the API. And no it is not the same as for Rust, which causes clashes with the Rust people.
- uecker 11mo agoWhat clashes?
- 1718627440 11mo agoI think there was a discussion in the Linux kernel between a kernel maintainer and the Rust people, which started by the Rust people demanding formal semantics, so that they could encode it in Rust, and the subsystem maintainer unwilling to do that.
- uecker 11mo agoAh, I thought you were talking about core language semantics in C.
- 1718627440 11mo agoI don't know enough Rust, to do such a comparison.
- steveklabnik 11mo ago“The rust people” were also kernel maintainers.
- 1718627440 11mo agoSorry, I'm not familiar with the titles of kernel developers. I thought only one of them was the subsystem maintainer.
- 11mo ago