Fix some words to better convey the actual meaning.

1-js/04-object-basics/02-garbage-collection/article.md

@@ -156,7 +156,7 @@ The following "garbage collection" steps are regularly performed:
 - The garbage collector takes roots and "marks" (remembers) them.
 - Then it visits and "marks" all references from them.
 - Then it visits marked objects and marks *their* references. All visited objects are remembered, so as not to visit the same object twice in the future.
-- ...And so on until there are unvisited references (reachable from the roots).
+- ...And so on until there isn't any unvisited reference (reachable from the roots).
 - All objects except marked ones are removed.
 
 For instance, let our object structure look like this:

1-js/05-data-types/10-destructuring-assignment/article.md

@@ -356,7 +356,7 @@ The problem is that JavaScript treats `{...}` in the main code flow (not inside
 }
 ```
 
-So here JavaScript assumes that we have a code block, that's why there's an error. We have destructuring instead.
+So here JavaScript assumes that we have a code block, that's why there's an error. We want destructuring instead.
 
 To show JavaScript that it's not a code block, we can wrap the expression in parentheses `(...)`:
 

1-js/06-advanced-functions/01-recursion/article.md

@@ -185,7 +185,7 @@ Here's the context stack when we entered the subcall `pow(2, 2)`:
 
 The new current execution context is on top (and bold), and previous remembered contexts are below.
 
-When we finish the subcall -- it is easy to resume the previous context, because it keeps both variables and the exact place of the code where it stopped. Here in the picture we use the word "line", but of course it's more precise.
+When we finish the subcall -- it is easy to resume the previous context, because it keeps both variables and the exact place of the code where it stopped. Here in the picture we use the word "line", but of course it's more precise in the real stacks.
 
 ### pow(2, 1)