Maybe it’s a good idea, but it’s understandable that some people are reluctant.
I understand that position. I also understand how the words and phrases that the C community has used to communicate with the Rust community seems to be completely dismissive, not just reluctant.
I quoted what I did explicitly because of how a statement like that comes off to the person it's aimed at. It doesn't make them feel like they're on an even footing working on the same project with the overall goal of it becoming better.
memory safety is more akin to changing languages from English to Esperanto because it has gender neutral pronouns.
I mean... not at all? Memory safety is huge for cybersecurity, buffer overflows and the like are common attack surfaces. C requires you to have deep knowledge of safe memory management practices and even then you can end up with memory issues. Rust was developed to avoid such issues entirely. I understand the reluctance but it feels to me like arguing "we should just stick with COBOL because it works."
Gender neutral pronouns are pretty huge too. Sure you can do them in English without too many problems usually, just as it's also possible to code safely in C. It requires everyone to change their old habits, but it's much less of a change than is involved in adopting a whole new language.
Anyway, I do like Rust better personally.
I would still say that getting people to the point where they can write safe C code every time is harder than learning Rust, as it’s equivalent to being able to write rust code that compiles without any safety issues (compiler errors) every single time, which is very difficult to do.
Ok, that made your analogy make more sense to me. I can agree with that. Thanks.
Gender neutral pronouns might be pretty huge too, but nobody's private data is getting hacked because of gendered pronoun use.
Don't thinknits possible by on write safe c code. Otherwise we would not have these issues time and time again. But yes its only the idiots begin don't know how to code. Projects are big and complicated itsneasy to make mistakes.
People prefer what's familiar to them. Rust is completely foreign to them, the syntax is very different, the community is different (and often much younger), it still has many issues and is not ubiquitous, and many people are just slow/averse to change in general. So I absolutely understand the hesitation. And some just don't like it for other reasons like the syntax, learning curve or other reasons. There's also still a host of memory-related things Rust doesn't fix like stack overflows, leaks, bitflips, unsafe context code, and just bad coding practices in general.
I blame C++. When these kernel hackers hear about how they should switch to this shiny new language that's going to make their code so much cleanser and more manageable, I don't blame them for thinking it's all bullshit. It was last time.
To be fair, there's nothing wrong with only using the parts of C++ you want. If you avoid things like templates, exceptions, RTTI etc. then e.g. your compile times will not suffer like people always complain about, your error messages will not be cryptic, plus you'll have stronger typing, easier/safer lifetime management with ctor/dtors and easier to read code from class usage.
Personally I think Swift has great potential if it can get past the speed and cross-platform issues, as it was designed by (among others) some C++ committee folks, and so it feels a lot more familiar than say, Rust, plus it fixes a lot of long-standing issues.
There is also an Indian kernel fork that allows C++ drivers.
I understand the reluctance but it feels to me like arguing “we should just stick with COBOL because it works.”
For those depending on COBOL code that does the job and has been doing it just well for a few decades, there are approximately zero good reasons to not stick with it.
Eventually all the people who know and are good at cobol will die.
A while before that happens, the people who know it will continually demand more money for their rare skills.
Eventually, the cobol systems out there will need to interface new systems in some way it wasn't designed to and it'll be more expensive to shoehorn the remote system than to let the ancient beast retire.
I understand that position. I also understand how the words and phrases that the C community has used to communicate with the Rust community seems to be completely dismissive, not just reluctant.
I quoted what I did explicitly because of how a statement like that comes off to the person it's aimed at. It doesn't make them feel like they're on an even footing working on the same project with the overall goal of it becoming better.
I mean... not at all? Memory safety is huge for cybersecurity, buffer overflows and the like are common attack surfaces. C requires you to have deep knowledge of safe memory management practices and even then you can end up with memory issues. Rust was developed to avoid such issues entirely. I understand the reluctance but it feels to me like arguing "we should just stick with COBOL because it works."
Gender neutral pronouns are pretty huge too. Sure you can do them in English without too many problems usually, just as it's also possible to code safely in C. It requires everyone to change their old habits, but it's much less of a change than is involved in adopting a whole new language.
Anyway, I do like Rust better personally.
I would still say that getting people to the point where they can write safe C code every time is harder than learning Rust, as it’s equivalent to being able to write rust code that compiles without any safety issues (compiler errors) every single time, which is very difficult to do.
Ok, that made your analogy make more sense to me. I can agree with that. Thanks.
Gender neutral pronouns might be pretty huge too, but nobody's private data is getting hacked because of gendered pronoun use.
Don't thinknits possible by on write safe c code. Otherwise we would not have these issues time and time again. But yes its only the idiots begin don't know how to code. Projects are big and complicated itsneasy to make mistakes.
People prefer what's familiar to them. Rust is completely foreign to them, the syntax is very different, the community is different (and often much younger), it still has many issues and is not ubiquitous, and many people are just slow/averse to change in general. So I absolutely understand the hesitation. And some just don't like it for other reasons like the syntax, learning curve or other reasons. There's also still a host of memory-related things Rust doesn't fix like stack overflows, leaks, bitflips, unsafe context code, and just bad coding practices in general.
I blame C++. When these kernel hackers hear about how they should switch to this shiny new language that's going to make their code so much cleanser and more manageable, I don't blame them for thinking it's all bullshit. It was last time.
To be fair, there's nothing wrong with only using the parts of C++ you want. If you avoid things like templates, exceptions, RTTI etc. then e.g. your compile times will not suffer like people always complain about, your error messages will not be cryptic, plus you'll have stronger typing, easier/safer lifetime management with ctor/dtors and easier to read code from class usage.
Personally I think Swift has great potential if it can get past the speed and cross-platform issues, as it was designed by (among others) some C++ committee folks, and so it feels a lot more familiar than say, Rust, plus it fixes a lot of long-standing issues.
There is also an Indian kernel fork that allows C++ drivers.
For those depending on COBOL code that does the job and has been doing it just well for a few decades, there are approximately zero good reasons to not stick with it.
Does it count as “doing it well” when every release has fixes for previous releases’ memory bugs?