11 ms·

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal.

lol my other post got flagged, so let me reiterate perhaps in a less inflammatory way. It is disappointing to see that "trust the programmer" is a design goal. Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. Building a language like this and saying you hope it will be the foundation for new operating systems is... depressing. It's setting us up for another century of industry failure - buggy software that makes users less safe. It's not to say that memory unsafe languages have no place. Toy programs, or programs not exposed at all, are fine. But that's clearly not the case here - the stated use cases are things like the OS, "networking software", etc. All of the places where C has caused incredible harm. edit: It would be wrong not to note that Hare does consider memory safety. https://harelang.org/blog/2021-02-09-hare-advances-on-c/ https://harelang.org/blog/2021-02-09-hare-advances-on-c/ There are clearly wins here, no question in my mind that a world where spatial memory safety is the default is a better world than today. It doesn't change my view overall, however, that for the use cases defined that the bar needs to be higher. I am also compelled to say something nice about the language. Most apparent is that it looks very approachable - I have to wonder what the '!' means (I can guess), but otherwise it looks very readable. I also like the explicit nature, that's my preference for programs as well as I find it's much more readable. I think "simplicity" can be a tricky goal, but I like seeing languages call it out as one - I'm very curious to see over the next few decades how "simple" plays out.

ddevault 4y ago
There are plans to research an optional borrow checker for Hare. Hare also does offer many "safety" advantages over C: checked slice and array access, exhaustive switch and match, nullable pointer types, less undefined behavior, no strict pointer aliasing, fewer aggressive optimizations, and so on. Hare code is much less likely to have these errors when compared to C code. I would ultimately just come out and say that we have to agree to disagree. I think that there is still plenty of room for a language that trusts the programmer. If you feel differently, I encourage you to invest in "safer" languages like Rust - but the argument that we're morally in the wrong to prefer another approach is not really appreciated.
- staticassertion 4y ago
  I think a section on safety might be worthwhile. For example, Zig pretty clearly states that it wants to focus on spatial memory safety, which it sounds like Hare is going for as well. That's certainly an improvement and worth noting, although it obviously leaves temporal safety on the table. > but the argument that we're morally in the wrong to prefer another approach is not really appreciated. Well, sorry to hear it's not appreciated, but... I think developers should feel a lot more responsibility in this area. So many people have been harmed by these issues.
  - ddevault 4y ago
    I don't really want to engage with the RESF. We have the level of safety that we feel is appropriate. Believe me, we do feel responsible for quality, working code: but we take responsibility for it personally, as programmers, and culturally, as a community, and let the language help us: not mandate us. Give us some time to see how Hare actually performs in the wild before making your judgements, okay?
    - staticassertion 4y ago
      I'm a security professional, and I'm speaking as a security professional, not as an evangelist for any language's approach. > Give us some time to see how Hare actually performs in the wild before making your judgements, okay? I'm certainly very curious to see how the approach plays out, but only intellectually so. As a security professional I already strongly suspect that improvements in spatial safety won't be sufficient to change the types of threats a user faces. I could justify this point, but I'd rather hand wave from an authority position since I suspect there's no desire for that. But we obviously disagree and I'm not expecting to change your mind. I just wanted to comment publicly that I hope we developers will form a culture where we think about the safety of users first and foremost and, as a community, prioritize that over our own preferences with regards to our programming experience.
      - ddevault 4y ago
vladharbuz 4y ago
I can sort of understand where you're coming from — manual memory management can be difficult, and doing it improperly can cause bugs. However, in my experience, we're very far from having a magical solution for memory management. C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. Unfortunately, the memory management strategy of every other language I've tried introduces performance penalties that make it unsuitable for e.g. video games. Trust me, I really wish this weren't the case! :( Until we have some kind of significantly better solution that solves all memory management problems, I would rather work in a simple language that lets me carefully do everything myself, and if that language is also an improvement over C, I'm happy. However, that's just me, and I can fully appreciate that others are free to choose the tools that are good for them!
- staticassertion 4y ago
  I hear you, but I think the problem is that you're framing this as "I, the developer, don't want to accept these costs". And that's fine when the software doesn't leave your system. The problem is that you're them pushing other costs onto your users ie: exploitable software. So from the developer perspective, great, it works for you, but the cost is there. I'm sympathetic to not wanting to use the other languages available, I'm not saying that any other language is doing things the "right" way, there's room for a lot of improvement. But I personally think that setting out to build new systems software in a memory unsafe language is setting users up for very serious harm.
  - vladharbuz 4y ago
    I think I understand your view better now. Are you aware of any current memory management strategies (implemented as part of a language or otherwise) that perform well in situations with high performance requirements? For example, as someone who works on video games and real-time audio, most options seem non-starters to me aside from Rust, even if I decided to make sacrifices for the sake of security, and I at least have the impression I've explored this space quite a bit. Anyway, I would be happy to learn more about minimal memory safety strategies that don't require massive scaffolding and also allow for high-performance situations.
closeneough 4y ago
Imho as everywhere in this field there are tradeoffs to choose for improving this problem: Complexity (rust, formal proofs), runtime overhead (GC), etc. Hare tries to be simple, so that it's easier to reason about the code and hence maybe find/avoid such bugs more easily.
joeberon 4y ago
I agree. It is quite clear that it is impossible to write large code bases safely with manual memory management. Even very small programs often have massive problems. I think many programmers are simply in denial about this.
- nyanpasu64 4y ago
  I see Rust as a counterexample, serving as a formalization of provably safe patterns of manual memory management. I do wish it made it easier to write human-checked code the compiler cannot verify; unsafe code is so painful with unnecessary pitfalls, that many people write either wrong-but-ergonomic unsafe code (https://github.com/mcoblenz/Bronze/ https://github.com/mcoblenz/Bronze/, https://github.com/emu-rs/snes-apu https://github.com/emu-rs/snes-apu) or add runtime overhead (Rc and RefCell).
Koiwai 4y ago
While any modern operating system is the living counter point, so far it's manageable.
- the_duke 4y ago
  Every (popular) modern operating system sits on decades old foundations written in C that can't just be replaced, so that's not a particularly strong argument. It's noteworthy that Google is financing the effort to bring Rust to the Linux kernel, that Microsoft is also investing in the language and that there are newer, production usage focused operating systems written in Rust. (eg Hubris [1]) [1] https://github.com/oxidecomputer/hubris https://github.com/oxidecomputer/hubris
  - mkeeter 4y ago
    Redox is probably a better example than Hubris: https://www.redox-os.org/ https://www.redox-os.org/ Hubris is intended to run on microcontrollers in a very low-level context (e.g. no display), so is very unlikely become a desktop / user-facing OS. (I work at Oxide, mostly writing Hubris code)
- formerly_proven 4y ago
  They aren't a counterpoint at all. They're confirmation. Security-wise legacy operating systems (Linux, NT, ...) suck. New security vulnerabilities are discovered every week and month in them to the point that nobody actually considers these "multi-user systems" any more and obviously every box hooked up to the internet better be getting patches really frequently.
  - Koiwai 4y ago
    For the record I said manageable not great or perfect.
throwawaymaths 4y ago
Maybe be less zealous and aware of your assumptions? Your assumption is that memory safety has to be baked in the language. It could be baked into proof assistants that are part of (optional or add-on) tooling, like what sel4 does. A simpler language makes this more possible, and the things that a proof assistants can do go far beyond what rust is able to provide, without sacrificing compilation speed or other forms of optimality (e.g. avoiding the heap) when you don't want or need such a high level of security guarantee (e.g. writing a cli tool that never sees the internet) As for me, I'm terrified that rusts complex macro system will hide/obfuscate discovery of other forms of security regression, like timing or energy side channels.
- staticassertion 4y ago
  My assumptions are based on study and experience. My "Zealotry" is just a desire to reduce harm to users in an area that I personally believe we should strive not to regress on. I'm not interested in discussing Rust. Frankly, I'm sure there will be plenty of other people already doing so. What's clear from this thread is that Hare does attempt to move the needle, relative to C, with regards to safety. My opinion is that that's not enough for the use cases they're targeting, but I suppose it's really up to whoever's writing the software to decide that.
- kaba0 4y ago
  > A simpler language makes this more possible This is false. Rust’s borrow checker is nothing else but an included proof assistant for rust code. The reason it can catch so many memory issues and data races is specifically due to a more restricted language. Also, sel4 is a relatively tiny program which was written for an unusually long time by domain experts. Formal verification simply doesn’t scale to global properties, that’s why some restrictions are useful as they allow local reasonings instead. For a more hands-on example look at the quality of auto-complete in case of Intellij’s Java vs a dynamically typed language. This night and day difference in quality is yet again possible due to what the language can’t denote. Re rust macros: I don’t get your point, AFAIK they simply expand to regular old Rust code and then gets compiled, so the exact same safety guarantees apply.
pizza234 4y ago
- vladharbuz 4y ago
  While Drew is the designer of Hare, a lot of us worked on Hare, and we tried really hard to create something useful and valuable. I think it would be a shame if you disregard it because of something that Drew said at whatever point in time. If you have the time, please try Hare and let us know what you think! Aside from that, the question of memory safety is more complex than you make it out to be, and Drew, myself and others have discussed it in a lot of detail in this thread, Drew mentioned there are many memory safety features, potential plans for an optional borrow checker and so on — please draw your conclusions based on the full information.
  - the_duke 4y ago
    I am sympathetic, but I agree with others that any new systems language in 2022 must have memory and thread safety with minimal escape hatches as its utmost priority and a core component of the language design. Otherwise, what's the point? Yet another language that is a bit more convenient than the alternatives but doesn't do much to help with all the vulnerabilities and bugs in our software? We already have quite a few languages like that: Zig, Nim and D to name a few. (for both Nim and D GC is optional) Rust is by no means the ultima ratio. It's complex and places a lot of immediate burden on the developer. I'm sure there are better solutions out there that don't sacrifice the safety guarantess. Particularly because Rust not only has the borrow checker but also a general focus on very type-system heavy designs. But it has proven to be a significant step up from the likes of C and C++, and the additional burden pays off immensely in maintainability and correctness. I can count the memory/thread unsafety issues I encountered in 5 years of Rust on one hand, and in each case the culprit was a C library. (either because of a bad wrapper, or inherent incorrectness in the library) Memory and thread safety can't be retrofitted into a language without producing a mess, as can be seen by the discussions and efforts in D, C++ and to some extent Swift. They need to be central to the core language and standard library.
    - 4y ago
Shadonototra 4y ago
> Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. We have sanitizers if you are a bad programmer, use that if you don't trust yourself
- kaba0 4y ago
  It’s just ridiculous to call someone a bad programmer over memory bugs. By your own words you are definitely a bad programmer if you have ever written more than 1000 lines of code in low level programming language, because there is simply no way you haven’t made an error. You just don’t necessarily know about it, which in my opinion makes you a worse developer, especially with this ancient and destructive mindset.
  - Shadonototra 4y ago
    There is nothing wrong with being a bad developer, we are all bad developers if we don't understand what we are doing We have the tools to eliminate memory bugs already Forcing people to use a language with a buitin sanitizer/babysitter that runs everytime you compile your code and as a result makes you wait 10+ minutes between each line of change is dumb Expecting your code to be bug free because the code written by someone else told you so is also dumb https://github.com/rust-lang/rust/issues/38899 https://github.com/rust-lang/rust/issues/38899 who to trust in that case? -- educate and trust developers, use tools to audit your code when needed
    - kaba0 4y ago
      Sanitizers can only show you some memory problems that happen during a given runtime with given data. And your 10+ minutes baseless assumption is just demonstratively false. In the default debug mode it is literally instant with human perception on my current, not small project. Longer compiles only happen in release mode or when you introduce new dependencies. Shall I link you to Valgrind bugs as well?
      - 4y ago
minroot 4y ago
How would I trust the programers who implement automatic memory management that they are not going to make any mistake?
- throw10920 4y ago
  "How would I trust the programmers who implement compilers that they are not goin to make any mistakes? I'll write the assembly myself, thank you very much." It's much better to push logic from being manually re-written over and over by tens of thousands of different programmers, to being built into a language/tool/library by a team of a few hundred experts and then robustly tested.
  - AnimalMuppet 4y ago
    > "How would I trust the programmers who implement compilers that they are not goin to make any mistakes? I'll write the assembly myself, thank you very much." Nope, doesn't work. Then you have to trust that the programmer who wrote the assembler didn't make any mistakes. Real programmers program in octal.
    - astrange 4y ago
      > Then you have to trust that the programmer who wrote the assembler didn't make any mistakes. This is true, but the actual solution is safer assembly. ARM is heading in this direction with PAC/BTI/CHERI. Intel, being Intel, tried adding some and it was so broken they removed it again. It could go much further.
akagusu 4y ago
For the last 50 years, from personal computer devices to nuclear power plants, the world is sitting on a pile of C code. Why are you afraid of manual memory management? The world is just doing fine with it, because, believe me or not, the world's worst problems like violence, war, poverty, famine, just to name a few, are not caused by C bugs.

ddevault 4y ago

There are plans to research an optional borrow checker for Hare. Hare also does offer many "safety" advantages over C: checked slice and array access, exhaustive switch and match, nullable pointer types, less undefined behavior, no strict pointer aliasing, fewer aggressive optimizations, and so on. Hare code is much less likely to have these errors when compared to C code. I would ultimately just come out and say that we have to agree to disagree. I think that there is still plenty of room for a language that trusts the programmer. If you feel differently, I encourage you to invest in "safer" languages like Rust - but the argument that we're morally in the wrong to prefer another approach is not really appreciated.

staticassertion 4y ago
I think a section on safety might be worthwhile. For example, Zig pretty clearly states that it wants to focus on spatial memory safety, which it sounds like Hare is going for as well. That's certainly an improvement and worth noting, although it obviously leaves temporal safety on the table. > but the argument that we're morally in the wrong to prefer another approach is not really appreciated. Well, sorry to hear it's not appreciated, but... I think developers should feel a lot more responsibility in this area. So many people have been harmed by these issues.
- ddevault 4y ago
  I don't really want to engage with the RESF. We have the level of safety that we feel is appropriate. Believe me, we do feel responsible for quality, working code: but we take responsibility for it personally, as programmers, and culturally, as a community, and let the language help us: not mandate us. Give us some time to see how Hare actually performs in the wild before making your judgements, okay?
  - staticassertion 4y ago
    I'm a security professional, and I'm speaking as a security professional, not as an evangelist for any language's approach. > Give us some time to see how Hare actually performs in the wild before making your judgements, okay? I'm certainly very curious to see how the approach plays out, but only intellectually so. As a security professional I already strongly suspect that improvements in spatial safety won't be sufficient to change the types of threats a user faces. I could justify this point, but I'd rather hand wave from an authority position since I suspect there's no desire for that. But we obviously disagree and I'm not expecting to change your mind. I just wanted to comment publicly that I hope we developers will form a culture where we think about the safety of users first and foremost and, as a community, prioritize that over our own preferences with regards to our programming experience.
    - ddevault 4y ago

vladharbuz 4y ago

I can sort of understand where you're coming from — manual memory management can be difficult, and doing it improperly can cause bugs. However, in my experience, we're very far from having a magical solution for memory management. C++ definitely isn't it, and while Rust does bring significant advances in this field, it's a very large and complicated language. Unfortunately, the memory management strategy of every other language I've tried introduces performance penalties that make it unsuitable for e.g. video games. Trust me, I really wish this weren't the case! :( Until we have some kind of significantly better solution that solves all memory management problems, I would rather work in a simple language that lets me carefully do everything myself, and if that language is also an improvement over C, I'm happy. However, that's just me, and I can fully appreciate that others are free to choose the tools that are good for them!

staticassertion 4y ago
I hear you, but I think the problem is that you're framing this as "I, the developer, don't want to accept these costs". And that's fine when the software doesn't leave your system. The problem is that you're them pushing other costs onto your users ie: exploitable software. So from the developer perspective, great, it works for you, but the cost is there. I'm sympathetic to not wanting to use the other languages available, I'm not saying that any other language is doing things the "right" way, there's room for a lot of improvement. But I personally think that setting out to build new systems software in a memory unsafe language is setting users up for very serious harm.
- vladharbuz 4y ago
  I think I understand your view better now. Are you aware of any current memory management strategies (implemented as part of a language or otherwise) that perform well in situations with high performance requirements? For example, as someone who works on video games and real-time audio, most options seem non-starters to me aside from Rust, even if I decided to make sacrifices for the sake of security, and I at least have the impression I've explored this space quite a bit. Anyway, I would be happy to learn more about minimal memory safety strategies that don't require massive scaffolding and also allow for high-performance situations.

closeneough 4y ago

Imho as everywhere in this field there are tradeoffs to choose for improving this problem: Complexity (rust, formal proofs), runtime overhead (GC), etc. Hare tries to be simple, so that it's easier to reason about the code and hence maybe find/avoid such bugs more easily.

joeberon 4y ago

I agree. It is quite clear that it is impossible to write large code bases safely with manual memory management. Even very small programs often have massive problems. I think many programmers are simply in denial about this.

nyanpasu64 4y ago
I see Rust as a counterexample, serving as a formalization of provably safe patterns of manual memory management. I do wish it made it easier to write human-checked code the compiler cannot verify; unsafe code is so painful with unnecessary pitfalls, that many people write either wrong-but-ergonomic unsafe code (https://github.com/mcoblenz/Bronze/ https://github.com/mcoblenz/Bronze/, https://github.com/emu-rs/snes-apu https://github.com/emu-rs/snes-apu) or add runtime overhead (Rc and RefCell).

Koiwai 4y ago

While any modern operating system is the living counter point, so far it's manageable.

the_duke 4y ago
Every (popular) modern operating system sits on decades old foundations written in C that can't just be replaced, so that's not a particularly strong argument. It's noteworthy that Google is financing the effort to bring Rust to the Linux kernel, that Microsoft is also investing in the language and that there are newer, production usage focused operating systems written in Rust. (eg Hubris [1]) [1] https://github.com/oxidecomputer/hubris https://github.com/oxidecomputer/hubris
- mkeeter 4y ago
  Redox is probably a better example than Hubris: https://www.redox-os.org/ https://www.redox-os.org/ Hubris is intended to run on microcontrollers in a very low-level context (e.g. no display), so is very unlikely become a desktop / user-facing OS. (I work at Oxide, mostly writing Hubris code)
formerly_proven 4y ago
They aren't a counterpoint at all. They're confirmation. Security-wise legacy operating systems (Linux, NT, ...) suck. New security vulnerabilities are discovered every week and month in them to the point that nobody actually considers these "multi-user systems" any more and obviously every box hooked up to the internet better be getting patches really frequently.
- Koiwai 4y ago
  For the record I said manageable not great or perfect.

throwawaymaths 4y ago

Maybe be less zealous and aware of your assumptions? Your assumption is that memory safety has to be baked in the language. It could be baked into proof assistants that are part of (optional or add-on) tooling, like what sel4 does. A simpler language makes this more possible, and the things that a proof assistants can do go far beyond what rust is able to provide, without sacrificing compilation speed or other forms of optimality (e.g. avoiding the heap) when you don't want or need such a high level of security guarantee (e.g. writing a cli tool that never sees the internet) As for me, I'm terrified that rusts complex macro system will hide/obfuscate discovery of other forms of security regression, like timing or energy side channels.

staticassertion 4y ago
My assumptions are based on study and experience. My "Zealotry" is just a desire to reduce harm to users in an area that I personally believe we should strive not to regress on. I'm not interested in discussing Rust. Frankly, I'm sure there will be plenty of other people already doing so. What's clear from this thread is that Hare does attempt to move the needle, relative to C, with regards to safety. My opinion is that that's not enough for the use cases they're targeting, but I suppose it's really up to whoever's writing the software to decide that.
kaba0 4y ago
> A simpler language makes this more possible This is false. Rust’s borrow checker is nothing else but an included proof assistant for rust code. The reason it can catch so many memory issues and data races is specifically due to a more restricted language. Also, sel4 is a relatively tiny program which was written for an unusually long time by domain experts. Formal verification simply doesn’t scale to global properties, that’s why some restrictions are useful as they allow local reasonings instead. For a more hands-on example look at the quality of auto-complete in case of Intellij’s Java vs a dynamically typed language. This night and day difference in quality is yet again possible due to what the language can’t denote. Re rust macros: I don’t get your point, AFAIK they simply expand to regular old Rust code and then gets compiled, so the exact same safety guarantees apply.

pizza234 4y ago

vladharbuz 4y ago
While Drew is the designer of Hare, a lot of us worked on Hare, and we tried really hard to create something useful and valuable. I think it would be a shame if you disregard it because of something that Drew said at whatever point in time. If you have the time, please try Hare and let us know what you think! Aside from that, the question of memory safety is more complex than you make it out to be, and Drew, myself and others have discussed it in a lot of detail in this thread, Drew mentioned there are many memory safety features, potential plans for an optional borrow checker and so on — please draw your conclusions based on the full information.
- the_duke 4y ago
  I am sympathetic, but I agree with others that any new systems language in 2022 must have memory and thread safety with minimal escape hatches as its utmost priority and a core component of the language design. Otherwise, what's the point? Yet another language that is a bit more convenient than the alternatives but doesn't do much to help with all the vulnerabilities and bugs in our software? We already have quite a few languages like that: Zig, Nim and D to name a few. (for both Nim and D GC is optional) Rust is by no means the ultima ratio. It's complex and places a lot of immediate burden on the developer. I'm sure there are better solutions out there that don't sacrifice the safety guarantess. Particularly because Rust not only has the borrow checker but also a general focus on very type-system heavy designs. But it has proven to be a significant step up from the likes of C and C++, and the additional burden pays off immensely in maintainability and correctness. I can count the memory/thread unsafety issues I encountered in 5 years of Rust on one hand, and in each case the culprit was a C library. (either because of a bad wrapper, or inherent incorrectness in the library) Memory and thread safety can't be retrofitted into a language without producing a mess, as can be seen by the discussions and efforts in D, C++ and to some extent Swift. They need to be central to the core language and standard library.
  - 4y ago

Shadonototra 4y ago

> Programmers can not be trusted with manual memory management. We have decades of proof, billions and billions of dollars of bug fixes and mitigation investments, real world damages, etc. We have sanitizers if you are a bad programmer, use that if you don't trust yourself

kaba0 4y ago
It’s just ridiculous to call someone a bad programmer over memory bugs. By your own words you are definitely a bad programmer if you have ever written more than 1000 lines of code in low level programming language, because there is simply no way you haven’t made an error. You just don’t necessarily know about it, which in my opinion makes you a worse developer, especially with this ancient and destructive mindset.
- Shadonototra 4y ago
  There is nothing wrong with being a bad developer, we are all bad developers if we don't understand what we are doing We have the tools to eliminate memory bugs already Forcing people to use a language with a buitin sanitizer/babysitter that runs everytime you compile your code and as a result makes you wait 10+ minutes between each line of change is dumb Expecting your code to be bug free because the code written by someone else told you so is also dumb https://github.com/rust-lang/rust/issues/38899 https://github.com/rust-lang/rust/issues/38899 who to trust in that case? -- educate and trust developers, use tools to audit your code when needed
  - kaba0 4y ago
    Sanitizers can only show you some memory problems that happen during a given runtime with given data. And your 10+ minutes baseless assumption is just demonstratively false. In the default debug mode it is literally instant with human perception on my current, not small project. Longer compiles only happen in release mode or when you introduce new dependencies. Shall I link you to Valgrind bugs as well?
    - 4y ago

minroot 4y ago

How would I trust the programers who implement automatic memory management that they are not going to make any mistake?

throw10920 4y ago
"How would I trust the programmers who implement compilers that they are not goin to make any mistakes? I'll write the assembly myself, thank you very much." It's much better to push logic from being manually re-written over and over by tens of thousands of different programmers, to being built into a language/tool/library by a team of a few hundred experts and then robustly tested.
- AnimalMuppet 4y ago
  > "How would I trust the programmers who implement compilers that they are not goin to make any mistakes? I'll write the assembly myself, thank you very much." Nope, doesn't work. Then you have to trust that the programmer who wrote the assembler didn't make any mistakes. Real programmers program in octal.
  - astrange 4y ago
    > Then you have to trust that the programmer who wrote the assembler didn't make any mistakes. This is true, but the actual solution is safer assembly. ARM is heading in this direction with PAC/BTI/CHERI. Intel, being Intel, tried adding some and it was so broken they removed it again. It could go much further.

akagusu 4y ago

For the last 50 years, from personal computer devices to nuclear power plants, the world is sitting on a pile of C code. Why are you afraid of manual memory management? The world is just doing fine with it, because, believe me or not, the world's worst problems like violence, war, poverty, famine, just to name a few, are not caused by C bugs.