It’s fair to want to learn (and it’s certainly a good skill to have), but the question is what you’d rather see in a large, production environment. Guard rails are usually there for a reason. As for the control: you actually can program memory-unsafe (and in kernel development you often have to!) in Rust. The difference is that in Rust it’s explicitly marked by an unsafe block:
unsafe {
...
}
That way you get the same, fine-grained control over low-level processes, but someone else reading your code can at a glace spot where potential memory bugs may be.
In the end, languages are a tool. Especially for personal projects, everyone should just go with what’s fun to them. I personally think it makes sense, logistically, to slowly transition legacy C-based projects to Rust, because it makes onboarding new developers easier, while keeping the same memory safety that requires years of experience otherwise, basically for free. But there’s really no rush to rewrite anything that’s working well in Rust
Alas, when there is no difference between unsafe wrapper in Rust and C, then why learning Rust, if one wants to go for managing the memory manually? Especially when considering the complex way of coding in Rust?
Another problem: going the easy way and forgetting the tricky parts - if Rust allows for unsafe code, but it is safer to put it into a « safe » mode, so why I need to take the burden and deal with unsafe code? This will evidently lead to the situation that less and less unsafe blocks will be used, which finally leads to a situation where the programmer forgets the in and outs of manual memory management. You can see it as the principal aim of writing memory safe code, but to me it is also a way of « delearning » by learning. I see here the reason why so many young programmers are opting for Rust, because manually managing the memory in larger projects like in C is a question of knowledge and experience which does not come in one day. I also doubt that following just the compiler is a good approach.
I agree totally with your last points though! Coding should mean to have fun and be the same time mentally challenged due to complex algorithms or demand for better code in general.
The difference is, you put up a sign “here be dragons” with unsafe. Certain operations break the garanties of rust, like pointer operations and Cells. So now you need to write a wrapper which upholds checks that they are not violated. If it breaks, you just need to check your unsafe code, instead of everything. Now only one person needs to deal with unsafe for everyone in a team to benefit.
Memory safety isn’t a skill issue. There is a reason they happen in all big projects like android or chrome and only reduced when introducing safe languages.
I’d rather have a compiler that tells me why my code was refused than a compiler which prints 100 lines of templates. Or a compiler, which tells me a pointer/reference is null instead of a compiler that knows, but it’s UB-NDR so it isn’t snitching. If the compiler tells me, hey here you could have a race condition, it’s one less bug I have to find with a debugger. A compiler that complains about uninitiated variables, instead of a compiler that gives me potluck as content.
Thank you for your explanation and I understand it well, as well the advantage to find bugs quicker (which however does not mean that a safe code cannot be also a bad code). However, I do think that writing safe code without being guided by a compiler is indeed a skill. And the question how safe the code written with the help of the compiler will be is another interesting one. Perhaps we will find out in the future.
In my opinion, Rust is a language dictated by the compiler rather than one that allows you to use your brain, knowledge, and skills to deepen your understanding. Rust is essentially a programming language with training wheels.
Unfortunately, the preference to finish tasks quickly is nowadays the mainstream. The understanding of the deeper stuff falls behind.
A related example from real life: bike tyres that have a flat. Less and less people can change the tyres on their own, and even do not understand the construction and characteristics of different tyres, only believing what the vendor in the shop is telling them. Bad surprises then happen.
This, to me, seems like the standardization vs optimization argument. So much of the tech world could be optimized like crazy, but the more complex it gets, the hard it is to communicate with others and keep things consistent. This complexity actually hinders production overall. Standardization, even if it’s not the most optimized, allows us to create vastly more complex and reliable systems because we can ensure we are all on the same page. Even if that standardization isn’t the best way to do it. I mean, if you want to talk about absolute control over your code, why don’t you write in assembly? Are all programming languages not virtually assembly with training wheels?
Writing in code that is not memory safe is going to mean you are substantially more likely to have mistakes that lead both to user annoyance and straight up security vulnerabilities. Having applications written in a memory safe languages, especially when worked on by large swaths of people, is absolutely the best route. It provides a secure standard way to write memory safe code. This will reduce security vulnerabilities, decrease program crashes, and allow for more efficient developers.
Changing a bike tire is something for a single person, maybe two at most. Writing code is often a team effort. And the more people that are involved, the more likely mistakes are going to happen. People absolutely can still learn the complexities, and still choose to use Rust because honestly, it’s the smart thing to do. And it doesn’t need to be rust. Any memory safe language would accomplish the same goal.
This, to me, seems like the standardization vs optimization argument. So much of the tech world could be optimized like crazy, but the more complex it gets, the hard it is to communicate with others and keep things consistent. This complexity actually hinders production overall. Standardization, even if it’s not the most optimized, allows us to create vastly more complex and reliable systems because we can ensure we are all on the same page. Even if that standardization isn’t the best way to do it.
Standardization is the reason why systems collapse or are more prone to attacks. Just think about a monoculture vs an organic mixed culture. Also, the impact on standardized systems is much bigger, because it affects the entire system. But on the other hand, yes, it requires more time and people. When reading comments from Rust people, I have always the impression that in the best case everything is replaced with Rust code. If this is indeed their intention, I disagree.
I mean, if you want to talk about absolute control over your code, why don’t you write in assembly? Are all programming languages not virtually assembly with training wheels?
Perhaps difficulty to learn, apply, and make changes? Also no interest, trigger and coolness among people? Assembly are considered the old nerds aka the hated boomers, while Rust people are sometimes the hipsters, the new generation. I do not like this attitude of exclusion. BTW, if you want to try out an OS written in assembly look at Kolibri OS.
Writing in code that is not memory safe is going to mean you are substantially more likely to have mistakes that lead both to user annoyance and straight up security vulnerabilities.
Depends on your skills.
Having applications written in a memory safe languages, especially when worked on by large swaths of people, is absolutely the best route.
I am sorry but I am unable to mix “safe language”, “large swaths of people”, and “best route” somehow in my brain. I just see “tilt, tilt, tilt”, because it does not make sense to me as there are no connections between all three points.
It provides a secure standard way to write memory safe code. This will reduce security vulnerabilities, decrease program crashes, and allow for more efficient developers.
The secure I put in question mark (aka time will show) and are you serious about efficient developers? In case you mean producing a larger program faster, yes, I agree. Memory safer? Very likely (although you can write safe programs in C as well). But more efficient in terms of more competent? I would not say this.
Changing a bike tire is something for a single person, maybe two at most. Writing code is often a team effort. And the more people that are involved, the more likely mistakes are going to happen.
Does not change my intention: either you know the in and outs, or you are a slave of others - in the case of Rust, the slave of the compiler.
People absolutely can still learn the complexities, and still choose to use Rust because honestly, it’s the smart thing to do.
Haven’t said anything against, but the smart thing to do is up to the personal choice, not because there is a loud community of followers.
And it doesn’t need to be rust. Any memory safe language would accomplish the same goal.
This is the point I would underline. It is not only Rust, but there are many languages out there worth regards and time, even for low level and systems.
Yes, writing safe code is a skill. But for most skills you need someone to teach you.
My suggestion is, think about it differently:
The compiler isn’t training wheels, but rather a senior dev, that quickly looks over your shoulder and tells you, hey you might have missed something here. You can at any point tell them, trust me bro for this part. They need at some points a comment in the form of lifetime annotations. They are pretty good, but not perfect.
To pick up your example. They don’t tell you, you need a new wheel. They tell you, you’re bike has disc brakes, but your new wheel is missing the disk. When you later hit a wall, because you couldn’t break, you can check where you just said trust me.
@Flipper, if you just learn from one master, you cannot become a master in the field. As I said above: relying heavily on the compiler, even when this may be the best „teacher“, does not make you - I do not speak about you personally, but you in general, so all programmers - a good programmer. This is my major critic about Rust, while I do also understand its advantages.
It’s fair to want to learn (and it’s certainly a good skill to have), but the question is what you’d rather see in a large, production environment. Guard rails are usually there for a reason. As for the control: you actually can program memory-unsafe (and in kernel development you often have to!) in Rust. The difference is that in Rust it’s explicitly marked by an unsafe block:
unsafe { ... }That way you get the same, fine-grained control over low-level processes, but someone else reading your code can at a glace spot where potential memory bugs may be.
In the end, languages are a tool. Especially for personal projects, everyone should just go with what’s fun to them. I personally think it makes sense, logistically, to slowly transition legacy C-based projects to Rust, because it makes onboarding new developers easier, while keeping the same memory safety that requires years of experience otherwise, basically for free. But there’s really no rush to rewrite anything that’s working well in Rust
Alas, when there is no difference between unsafe wrapper in Rust and C, then why learning Rust, if one wants to go for managing the memory manually? Especially when considering the complex way of coding in Rust? Another problem: going the easy way and forgetting the tricky parts - if Rust allows for unsafe code, but it is safer to put it into a « safe » mode, so why I need to take the burden and deal with unsafe code? This will evidently lead to the situation that less and less unsafe blocks will be used, which finally leads to a situation where the programmer forgets the in and outs of manual memory management. You can see it as the principal aim of writing memory safe code, but to me it is also a way of « delearning » by learning. I see here the reason why so many young programmers are opting for Rust, because manually managing the memory in larger projects like in C is a question of knowledge and experience which does not come in one day. I also doubt that following just the compiler is a good approach. I agree totally with your last points though! Coding should mean to have fun and be the same time mentally challenged due to complex algorithms or demand for better code in general.
The difference is, you put up a sign “here be dragons” with unsafe. Certain operations break the garanties of rust, like pointer operations and Cells. So now you need to write a wrapper which upholds checks that they are not violated. If it breaks, you just need to check your unsafe code, instead of everything. Now only one person needs to deal with unsafe for everyone in a team to benefit.
Memory safety isn’t a skill issue. There is a reason they happen in all big projects like android or chrome and only reduced when introducing safe languages.
I’d rather have a compiler that tells me why my code was refused than a compiler which prints 100 lines of templates. Or a compiler, which tells me a pointer/reference is null instead of a compiler that knows, but it’s UB-NDR so it isn’t snitching. If the compiler tells me, hey here you could have a race condition, it’s one less bug I have to find with a debugger. A compiler that complains about uninitiated variables, instead of a compiler that gives me potluck as content.
Thank you for your explanation and I understand it well, as well the advantage to find bugs quicker (which however does not mean that a safe code cannot be also a bad code). However, I do think that writing safe code without being guided by a compiler is indeed a skill. And the question how safe the code written with the help of the compiler will be is another interesting one. Perhaps we will find out in the future.
In my opinion, Rust is a language dictated by the compiler rather than one that allows you to use your brain, knowledge, and skills to deepen your understanding. Rust is essentially a programming language with training wheels. Unfortunately, the preference to finish tasks quickly is nowadays the mainstream. The understanding of the deeper stuff falls behind.
A related example from real life: bike tyres that have a flat. Less and less people can change the tyres on their own, and even do not understand the construction and characteristics of different tyres, only believing what the vendor in the shop is telling them. Bad surprises then happen.
This, to me, seems like the standardization vs optimization argument. So much of the tech world could be optimized like crazy, but the more complex it gets, the hard it is to communicate with others and keep things consistent. This complexity actually hinders production overall. Standardization, even if it’s not the most optimized, allows us to create vastly more complex and reliable systems because we can ensure we are all on the same page. Even if that standardization isn’t the best way to do it. I mean, if you want to talk about absolute control over your code, why don’t you write in assembly? Are all programming languages not virtually assembly with training wheels?
Writing in code that is not memory safe is going to mean you are substantially more likely to have mistakes that lead both to user annoyance and straight up security vulnerabilities. Having applications written in a memory safe languages, especially when worked on by large swaths of people, is absolutely the best route. It provides a secure standard way to write memory safe code. This will reduce security vulnerabilities, decrease program crashes, and allow for more efficient developers.
Changing a bike tire is something for a single person, maybe two at most. Writing code is often a team effort. And the more people that are involved, the more likely mistakes are going to happen. People absolutely can still learn the complexities, and still choose to use Rust because honestly, it’s the smart thing to do. And it doesn’t need to be rust. Any memory safe language would accomplish the same goal.
Standardization is the reason why systems collapse or are more prone to attacks. Just think about a monoculture vs an organic mixed culture. Also, the impact on standardized systems is much bigger, because it affects the entire system. But on the other hand, yes, it requires more time and people. When reading comments from Rust people, I have always the impression that in the best case everything is replaced with Rust code. If this is indeed their intention, I disagree.
Perhaps difficulty to learn, apply, and make changes? Also no interest, trigger and coolness among people? Assembly are considered the old nerds aka the hated boomers, while Rust people are sometimes the hipsters, the new generation. I do not like this attitude of exclusion. BTW, if you want to try out an OS written in assembly look at Kolibri OS.
Depends on your skills.
I am sorry but I am unable to mix “safe language”, “large swaths of people”, and “best route” somehow in my brain. I just see “tilt, tilt, tilt”, because it does not make sense to me as there are no connections between all three points.
The secure I put in question mark (aka time will show) and are you serious about efficient developers? In case you mean producing a larger program faster, yes, I agree. Memory safer? Very likely (although you can write safe programs in C as well). But more efficient in terms of more competent? I would not say this.
Does not change my intention: either you know the in and outs, or you are a slave of others - in the case of Rust, the slave of the compiler.
Haven’t said anything against, but the smart thing to do is up to the personal choice, not because there is a loud community of followers.
This is the point I would underline. It is not only Rust, but there are many languages out there worth regards and time, even for low level and systems.
Yes, writing safe code is a skill. But for most skills you need someone to teach you. My suggestion is, think about it differently:
The compiler isn’t training wheels, but rather a senior dev, that quickly looks over your shoulder and tells you, hey you might have missed something here. You can at any point tell them, trust me bro for this part. They need at some points a comment in the form of lifetime annotations. They are pretty good, but not perfect.
To pick up your example. They don’t tell you, you need a new wheel. They tell you, you’re bike has disc brakes, but your new wheel is missing the disk. When you later hit a wall, because you couldn’t break, you can check where you just said trust me.
@Flipper, if you just learn from one master, you cannot become a master in the field. As I said above: relying heavily on the compiler, even when this may be the best „teacher“, does not make you - I do not speak about you personally, but you in general, so all programmers - a good programmer. This is my major critic about Rust, while I do also understand its advantages.
The sound bite I heard was “the unsafe keyword makes memory bugs greppable.”