In response to:
For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Rizèl Scarlett -
Jai Bhullar -
Sukhpinder Singh -
Tom Borg -
Top comments (39)
Imagine you have a box of toys, each toy has a place where it belongs so you always know where to look for it. After you're done playing with it you put it back where you got it from for next time. On top of that you have a helper who will have a little look through the toy box every so often and they will get rid of any toys you don't need anymore, maybe the toys are broken or maybe you just never want to play with them again. This way we can keep the toy box neat and tidy.
Memory safe programming languages have a set of rules for your computer's "toy box", though instead of toys we have data. We always keep it in the same place and when we're done with it we get rid of it (this is called garbage collection). This helps us prevent accidentally letting someone else see our data and also makes finding and using data much easier.
Nice one. But it does not explain how Rust is memory safe though. Guess the metaphor would be somewhat more difficult.
Rust bakes in the helper (garbage collector)
Rust very famously does not rely on garbage collection which is different than memory safety.
technically reference counting is garbage collection
Sometimes the child decides he really wants to play with his toy car next, so he picks it up and puts it on the little shelf meant for setting things down, then he does this 5 more times with other toys. He tells everyone this is the more efficient and optimized way of getting his toys he knows he wants to play with. The helper was told not to clean that shelf until the toy box is closed, which the child knows so he leaves it open. Someone comes along and steals all of the child's toys because he didn't close it.
Just as the healthcare and broadcasting industries grandfathered the internet, C an C++ grandfathered AI. Kids don't usually play with adults because they are too small. But some adults will abduct and kidnap kids because they are small. There is no and will be no safe code because the system is gaming cheating seniors, adults and children. You won't phase out C or C++ because the healthcare and broadcasters won't give up their blind spots. As they say in prison; "in order to be the man you have to beat the man...". The White House has help put a lot of bad parents in jail, but it has also made a lot of healthcare and broadcasters wealthy. The only good code is one that logs and alerts when RF equipment is live while you are viewing sensitive data. Almost zero ransomware and DDoS attacks occur without a hacker bulletin board evangelizing and converting members to safety. Maybe the White House should suggest Bearcats with their list of memory safe languages.
very nice!
If it wasn't such a poorly defined concept, then it might be possible to explain it, and then figure out how to reduce it to something consumable by a 5 year old.
However, "Memory Safe Programming Language" is a poorly defined concept. Why? Because it doesn't explain what "memory safe" means.
Technically, any FP (Functional Programming Language) practicing the fundamentals of "immutability" and "function referential transparency" are very "memory safe" from the perspective of not being able to change the state of a variable once it has been initialized.
Here's how Google's Gemini summarizes this.
And here is a great summary of the various FP languages and how they provide advantages.
That said, Java, C++, and even C can be made to be "memory safe" if one were to chose to very carefully and explicitly use immutability and "referential transparency".
In the end, the "Memory Safe Programming Language" is a false concept. All there can be are programming languages that make it more difficult to program incorrectly and which are more restrictive around how data is actually controlled.
tl;dr Technically, no such thing as "Memory Safe Programming Language" exists. That is fallacious concept that entirely misplaced the responsibility for effective and quality software design on a programming language instead of on the actual cause of the problems which is bad software engineering theory and practices.
I asked Gemini the same question. Here's how it response,
I asked it, too, to see it's answer. And it was the same answer given by a number of people replying to this thread. I even wondered why the OP didn't do this themselves.
That said, the answer demonstrates that the LLMs are just regurgitating what they have observed, and are not engaged in critical thinking about the actual problem itself.
If you will notice, I offered a response with critical thinking and did NOT use the AI/ML to compose it.
I think a huge number of people are going to get lost with the AI/ML LLM "looks like effective rational critical thinking", but it turns out that it isn't that at all.
And I suspect that the worst cases will be the marginal Software Engineers. They know just enough to inadvertently hurt themselves and others.
It strikes me as an excellent example of Hanlon's Razor:
"Do not attribute to malice that which is as easily attributed to ignorance."
Proper engineering means using the right the tools for the job. For physical construction, there's laws about this, because engineers have long learned that "effective and quality ... design" doesn't work if a building is built out of bad materials. They didn't blame some vague bad engineering theory and practices for the Grenfell Tower fire; they put the blame for the deaths on the use of flammable cladding.
Technically, there's no such thing as a "functional programming language" exists. It's a poorly defined concept that doesn't explain what "functional" means, and more precise definitions vary widely. But in reality, there's a general understanding of what a functional programming language is.
Likewise, "memory safe programming language" is not an entirely clear concept, but we should be able to agree that any language that can define an array of five elements and let you write to memory outside that array by accessing element 100 is not memory safe. That, and the ability to deallocate memory and then write to it, despite other parts of the code believing they have exclusive access to it, are the two issues that people have used to hack into systems that have generally be identified as a lack of memory safety.
I'm pretty sure you just repeated what I said, just in a passively aggressively oppositionally defiant tone.
Whatever floats your emotional boat, LOL!
Think of it as a way to keep your program from going hay wire due to a human mistake. So the most basic example would be like Java that uses strict types and a garbage collector. Which helps avoid incorect types being allocated to memory space and garbage collection to help free up memory ect.
In short think of it as a way to keep the program from getting things like memory leaks or stack overflow issues. And its more handled by the language vs having to manually handle it your self.
This is not memory safety. Not a single compiler out there will stop a memory leak. Segmentation in the other hand is what Zig, Rust and many other are trying to avoid.
Technically it is memory safety, while it does not stop it completely, it does allow you to identify it? And try to keep it from happening in the first place? But what you said is also more of the full spectrum of the actual issue.
Image that you have a coloring book and a crayon. There is nothing stopping you from coloring outside the lines if you are careless. There might be nothing outside the line so it's no big deal, or there might be something outside the line that you accidently colored over and ruined. That is NOT memory safe.
Now image that you have a stencil. You have a different stencil for every object on the page, and it's clipped to the page. Even if you try, you cannot color over any other objects. That is memory safe.
This is actually a really great metaphor for buffer overflow! I like it a lot!
my understanding of this issue is that in writing code in C and C++ for ex. the coder defines memory addresses and buffer sizes where data is held or work is performed. buffer overflow occurs when a coder has not accurately delineated the buffer or memory size or addresses. since the space is contiguous, a hacker can push more code into the ill defined space causing it to 'spill over' into the next address, thereby feeding false data into the processing. think of a house with many rooms and multiple doors to each room. good code opens the most efficient door pathway for a person to get anywhere in the house (ie: processing), AND closes each door as it passes thru to prevent unauthorized ppl from passing. A buffer overflow or memory leak, is a door left open and an unauthorized ppl enters.
so like if tetris blocks were sentient beings and they hired tetroidian contractors to build their houses with perfectly shaped doors to prevent the pacman ghosts to squeeze through the doors.
idk, I just picture blocks for all this 😅
Could someone also ELI5:
1) Most of the languages listed by the NSA are built on top of C and/or C++, and neither has GC. Being that they are the high level languages built on top of the low level C/C++, how then are those languages ultimately "memory safe"?
2) What then does that mean for languages implemented in C/C++, even if not directly built on or related to them? Doesn't that ultimately influence memory allocation anyway?
Both my braincells thank you for any advice😌🙏🏼
1) I'm not exactly sure what you mean by "built on top of C/C++", at least for Rust. Perhaps the compliers are written in C/C++ (which isn't true of Rust at least, but perhaps others). Regardless, see the second answer:
2) If they are built on top of C/C++, then so long as the compiler only can possibly generate memory safe code, the other language is also memory safe. I think another commenter's "stencil" example is apt here - the compiler for the language has a bunch of stencils it can use from your code to generate the lower level code. So long at the stencils themselves are utilizing memory safe code, the higher level language is memory safe, because it will never generate something that is not memory safe.
1) I'm not exactly sure what I mean either 🤷♂️, it's just the way I've interpreted low to high level language development, as in they are built on the foundations made by low level languages so that now the thousands of files of boilerplate-esque code lying underneath HLLs allow them to be typed in a much simpler and human friendly way. Both a "stand on the shoulders of giants" way and extra filter to help translate between human letters and binary electrical signals.
2) Ahh I see, that then paints the picture for me the other way around: high level initiates the action, to be filtered down into lower level and ultimately machine assembly then binary. That makes sense. I don't understand enough at these levels of what is going on specifically, what specific processes executed by what specific code, to make sense of it beyond that though.
Thanks for the advice, it helps clear some things up
Well, you know there are things in this house that you aren't allowed to touch because mommy and daddy say so? That's because we're in a safe family. If you were in an unsafe family, where mommy and daddy didn't watch after you, you'd think you would have so much more fun. You could do whatever you want to with no consequences.
But the consequences still exist. You still get burned from touching the hot stove. You still get hurt if you trip down the stairs. You still get sick if you touch medicine you don't need.
Memory safety is like parents, but for computers. Old-timey programmers didn't think they needed a mommy and daddy to tell them what to do. They never learned what it was like to feel safe. They instead got used to burning themselves. That doesn't sound like fun now, does it?
And Rust is like parents with very strict rules. They won't help you, only forbid you of doing some things. And if you manage to burn yourself anyway they will tell you "Your fault, we warned you but you didn't listen"!
And Java, C#, Python are like "Don't worry, go play, we will clean it up everything afterwards" 😅
Except for event listeners. I know C# doesn't completely clean up event listeners (not sure about java). One of the nastiest memory leaks I've seen in my career was from not unsubscribing to event listeners properly. Funnily enough this was on a government project also.
I'd more say Rust is like parents that trust you. They will tell you what to do unless you can tell them why you don't want to do it, and they'll let you find out the consequences of your ignorance then :)
HA! As a parent with a toddler, I extra love this response.
Memory safe languages are like the bank.
Memory unsafe languages are like a treasure ground in which you & a lot of others hide treasure.
C and C++ allow developers to allocate memory for use, but don't stop the developer from writing outside that memory allocation, they let developers "draw outside the lines". A memory safe programming language hides all memory allocation (and deallocation) from the developer, making sure they always "draw inside the lines".
Using the drawing metaphor. You (program a) allocate a firetruck drawing to color in, and someone else (program b) allocates a pool drawing to color in. The teacher (operating system) put these side by side with no gap. You start coloring your fire truck red. As you work, you find that there is now blue in your firetruck, the other person drew outside the lines (didn't use a memory safe programming language) so now your firetruck is compromised with color (data) that was drawn outside the pool (buffer overrun).
Best case, you just get a new firetruck (restart your program), worst case, you find the other person used their permanent blue marker to draw every where, even on the teacher (operating system) so now the entire school has to be shut down.
Imagine kids coloring a pentagonal star on drawing paper. Suppose that you have to color each triangular portion, but not the center.
If you're not a smart, experienced kid, you will color outside the lines. Sometimes by accident, sometimes because you're not experienced enough.
Languages that are not memory-safe are like that. Error prone, but fine for experienced kids.
Contrast that with having a stencil, maybe of triangular shapes. You will be far more tidy in your goal. The stencil is tool the likes of which are built into memory safe languages. Constrain your reach. Go wild with the coloring, but the paper only receives it in the necessary spots.
All analogies break down when you then say "There is no garbage collector in a stencil"
There is a garbage collector: it's called white-out.